I once sat behind the glass in a usability study. I was the lead in building the service being tested. We were studying whether the product we put together made it easy for our customers to solve their problems. In a typical usability study, a participant who has never used a product before is given a task, and builders watch them live as they try to use the product. In this case, it was clicking through buttons in the console and moving between pages. The goal was to see if the product communicated how it should be used, in other words, how intuitive it was.

I thought the user interface (UI) we put together was really great. It looked sharp. I was the lead engineer building the service behind it, and I had also been involved in shaping the concepts and UI flows during design sessions. At the start of the study, I was fully confident that users would complete the tasks with ease. Instead, I watched participant after participant click the wrong button, land on the wrong page, and fail to complete a task I thought was straightforward. It was an eye-opening experience for me as a software engineer.

People who build products, such as engineers, product managers, and applied scientists often get too close to them. What feels obvious to us may not be obvious to others. This is a blind spot user experience designers (UXD) are trained to avoid. Watching those participants, the UXD helping us was not surprised at all. For them, it was another day of gathering user feedback to refine the design.

Reading the usability report later, I learned something else. Users were not only confused by the interface. It was not just that a button could have been named better or placed differently. Some of the concepts we created as part of the data model were not intuitive. Users did not expect to create another resource and attach it to the original one for it to work. It was like renting someone a car, and expecting them to check the fuel first before they get in and turn the ignition on, while they expected the car to already have fuel. So they missed an unintuitive step, and the car did not start.

Until then I thought UXDs helped with UI while engineers defined the data model. Through that report, and follow-up conversations with our UXD, I realized they are trained to ensure the entire experience, not just the interface, is usable. In hindsight, I should have worked with UXD earlier on. I could have saved a lot of rework time.

I have seen builders treat UXD as an afterthought many times. The thing is, you can build a powerful, secure, reliable product. But if the interface and the concepts are not intuitive, if the customer journey is not shaped end-to-end by someone trained for it, you will frustrate your customers and risk losing them.

That is why I invited my colleague Shilpa Bhat to join me for a walk and a recording on this topic. Shilpa is a Principal UXD and leads the user experience team for Amazon Intelligent Operations, the broader org in AWS that owns services like CloudWatch, AI Ops, Managed Prometheus, OpenSearch, SSM, etc.

What follows is that conversation, with some quotes lightly edited for clarity. You can also watch the video here.

I started our conversation recalling the usability study I mentioned. I said, “Shilpa, when I first worked with a UX designer, I thought their job was about the interface.” Shilpa smiled and said “It is about the experience, it’s not just the interface.” That distinction matters. Calling it UX/UI flattens the role. “UX is much more than the UI.”

She gave an analogy:

Imagine you’re going to a restaurant. The food is one part of the experience. But the reservation, the welcome, the noise level, the way your order is taken, and how issues are handled are all part of the user experience. Even the payment timing changes how you feel about the place.

I agreed wholeheartedly. I go to a restaurant for more than the meal. I am there not just to feed myself, but to spend time with friends and family. How I remember that experience depends mostly on the people running the restaurant.

From there our conversation moved toward customer goals. “You always work backwards from the customer’s goal, the customer’s problem,” Shilpa explained. “Think about the ideal experience and then figure out how we achieve it.” She tied this to the “jobs to be done” philosophy. Customers are always hiring us to do a job. For example, in the space Shilpa and I work in, monitoring and operational excellence of software systems, that could mean resolving an issue quickly.

I added that when customers enter the AWS console and something is not where they expect, it is frustrating. We both laughed about a real-life example I brought up. I pointed to the “Norman Door” in the very building we were sitting in. How many times have I approached to that damn door, pushed, only to realize it was a pull? Later I learned these confusing doors are called Norman Doors, named after Don Norman, a cognitive scientist who showed how design should make use clear through its form. In his famous book, he used doors and door handles extensively to make the same point, hence the name.

It was not the first door I had trouble with. On a trip in Türkiye, I once stood there for what felt like half a minute, trying to get into a bank. It could have been a bank that offered the best service inside, but it didn’t matter. I was already frustrated before I even stepped through the door. In my defense, I was extremely jet-lagged and doors work differently there. In the US, commercial doors usually egress out, while in Türkiye they often do the opposite. Shilpa and I did not talk about this story, but reflecting on it later I realized it ties to localization, which in turn ties to usability and UXD. Different cultures bring different expectations. A shape, a symbol, even a color can mean opposite things depending on where you are.

Shilpa said this is related to a design term called affordance:

A product should communicate how users interact with it. When you see a cup of coffee, you know where you are supposed to hold it from and which end goes to your mouth. It is pretty self-explanatory.

Then, she brought it back to how this ties to the AWS console. She stressed that good design means thinking beyond the part of the system your own team owns. “If customers need to use multiple services to complete a job, the connective tissue matters,” she said. Going back and forth between consoles should be seamless.

I asked Shilpa what she expects from engineers when partnering with UXD.

A lot of engineering and UXD have very complementary goals. We always want to start with the “why.” Why we are building something and then figure out how to deliver it.

Bring UXD in early. Understand what the implications are. It may not be as trivial as it first seems, because there might be no standard patterns and you might need to think it through first.

Shilpa went on with an example from her time working with AWS DeepRacer, where her team contributed to an open-source project that many assumed had no UX element at all. Shilpa’s design team argued that developers would not see what they could achieve with the software without good guidance. They partnered with AWS Solutions Architects and community influencers to build small sample projects and record short videos of them using the software to inspire potential users. She said, “We then followed with marketing and console collaterals to reinforce the message.” By that she meant the supporting pieces teams often build after a launch, like blog posts, short guides, in-console tips, and other material that repeat the same message in different places. Shilpa later shared some of these videos with me. Here is one of them.

We closed with advice to be the user of our own products. I added my own reflection: the difference between trying a product on a large screen and on a small one can be dramatic. Only when I use my own products daily do I realize how they feel. Shilpa said, “We should be dogfooding our products day in and day out. Ask what the customer is trying to do, and then try to do it yourself.”

I had not worked for a US-based company before coming here, so the term “dogfooding,” which originated in the US, was confusing to me when I first heard it. The phrase traces back to a 1976 advertisement for Alpo dog food, where actor Lorne Greene claimed he fed the product to his own dog. In 1988, Paul Maritz at Microsoft sent an internal email titled “Eating our own dog food,” encouraging wider internal use of the company’s software. Since then, the term has stuck in the tech world. It is a strange name, but once you know where it comes from, the meaning is crystal clear. Using your own product is the only way to feel the friction yourself before customers do.

That usability study from years ago left a mark on me. My conversation with Shilpa reinforced my learnings from that experience:

1. Products succeed or fail not only on their power but on how they are experienced.

2. Working with UXDs is not only about how a product looks and feels. It is about ensuring the experience makes sense end-to-end.

3. As builders, we need to partner with UXDs from the start if we want to create products that our customers will love.

When I asked Shilpa at one point in our conversation, “Is it a stretch to say Amazon’s method of working backwards is UX?” she did not hesitate:

Totally, it’s totally that. If you look at the definition of user experience, it is user-centered design. The user is the center of everything we do. We start from the user, and Amazon’s working backwards is exactly that.

I walked away from our conversation that day with even a stronger conviction that the best products are built when we work side by side with UXDs.

Back in May 2025, I wrote about TechWomen and the power of mentorship. TechWomen is a U.S. State Department program, run by the Institute of International Education, that brings accomplished women in STEM from across the world to Silicon Valley and Chicago, pairing them with mentors who help amplify their impact.

It all started with a Walk the Talk I did with my colleague Abeetha Bala, Senior Product Manager at Amazon CloudWatch, when she was visiting Seattle. I was so moved by what I heard that I invited her to record an episode with me. In that session, she told me about her years of volunteering and how she co-founded the TechWomen AWS chapter.

I believe mentorship is one of the most important responsibilities we carry. Hearing Abeetha describe her own journey in our recording session deepened that conviction, and it moved me to apply to be a mentor myself. I also wrote that piece in May to encourage others to take the same step.

The video first circulated through internal channels and even made its way into Amazon’s internal newsletter that is emailed to all employees. I was exhilarated to hear from Abeetha that two AWS colleagues who signed up as first-time mentors this year said they were inspired by our episode.

A few weeks ago, I was humbled and thrilled to learn I had been selected as a mentor. Today I met my mentee for the first time. Her name is Assma Benmussa. She has been a software developer since 2017 and worked on a breadth of technologies. Abeetha and I will be co-mentoring her. Our kickoff meeting was full of passion, energy, and drive. I am excited for what’s next for Assma.

In other news, last Friday, the video of my conversation with Abeetha was also published on AWS’s official YouTube channel. So I decided to bring these threads together here: to reflect on that conversation in May, the lessons Abeetha shared, and what they mean as I begin my own journey with TechWomen.

What follows is a summary of our conversation, with some quotes lightly edited for clarity. You can also watch the full episode here.

We started our walk on a spring afternoon in Seattle, sitting outside on the shady patio of Amazon’s Blackfoot building. Abeetha began explaining TechWomen.

It is a mentorship program in the United States. We have over three hundred women leaders. Some are medical doctors, some with PhDs, some are entrepreneurs very successful in their fields. They come here to understand technology, learn more about emerging trends, and experience the culture. At AWS we host a TechWomen chapter.

TechWomen offers several forms of mentorship. Professional mentors support careers in STEM, cultural mentors help participants navigate life in a new country, and innovation mentors guide projects that tackle socioeconomic challenges back home.

Abeetha mentioned in our talk that participants arrive from 22 countries across Africa, Central and South Asia, the Middle East, and Europe. The official stay lasts five weeks, but the work does not end when they return home. Mentors often continue with monthly calls, helping leaders navigate challenges back in their own communities.

I asked Abeetha to recall one example from her TechWomen journey that moved her. She told me that every TechWomen program ends with an impact project. One of those projects, she said, “really brought tears to my eyes.” It was about water hygiene.

The participants spoke about how hard it was to find clean water, how every day was a struggle just to access something safe to drink. Listening to her describe it, I pointed out how far removed that reality is from the country we are living in. That moment when you turn on a faucet and clean water flows without a thought. That is a luxury many in the world do not have.

Abeetha nodded and broadened it to other barriers.

These causes are so real because every day they struggle for them. Some women wanted to move forward in life, to start their own businesses, but societal constraints held them back. They were grounded to do what they had to do and they really wanted a way to start their own business.

I asked about a field visit she had mentioned earlier, a trip that brought these lessons home even more forcefully. “Last year I had the privilege of going to Tajikistan, where we were in the field after these women went back,” she said.

She and other mentors traveled across Tajikistan, visiting universities and bootcamps that had been launched by TechWomen alumnae. They saw firsthand the kind of coaching participants had carried back with them and the impact it was already having.

The trip itself was a lesson in contrast.

We did not have good Wi-Fi connectivity throughout the seven-day trip. I was going on bumpy roads, the state of infra that was there, again, gave me a lot of appreciation as I came back.

For her, the lack of reliable Internet and basic infrastructure reframed what we, in our bubbles, sometimes consider inconveniences.

Even a ten-second Wi-Fi bloop is something that none of us can bear today. And being there with spotty Wi-Fi for seven days gave me better appreciation of the country we live in.

That week, seeing the work continue in Tajikistan, despite challenges of roads and connectivity, made clear to Abeetha just how resilient and determined the participants were.

I asked her if and how this journey over the past two years had changed her. Abeetha talked about how mentoring had developed her as much as it helped participants. She mentioned the group activities she had to lead and the talks she needed to give as part of her participation. “How do you confidently navigate a crowd? That is a skill set I’ve improved with TechWomen.” she said.

As a mentor at AWS, she also fielded many technical questions. Mentees asked about AWS services like SageMaker and Amazon Q.

It has helped me learn better. Last year I did a session on AWS Startups, an area I was not comfortable in. I had to meet so many people to understand what they do in that business.

I asked her, as a male ally, if I could be a mentor or participate in helping in some way. Abeetha said that although it is called TechWomen, mentors are not limited to women. They accept applications from all gender identities, including male allies.

She said “the only qualification you need is wanting to serve a greater purpose.”

She explained that applications open every June. Even if someone cannot commit to the full program, they can still contribute by leading a one-day workshop or covering a specific topic. The 2025 program has already begun, so if you are willing to help with workshops or other technical sessions, reach out to me or to Abeetha.

We ended our conversation with an important reminder: sign up for TechWomen’s newsletter to be notified of new volunteer opportunities as they become available.

A single nudge from a mentor can open a door that might have stayed shut. It changed the course of my own life when my mentors did the same for me, and now I have another chance to pass that on.

I am excited for what comes next.

I like spending quality time with my own brain. Those moments help me focus, solve a hard problem, or understand something complex. That said, when I need to be creative, come up with lots of competing ideas, and choose one, my brain and I alone can do only so much.

Most of the best ideas I’ve been part of came in a room or on a call, surrounded by others’ brains thinking hard, tossing out ideas, and questioning them. The presence of even one more person forces me to be more creative and quick to iterate, eliminate, or build upon ideas. The days I enjoy most in my profession are the ones with a fruitful brainstorming session.

In an ideal session, ideas swirl as if a storm has filled the room. No wonder the name fits so well. It was coined by a New York advertising executive, Alex F. Osborn, who co-founded one of the most successful ad agencies of the 20th century. He introduced it as a method for creative thinking, built on deferring judgment so ideas could flow freely. An wonderful article by Hanisha Besant traces the journey of brainstorming from Osborn to today.

Besant says “[Osborn] came up with four basic rules for the process.” Three of the rules can be summarized this way: create as many ideas as possible, allow them to be wild, and build on others’ ideas. Osborn’s second rule, “that no one was to criticize an idea,” is the one that stood out for me. It is a great rule, it is essential for a productive session, but I’ve seen it broken at times.

At Amazon, with whiteboards in our hallways and even our elevators, I’ve been part of thousands of brainstorming sessions. I’ve been to both great sessions and poor ones. In the worst, egos clashed. The ideas were dismissed too quickly. Or everyone was after pushing their own agenda without taking the time to hear each other.

Hasan Abbasi is a Principal Engineer at Amazon with whom I’ve worked for almost a decade. He is my favorite teammate to brainstorm with. With him there is no judgment. Ideas surface freely, shaped and reshaped without fear of being shut down.

That’s why I invited him to record an episode of Walk the Talk: Builder Conversations with me and identify what he and I do that makes our brainstorming sessions productive and judgment-free.

What follows is that conversation, with some quotes lightly edited for clarity. You can also watch the full video here.

Hasan came prepared to our discussion. He said he thought about what had made our brainstorming sessions work:

At first, I thought maybe it works because we think alike. But then I realized, no, it is not. You and I usually have differing views. It is actually about four things: being respectful, being open-minded, bringing different perspectives, and also having strong opinions.

We definitely share a sense of humor, a glimpse is on display in the bloopers. But Hasan is right, I remember many instances where we were thinking in opposite directions, and through our sessions, we converged. His list resonated with me the moment I heard it.

Respect

We decided to break our conversation into those sections. Hasan kicked the first one off.

Respect is the foundation of collaboration of all sorts. You cannot collaborate with someone who does not respect you or that you do not respect. And not just the person, but their opinions, their past work, their approaches, their position.

He pointed out how quickly its absence shows.

Often people come into a discussion with a hostile attitude. That doesn’t help get over any hurdles. When you come into a session for brainstorming, you need to check your ego at the door but bring your respect in. Without that, people stop listening.

Hasan was spot on. Without respect, brainstorming collapses into the most senior person dictating while everyone else stays silent. With respect, ideas are heard and tested.

Open-Mindedness

The second element in Hasan’s list was open-mindedness.

If you come into a session and you have already made up your mind about the path you want to take, you will not consider other options. That’s not brainstorming anymore. That’s trying to sell your idea.

Respect and openness, he explained, go together.

You only listen to other people’s opinions if you actually respect them. Otherwise, you might tell someone what you think the right way is, but you will not hear what they are telling you.

I told him why I think our sessions work: we can put wild ideas on the board without the fear of being judged. Hasan said “Even crazy ideas, right?” and built on what I’d just said.

There have been many instances where we mapped an approach, wrote it out, and at the end I said, “You know what… I’m an idiot, my original idea doesn’t work.” I can’t tell you how many times I’ve said those exact words in a session.

This is great humility by Hasan, which goes a long way in brainstorming. What he is really saying is that one needs to feel comfortable admitting their original thinking was wrong. That builds trust, and trust leads to what Osborn had in his rules: “improve on each other’s ideas.”

We discussed that if one feels someone is going to attack them in a brainstorming session, they will be less likely to give an honest opinion.

I continued arguing that the most senior person sets the tone so everybody feels comfortable contributing, no matter how wild the idea or what their level is. I recalled examples where the most brilliant idea came from the most junior person in the room, and that only happened when we, as facilitators, ensured psychological safety. I later read in Besant’s article that Osborn also made it clear that the “facilitator of the brainstorming session played a pivotal role in the process.”

The open-mindedness Hasan brought up allows finding better paths. Hasan recalled a project where his design seemed solid until an engineer less experienced than him suggested a cheaper and simpler alternative. He said his idea would have worked, but her perspective reshaped the solution. For Hasan, that is the value of open-mindedness: testing everything far enough to see what holds, and replacing your own when something better emerges.

Perspective

Hasan’s third element was perspective.

People will always come up with an idea that fits with the vision they have. You may not have equal knowledge, but you have equal knowledge about yourself.

He explained that it is easy to dismiss someone’s view without realizing the foundation it comes from. You might hear the words but miss why they are being said. When that happens, the whole idea feels weak because its base has been ignored.

Each team comes to a brainstorming session with its own perspective. I noted that in Amazon we often talk about “wearing different hats.” Within your own team, you focus on what benefits that group. But in a larger setting, the perspective has to shift toward what benefits the whole company.

Hasan nodded and gave an example: One team might be focused on reducing high-severity operational tickets, another on revenue. Both are valid, but unless you recognize the hat each is wearing, you will talk past each other.

We concluded that good brainstorming means putting those hats on and switching them long enough to understand.

Strong Opinions

The final element Hasan named was having strong opinions.

You cannot just come into a brainstorming session with no perspective of yourself. You have to have an opinion, a goal you are trying to get out. If all the participants have no opinions, then yes, it’s a pure brainstorming session, but it’s not productive.

Strong opinions give the room something real to test. Hasan used the image of fan-in and fan-out. Everyone comes in with many ideas. A good session narrows them down, tests them, and shapes them. Sometimes the fan-out is larger, and that is a signal that there were options no one had thought of before. I call that a success too.

Hasan described brainstorming as a loop. I found that brilliant. He said you think on your own, come together to combine ideas, generate more, then return to refine them. Hasan continued to emphasize a point I made mid-conversation that writing a document afterward turns that loop into something concrete. “Writing the doc is the one that lets the dust settle after the storm.”

In Conclusion

Thinking about our conversation, Hasan laid out a simple but powerful set of elements to keep brainstorming effective: Respect is the foundation. Open-mindedness keeps the session alive. Perspective widens the frame. Strong opinions push the work forward and give the room something real to test.

Two brilliant people, Osborn and Hasan, more than half a century apart, came up with their own four rules for brainstorming. Different rules, same spirit. Both are based on trust.

My first conflict at Amazon was with a product manager. It was 2013, only a few months into my time at the company. I was on call when a script my team owned, the one that generated data for the weekly business review, went down. It had already been a tough day, packed with other high-severity service issues, and I was stretched thin. That evening the PM came down to my desk visibly angry that I still hadn’t fixed the script. I didn’t keep my anger to myself either. We had a tough exchange, my blood boiled, and I lost sleep over it.

I was frustrated that he insisted on the priority of a task I believed could wait until later that night. I didn’t take the time to understand that the script was generating business-critical, time-sensitive data and that the PM was blocked. I was also frustrated that he made it seem as if everything I had been working on all day was of lesser priority. I know that wasn’t his intent, but when trust isn’t there, each side assumes the worst of the other’s thinking.

Problems of a similar nature had come up a few times in my daily walks with engineers and PMs. That is why I invited Nikhil Dewan, Head of Product for Amazon CloudWatch, to record an episode with me. Nikhil and I have known each other for a long time and worked on many projects together. I have seen him cross the line between engineering and product many times.

What follows is that conversation, with some quotes lightly edited for clarity. You can also watch the video here.

Nikhil started our conversation with a great story. Working on an ambiguous project a few years ago, while he was preparing to meet customers, he had drafted a list of questions. Instead of treating it as a PM-only task, he shared it with his engineering partner. “We jointly put together the final list,” Nikhil said and continued:

The best part was the engineer was excited to join the customer calls. He didn’t see it as a PM responsibility. He wanted to directly hear the voice of the customer.

The collaboration grew from there. The engineer shadowed him, learning how Nikhil asked open-ended questions and avoided jumping to solutions. As the engineer got more comfortable, he began asking questions himself. After each call they debriefed together and compared notes. Over time they started to see patterns across conversations that shaped their design decisions.

Agreeing with Nikhil that this was a great example, I said, “Partnership is the key. If a PM or an engineer draws a line in the sand and says, ‘this is your responsibility, that is mine,’ that territorial behavior is not going to work.” I was pointing to situations where PMs or engineers expect the product to be fully defined by the PMs (in Amazon this means writing a document called a PR/FAQ, which defines the product as if we are releasing it to the public and answering customers’ questions). The same goes for expecting the engineer to own the entire technical design.

Nikhil agreed and continued:

The owner of the PR/FAQ is not just the PM. The lead engineer is a co-owner. And while I am not writing the technical design doc, I see myself as a very important part of it. These docs are not PM or engineering docs. They are docs we co-own.

He explained that he sees value in engineers developing product instincts too.

Something I am super passionate about is how to make the best engineer also a pretty solid PM. I love when an engineer can lead a customer conversation themselves because they are that close to how we gather requirements and dive deep.

Then Nikhil turned the question to me and asked if I had seen examples of strong collaboration. I remembered one: a PM who, after talking to a few customers, hacked together a quick prototype from existing parts. It was scrappy, but it showed the shape of the idea. That extra effort added to the momentum and gave me confidence we were in for a great partnership.

Nikhil nodded and brought the point back to trust:

What you are highlighting Mustafa is a core Amazon Leadership Principle: Earn Trust. Engineers earn a PM’s trust when they partner on customer requirements and think through everything from product definition to prioritization to adoption.

And for PMs to earn the trust of engineers, they have to be hands-on. It is a tough skill, but absolutely critical in a very technical company. At the end of the day, Customer Obsession means we need to know what the customer does, and what better way than doing it yourself.

When I look back at that conflict in 2013, I see it was never about priorities. It was about trust that had not yet been built. The PM didn’t take my word that I would eventually fix it later that night. I didn’t trust his word that what he needed was truly business critical. Over time that PM and I became great partners by making the effort to step into each other’s world.

What we touched upon in my conversation with Nikhil is something close to my heart: trust is earned, with intention and effort.

And when trust is established, the products we build are better.

I’ve launched a new video podcast today. You can find all episodes at WalkTheTalk.show.

I didn’t come up with the name. It was coined by Anil Desai, the first of my colleagues who walked with me. When I wrote in Slack the next day asking who else would want to walk around the block with me, a few folks replied, and on the same thread Anil added, “I think you need a sign up sheet for Walk the Talk.” That line named the thing before I had even thought of it as a thing. Only later did I learn it was also a TV show in India by Shekhar Gupta with a similar premise: the host walking alongside his guests, interviewing them on the move.

It all started with a New Year’s resolution I made this year. I decided to pick one that, perhaps, this time I could keep: walk outdoors twenty minutes every day. A way to clear my head, move a little, and create space in the middle of busy days. Like most resolutions, though, I felt myself slipping after a month. I cursed myself more than once for trying to build such a habit in one of the coldest months of the year.

Something else was pressing. My team had grown to several hundred people during the pandemic, and when we came back to the office last year, I realized how many of them I hadn’t met yet. How were we going to keep delivering great products and maintain our large-scale systems if we didn’t really know each other? In an emergency, like a service outage, I am supposed to be trusted with my judgment. But how could they trust me if we had never spent any quality time together?

I tried a few ways to connect, but they weren’t as effective. I remembered the times I was a junior engineer. Whenever I crossed paths with someone far more senior, it felt as if I had run into Gandalf the White on a ridge overlooking Helm’s Deep in the second book. My eyes burning, I would wonder if I was even breathing or blinking right. Dropping into team meetings with the title I hold can shift the room in the same way. Retros and fun sessions can change tone the moment I show up. We have social hours, but they are too loud, scattered, and random to have any depth.

So that cold afternoon in February, I posted in our team Slack room: “I’m going to walk around the block and get some fresh air. Anyone want to join?” Anil said yes. I posted again the next day, and the day after. Twenty minutes around the block turned out to be the perfect size: easy to say yes to, no calendar mangement needed. Over time it grew into an almost-daily ritual. Now, when I’m visiting another office in a different city, I offer multiple walks in a day to make room for more conversations. And when walking in person isn’t possible, I offer a remote walk instead, with both of us on headphones, doing whatever relaxes each one of us, including an outdoor walk.

Beyond getting to know each other, and giving them time with someone who had been around the block a few times, those walks also taught me a few things. First, I was reminded again and again that I am surrounded by smart and passionate people from all walks of life and generations. They taught me about tools I hadn’t seen and pointed me to articles or videos I had missed. It was a reminder that everyone has something you can learn from, and an antidote to one of the great misconceptions of life: that our own generation was the last good one, and that those coming after us are nowhere close. Second, I heard directly about struggles and best practices within their teams that I would have easily missed in all-up reports, and I was able to offer suggestions on solving some of those issues and sometimes apply their practices more broadly. Third, a simple twenty-minute walk can go a long way in bridging the gap. The next time I was in a meeting with someone I had walked with, it was easier to make progress, because the artificial distance created by titles had narrowed.

Doing this every day, I started to notice sets of questions that came up again and again. How do I handle disagreement without damaging trust? How do I navigate across teams when goals don’t align? Should I stay an independent contributor or try the management route?

For many of these questions, I think I have good answers. But for some of them, like whether to try the management route, it is best answered by someone who has done that. I never chose that path. And I am only one person. I have experience, but it is nowhere close to the collective experience we have across my network.

This gave me an idea. What if, on some days, I invited experienced Amazonians to walk with me and record their take on some of those questions as a video podcast? I could add my commentary, but let the person with the experience, role, or superpower that best fit the question share their perspective. That is how Walk the Talk: Builder Conversations began to take shape.

At first, I thought we would record ourselves while walking, but the logistics of that proved to be a nightmare. Instead, we walk together first, discuss the question we want to cover during the walk, then find a place to sit and record a casual conversation. Someone once joked that the podcast should really be called “Sit the Talk” since we aren’t actually recording while moving. Fair point. But the walk is still the spark. It is what leads to the talk on record.

My first take was a disaster. I picked the wrong spot in the Amazon Spheres, with too many people behind us taking selfies and causing distractions. The average quality microphones I bought and thought would do an acceptable job failed miserably. The audio, the most important part of the whole thing, was muffled beyond repair. That first attempt was with Hasan Abbasi. He graciously agreed to do one more take with me, which became an episode that is out now. My next guest, where I finally showed up with better equipment, was Nikhil Dewan. Even then, we had several struggles. My favorite was a custodian rolling two big trash cans behind us just as I was saying the words, “PMs should get their hands dirty.”

I posted a few episodes to Amazon’s internal video sharing platform, and they caught the interest of the folks who manage AWS social media accounts. We decided to release these videos publicly, and now they are posted on the AWS Careers YouTube channel in their own playlist. A shorthand URL is WalkTheTalk.show if you’d like to bookmark it.

Walk the Talk started with a New Year’s resolution that almost died. It stayed alive because it solved a real need: to connect, to listen, and to surface the lessons that repeat.

I have enjoyed every minute of each walk and recording session. I hope you will too!

P.S. Feel free to drop me a note if you have feedback, ideas, or if you are also an Amazonian and interested in sharing your own learnings as a guest in the podcast.

From the Broader Conversation

In this newsletter, I try to bring my own experience to each piece, but I believe the real value comes from connecting that perspective with the collective wisdom of my network and with ideas I encounter elsewhere. Below are from my bookmarks relevant to today’s topic and not promoted content.

From Ethan Evans

Back in 2019, Ethan Evans, a former Amazon VP, wrote The Reason Everyone Wants a Mentor. His argument was simple and still relevant today: schools don’t prepare people for the realities of work, fewer students gain early job experience, and so employees enter the workplace hungry for guidance. It made me remind myself that mentorship, and creating spaces like Walk the Talk, is a responsibility for those who have more experience.

Consider subscribing to Ethan’s awesome Level Up Newsletter if you haven’t already.

From Julie Zhuo

I’ve recently came across this article on Lean In by Julie Zhuo. It is a candid story about how hard it was to start writing publicly. She had been keeping a journal since childhood, but when she first tried to blog, she froze: what voice should she use, what if people thought less of her if she shared insecurities? For months she wrote anonymously, until she realized anonymity made her words hollow. That’s when her writing began to resonate with larger audiences.

This story resonated with me because I’ve struggled with the same question: how much do I share? At Amazon, “being vocally self critical” is part of earning trust, and inside the company I grew comfortable with it. But doing it in public felt different. When I was working on Walk the Talk episodes for the initial release, I kept stalling, re-editing, and obsessing over details. Friends and my wife told me to stop overthinking. Looking back, yes, the hesitation was about microphones or editing, but it was also a bit about bracing myself to be seen more broadly for who I am, flaws included.

Julie closes her article by describing how much she gained once she stopped hiding: warm compliments, her writing being shared, feedback that sparked new ideas, and connections that helped her grow into a better designer and leader. I would love to experience that kind of growth through Walk the Talk. Even now, I’ve benefited in ways I didn’t expect. I used to cringe every time I saw myself on video or heard my own recorded voice. Forcing myself to endure hours of editing has started to change that. I watch my body language, the way I phrase things, and how I come across. I’ve already noticed I feel more comfortable when I deliver a speech in public. I don’t know yet where this podcast will lead, but I’m eager to keep learning.

Consider subscribing to Julie’s excellent newsletter.

I almost missed the biggest opportunities of my life, until a mentor stepped in.

From kindergarten to the workplace, mentors showed up at just the right moments. They helped me recognize opportunity when it was disguised as uncertainty, and reminded me to keep going when I almost didn’t.

That’s what mentorship does.

And it’s why I applied to be a mentor with TechWomen this year, a program that supports women in STEM from countries where both infrastructure and opportunity can be scarce. It takes all of us to stand beside them as they rise higher.

I was lucky to grow up in Turkiye at a time when public education was free, accessible, and strong. That foundation shaped everything that followed, not just the knowledge I gained, but the people I met along the way who nudged me toward better choices.

I was lucky to have a teacher who pulled me aside when I was choosing high school. One of the best schools in the city, already over a century old, was known for its rigor and its accomplished alumni. The only catch? It was an all-boys school, and I was a teenager with the usual cocktail of hormones, leaning toward a more balanced option. My teacher said, “If you can get in, it’s a great school. Set your priorities straight.” I applied, and got in. That choice shaped everything that came after: the study groups, the mindset, the peer network.

The school later began welcoming students of all gender identities, a long-overdue correction that opened doors for everyone.

Later, while I was a master’s student, I nearly gave up on applying to a PhD program in the U.S. Funding had been delayed. Deadlines were closing in. I didn’t think I could pull it off. A mentor sat me down and said, “These opportunities don’t come often. Get yourself together and apply already.” I did, and I got in.

Then came another kind of luck: my PhD advisor, Ali Akansu, who didn’t just care about my research, but about the kind of person I was becoming. He talked to me about how I’d show up in the world, how to grow my confidence, how to carry myself with intention. Some of the best advice I’ve ever received came while drinking coffee with him, off the clock.

Do you see the pattern?

A colleague of mine, Abeetha Bala, is one of those people who walks through life with a clear intention: to lift others up and help them channel their grit. She co-founded the TechWomen AWS chapter and has been leading it successfully for two years.

When Abeetha told me more about the program, what struck me most wasn’t just the brilliance of the TechWomen participants, but the weight they carry.

Some come from countries where only 10% of households have stable Internet. Where water cuts are routine, and in many cases, the water isn’t even potable. Where girls are expected to shrink, not lead. Where the moment they speak up, someone tells them not to overstep.

And still, they rise.

They return home and launch bootcamps for girls.
Found startups.
Change curricula.
Mentor relentlessly.
Advocate for access and opportunity, for all.

This isn’t about “helping the less fortunate.” It’s about standing beside people who already carry the future and amplifying what they’re already doing.

A little guidance, the right word at the right moment, can ripple across villages, classrooms, entire generations.

What we offer as mentors is perspective, encouragement, clarity. What we receive is often greater: the quiet knowledge that you helped someone take their next bold step.

If that speaks to you, apply today. Or find your own way to nudge someone forward.

It doesn’t have to be big.

It just has to be at the right moment.

A few years ago, I wrote a design document outlining a few different options. It was for a group more experienced than me, not in the domain, but in the industry. I knew the problem well. I had done the work. But still, I softened my position. I showed the tradeoffs, invited discussion, and held back from saying with confidence, “This is the direction I believe we should take.”

In a pre-review, someone I trusted, someone more experienced than me, called it out. The document lacked conviction. It read like I was asking the group to decide for me. They reminded me that I was the expert in this domain, not them. What they expected was something else: my thinking, clearly stated and owned. Not rigid. Not defensive. Just grounded in the work I had done.

That moment stuck.

I’ve found myself giving this advice ever since, to engineers, to peers, to new leaders. If you want real collaboration, don’t just open the floor. First, show your thinking. Then invite challenge.

Because consensus doesn’t mean staying neutral. It doesn’t mean showing up and asking, “What do you all think we should do?” and hoping clarity will emerge. It means doing the work, forming a point of view, and bringing others something solid to react to.

Consensus starts with conviction.

What’s harder is holding that conviction while staying open. You walk in with a recommendation, and a willingness to change your mind. That’s always important, but it becomes even more critical when you’re the most senior person in the room.

That’s when the room starts tilting toward you. People hesitate. They defer. And when you get that wrong, the cost is hidden. People stop pushing back. They start clapping along. What looks like alignment is often just fear in disguise, not because people agree, but because they don’t feel safe to disagree.

Leading in that moment means doing both: showing clarity and making space. Saying, “Here’s what I think,” and meaning it, while still being the kind of person others feel comfortable challenging.

That’s the real work of the most senior person in the room: bringing conviction without shutting down dialogue. Creating clarity while leaving room for disagreement and change.

It’s a balance. And that’s the job.

Back in the days when I was a PhD student, I was closely collaborating with a professor of mathematical finance at New York University, the late Marco Avellaneda. NYU is right by the great Washington Square Park, perhaps one of the most beautiful in the city. Sometimes, I’d walk there by myself or with my advisor, Ali Akansu. It was his favorite park too, a small shared ritual during those years that I still remember fondly.

There’s a statue there that's easy to miss. It’s not in the center, not on some grand pedestal. It sits off to the side, quietly. You can pass by it dozens of times without noticing. One day, I did notice it. It’s a bust of Alexander Lyman Holley. I hadn’t heard of him. But when I dug in to learn more, I realized how deeply influential he was in his field. Holley was a mechanical engineer and pioneering industrialist who helped bring the Bessemer steelmaking process to the U.S. He didn’t invent it. He recognized its potential during a trip to Europe and used his background in science and engineering to refine and adapt it. In doing so, he helped turn steel from a rare material into the backbone of modern infrastructure, making skyscrapers, and with them, modern cities, possible.

That alone would be enough to cement his legacy, but what struck me was the kind of impact he chose to have, not just technical, but institutional and systemic. That’s what lingered: not just his achievements, but how he made others around him better through his generosity, leadership, and commitment to lifting the profession. He co-founded the American Society of Mechanical Engineers and other institutions. Holley brought people of different backgrounds together around ideas that mattered, laying the groundwork for education, professional standards, and disciplinary excellence in American engineering. That kind of legacy doesn’t just grow individuals. It lifts the system around them. And for someone who’s spent decades mentoring one-on-one and working hard to establish and maintain organizational cultures, this resonates deeply with me. This newsletter, in its own small way, is an attempt to scale that kind of work.

I don’t expect to have achieved technical impact on Holley’s scale. But I know the kind of work I want to do more of, the kind that lifts others. That’s something I’ve come to see as worth building a life around. Not for recognition. Not out of ego. And not to chase some grand narrative of legacy. This isn’t a midlife crisis either. It’s a quiet conviction that this matters. It’s the most personal reason I’m starting this newsletter: a way to use the experience and some of the time I have outside my day job to serve a purpose larger than myself.

That experience, walking by this statue so many times and never truly seeing it, taught me something I didn’t expect. You have to notice. You have to stop and wonder. You have to carry a kind of curiosity with you to really appreciate and learn from what’s around you. As I mentioned earlier, Holley didn’t invent the Bessemer process. He was traveling to study the railroad industry, but he paid attention, saw something others didn’t, and recognized its potential. That kind of perception isn’t loud. It doesn’t announce itself. And that’s part of the point. In a world that constantly pushes noise at us, information, opinions, answers, it’s easy to forget how to look. How to slow down, notice, and wonder. But curiosity is where everything meaningful begins. Growth, understanding. Even connection.

That’s another reason why I’m starting this newsletter. I’ve spent more than two decades in engineering, and the more I learn, the more I see how much still depends on curiosity and human connection. At Amazon, where I’ve spent a significant part of my career, "Learn and Be Curious" wasn’t just a leadership principle. It became a habit. This newsletter is a way for me to stay curious, a little uncomfortable, and open to learning in public.

To reflect. To explore. To wander. About what it means to lead. About how people grow. About how I still need to grow. Writing helps me pay attention, to the ideas that pass by quietly, the moments that might get overlooked, the questions that don’t always have answers.

This newsletter is a place for me to think out loud and maybe, occasionally, to offer something useful to someone else walking a similar path.

If you’re here, I’m glad you found it, and I hope it makes you pause, however briefly, to reflect.

So if you’re early in your career or even just feeling early in your thinking, here’s a thought: pay attention to the quiet things. Ask questions even when you’re not sure what you’re looking for. And when you find someone who makes you better, thank them. Or better yet, try to do the same for someone else.

That’s how this starts.