The Pragmatic Engineer - How to work better with Product, as an Engineer with Ebi Atawodi

Episode Date: April 30, 2025

Supported by Our Partners•⁠ WorkOS — The modern identity platform for B2B SaaS.•⁠ The Software Engineer’s Guidebook: Written by me (Gergely) – now out in audio form as well.—How do you get product and engineering to truly operate as one team? Today, I’m joined by Ebi Atawodi, Director of Product Management at YouTube Studio, and a former product leader at Netflix and Uber.Ebi was the first PM I partnered with after stepping into engineering management at Uber, and we both learned a lot together. We share lessons from our time at Uber and discuss how strong product-engineering partnerships drive better outcomes, grow teams, foster cultures of ownership, and unlock agency, innovation, and trust.In this episode, we cover:• Why you need to earn a new team's trust before trying to drive change• How practices like the "business scorecard" and “State of the Union” updates helped communicate business goals and impact to teams at Uber• How understanding business impact leads to more ideas and collaboration• A case for getting to know your team as people, not just employees• Why junior employees should have a conversation with a recruiter every six months• Ebi’s approach to solving small problems with the bet that they’ll unlock larger, more impactful solutions• Why investing time in trust and connection isn't at odds with efficiency• The qualities of the best engineers—and why they’re the same traits that make people successful in any role• The three-pronged definition of product: business impact, feasibility, and customer experience• Why you should treat your career as a project• And more!—Timestamps(00:00) Intro(02:19) The product review where Gergely first met Ebi (05:45) Ebi’s learning about earning trust before being direct(08:01) The value of tying everything to business impact(11:53) What meetings looked like at Uber before Ebi joined(12:35) How Ebi’s influence created more of a start-up environment (15:12) An overview of “State of the Union” (18:06) How Ebi helped the cash team secure headcount(24:10) How a dinner out helped Ebi and Gergely work better together(28:11) Why good leaders help their employees reach their full potential(30:24) Product-minded engineers and the value of trust (33:04) Ebi’s approach to passion in work: loving the problem, the work, and the people(36:00) How Gergely and Ebi secretly bootstrapped a project then asked for headcount(36:55) How a real problem led to a novel solution that also led to a policy change(40:30) Ebi’s approach to solving problems and tying them to a bigger value unlock (43:58) How Ebi developed her playbooks for vision setting, fundraising, and more(45:59) Why Gergely prioritized meeting people on his trips to San Francisco (46:50) A case for making in-person interactions more about connection(50:44) The genius-jerk archetype vs. brilliant people who struggle with social skills (52:48) The traits of the best engineers—and why they apply to other roles, too(1:03:27) Why product leaders need to love the product and the business (1:06:54) The value of a good PM(1:08:05) Sponsorship vs. mentorship and treating your career like a project(1:11:50) A case for playing the long game—The Pragmatic Engineer deepdives relevant for this episode:• The product-minded software engineer• Working with Product Managers as an Engineering Manager or Engineer• Working with Product Managers: advice from PMs• What is Growth Engineering?—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

So you worked at Uber for a long time. You worked at Netflix. You're now working at Google. What are patterns you've seen truly standout software engineers be like across these companies? So they are, one, students, they always be learning. Two, they're willing to roll up their sleeves and get their hands in it. And then this final piece, which is that the conviction, like, they have a strong opinion. They have convictions where they say, like, this is the way.

They're not like wobbly, like, maybe whatever. They're willing to have skinned the game. But they're also willing to be wrong. Be like, you know what? Actually, I take a bit. back. Actually, I didn't realize it. And then of course, there's some other tactical things like they're actually able to communicate. I don't mean you need to be able to go on stage and present or whatever. But you can just talk human to human. You can have a conversation. And because it's so important,

even if you're like shy or task turn, you're able to kind of distill what you're saying into simple terms. And the ones I love the most are the engineers that don't make you feel like an idiot. Do not be afraid to get your hands already in code. Because there are the things that apply to everyone, but the people who I've seen fail at teams who look good is they just talk to talk, but they don't get involved for whatever reason. How do you get product and engineering to work really well together as one team? Ebby Atta Woody is a director of product at YouTube and previously worked at Netflix and at Uber.

As it happened at Uber, when I became an engineering manager, Ebby was the first product manager I worked with, and we learned a lot from each other as our team went through the stages of forming, storming, and performing. In today's episode we cover how introducing things like a business scorecard and doing a state of the union helped the engineering team take more ownership of the product.

How it was surprisingly helpful for us to get to know each other outside of work, and how this personal connection helped us work better together, especially as team leads. Getting funding for engineering projects by secretly bootstrapping these, then showing to the business how much value they were already generating. Patterns and anti-patterns of standout software engineers, and many more. This episode is different from most podcast episodes in how you'll hear both AB and myself talk a lot about our experiences and observations as we got better working together,

and this episode is really about the learnings that both of us had. If you're an engineering leader or a product leader and want to hear about tactics on how to better work with your other counterpart, this episode is for you. If you enjoy the show, please do subscribe to the podcast on any podcast platform and on YouTube. Welcome to the podcast. Welcome. Thank you. Welcome. Thank you. Welcome too. We did end up working really, really well together. Like, I think it was the most productive working relationship that I have. in my professional career. And also it's just very rare to see.

So we turned like this small site in Amsterdam. We kept growing. We kept getting more headcount. And we did that because we kept delivering results. We had just outstanding business results in terms of how much additional money we generated for the business. Two years before, you just came to Amsterdam. You joined as a new PM. We didn't really know you.

Or trust me. I was a new EM. and my team was a bit burned from this massive project and we had a large backlook in front of us and it was just all messy. We just had to build. So our team, during Helix, the rewrite,

we had a clear vision. But before that, most of my team, it was a new team, we called it writer payments, but before it was called APAC growth. And actually in the news that I now have a growth article, which we'll link in the notes below. But the thing about the growth team is, it's not long-lived.

Like it was just shipping individual projects. So I had a team that kind of built a bunch of payment methods here and there. Our roadmap was built like 20 more. There was no coherence. And then you showed up. And then I'll be honest, I was a little upset because the first thing you start to do is you came to a meeting. And this is just strange because I'm just saying how it was. You shared how the product review meeting went really badly.

And I was like, what are you doing? Like you're demotivating all of the engineers. And the injuries were blinking. They're like, what's going on? You were saying, look, if we don't focus, like, you know, we might not get headcount. They're like, are we going to get fired? And I was just sitting in that meeting. I was the engineering manager of this team, again, a new engineering manager.

I was like, what are you doing? Like, what are you trying to do? Are trying to, like, and that was that. That's how it started. What product review is this? Do you remember? I think it was a pretty early one, but I think it was a weekly review meeting. we had? So it was the weekly meeting, so we had a weekly team meeting and you, you attended.

I didn't even know until them, by the way, that a product review existed because the previous product manager has never told me about this, but you told me like, oh, I've just been at this monthly product review. And here's what I presented and here's what I heard. And you just gave us very wrong to us. And you told us some kind of bad news about like how it's, you know, things are in law looking good right now. Yeah, which was a blessing, as it was always a blessed, the candor is always a blessing and a curse. I, I, we both live in, in the Netherlands and people sort of say the Dutch are very direct. And I'm like, they haven't met Nigerians. Yeah, but this is how it started. So I was blinking and I think afterwards, I pulled your side like, maybe like, like, was,

I asked you, are we on the same team? Yeah, yeah, yeah. Yeah, exactly. And, and I think we kept, we kept stepping on each other's toes as well. I remember that earlier on because, you know, I would present something or you would present something and I'm like, and because you had also, there was, as it should be, right? But there was a gap in product at the time. You were stepping in and doing a bunch of things like, like, remember the jelly bean cheat we had with the staffing, which at the end we didn't have that.

But like, at the beginning, it was so important to have context and like, who is doing what? Like I knew, until today, I still make a point of like, who are the key engineers working on every effort? And not just that like the EM, the reports into my director, but like who's the TL, who's the person like really under, you understand what I mean. I don't feel, I don't hold back like needing to ping. In fact, we encourage as we used to do putting everybody in the same chat space so that

the conversation just flows. So I'm literally seeing, oh, I'm blocked on the CL. Like, I can see it, right? And I think that's just, that's just good practice to have this shared understanding. But going back to the directness, maybe knowing what I know now, I've also tried to try to refine my approach to onboarding, right? So there is an element of like, yeah, okay, you can be direct, but trust is given, and then you earn more of it.

This episode was brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine-grade authorization. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand,

and you can ship quickly and get back to building other features. Work OS also provides a free user management solution called AuthKit for up to 1 million-month active users. It's a drop-in replacement for Alt-Zero and comes standard with useful features like domain verification, rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably probably, ones you probably know, like cursor,

Vercell, and Perplexity. Check it out at workoals.com to learn more. That is workos.com. You know, what later happened, actually it turned out to be an amazing thing because before that, what happened is none of the engineers, and as an engineer manager, neither did I, I didn't know a monthly product review existed, that

product managers went there and they presented their teams. Also at Uber, product gave us headcount, which was unusual, I think, maybe some companies worked like this. So we were always dependent on product. And because of this, in hindsight, it would have been really important to know that it exists. What's the perception? What's going on? What's product happening? And, you know, you start to do this every, every month or so. You share it. And we start to understand, oh, what does product care about?

Right. The product team is the combination of all the differences. It's the Eng. Like when you say product, product is you too. And that was something we really made a culture in our team. Like product is all of us combined. There's no, I am waiting for the PRD. I'm blocked on. Product said this. And it's almost like, our product said this.

And we think it's too much scope. And that's not, you know, that is not a cohesive product team actually. Because again, if we were a startup, you would not be using that language. You would not be saying, oh, product said, you'd be going, wait, hold on. Why are we doing that? You would have skin in the game. And so I think what it comes down to actually is, one is there's this, I think in big tech over time, this belief that engineers, some engineers want that, but that engineers want

to be shielded from the reality of what's going on. But actually, if those engineers quit and went to a startup tomorrow to build something, they would want to look at the dashboards and see what was going on and how the numbers were going. They would want to know how much runway we have. they would want to know if, you know, we're hitting the growth numbers. They would want to know which round, you know? Like, you would be as involved.

So why is it any different? And so I think a couple of things happened that we were able to come to. One is a fundamental belief and it took us a while to get there, but that actually we want the same thing. Yeah. And it sounds obvious. We're on the same team. But actually, sometimes I've seen product leaders and engineering leaders, like PM specifically.

So I consider everybody in that group of product leader. the UX, Ux, UxR, data science, but I see PMS, Eng, UX, you know, you see UX say like, oh, I would, I would love to have more polish, but Nge always cuts my scope. Like, the moment you start having those, does the UX person understand that there is literally a mission-critical thing that needs to ship? And actually the polish might add two more sweet quarters, and I would actually love for the, like, my UX partner now at Google is so good at it. He's like, I'm not happy with the way that looks, but let's do that and there'll be a fast follow. Because again, if that was a runway and you needed to ship the product, you would be like, is this good enough to get us customer love and viability and usability and usability? And you'd be able to balance that trade off and you would ship it. You wouldn't hold it back because UX believes in Figma should look pretty and engineering disagrees.

That's not how it works. Same goes for Eng, right? You would not say, actually, I want to do the most elegant way to build this thing. I know there's tech debt that's going to come in because, you know, you would be mindful of the fact that actually there's a real business that has implications. So I think at the core, what we did very well was we also had lots of wins. We also had numbers, how many people were using payments, how many, you know, the conversion rate. But it's actually having a scorecard. We had that scorecard, which is a table with our PZerometrics as we would if we were a startup. And we had the numbers that

we cared about, like, you know, the gross number, the gross number, the cost. conversion rate, the failed payments, the cancellations, etc., percentage that was cash, et cetera, et cetera. And so by making it feel more like a business, so it's not like, you know, products are showing these bad things, actually as a collective, we have a perception. We have not hit our numbers. You create this sort of ownership going back to skin in the game. And now you have engineers even coming up with ideas like we actually should create a web

platform because it will unlock growth bookings because if you look at DoorDash compared to UberEats I mean that came purely from two engineers on the team right? Maybe we can describe it because I'm not sure it'll be clear for everyone. Yeah. It's not not been there before

you know like we like you know we had engineering and we had product and we would have a shared week at the meeting and you know the product manager will be there. We would share the product here's the progress on these projects. Those projects. Okay that would be it. And then we would talk a bunch, you know, the second half of the meeting will be about tech debt. Because it was,

you know, it was a team meeting, but the team was 10 engineers, one product manager and one operations person who was usually quiet. This was before. This was before you joined. And at the time, you know, most engineers on my team, they were very, very interested and focused on paying down tech debt because we had so much. It was just so painful, developer experience, improvements, et cetera. You know, everyone was busy with that. And back then we weren't really cared about promotions because it wasn't the thing just yet. Right. But then you came in and you started to bring, and we started to change.

So first of all, you and we started to, as I was the engineering manager, we started to talk a lot more. Like we actually had one-on-ones, which I never had before with my product manager. Like every week we would spend like 30 minutes of, you know, like what's on your mind? And I would be like, well, you know, there's this person on my team who's having, I don't know, like some trouble and I'm working with them or like this person's doing great. So like you actually learned like a lot about my team. I actually learned a lot about what you were doing. Like, oh, we're having this review about headcount in a month, and I don't feel we're ready. And I was like, oh, can help something?

So suddenly we started to do that. Then on the team meetings, there would be usually a section on product, which would either be like, all right, here's like, here's what we're talking about the product side of things. And initially, it would start pretty soft. So after that first one, it would just be a bit of introduction. but of our meetings, usually always always start with product. Like here's on the product side of things, here's the winds that we're seeing, here's, here's what's working, here's what we're working on with designers, any engineer who wants to be involved. Results, objectives, challenges. That was the format.

Yes. Which is a great format. Uber thing, rock, yeah. Yeah. And then an interesting thing starting to happen, you know, engineers eventually we start to chip in, you know, like usually the schedule would have been like five minutes or ten minutes of product. five minutes or ten minutes upgrade. And often it would just stretch out because engineers on the team would be like, oh, what about that?

What if we did that? Because you're like, and then we got to the point where after a few months, when the next half's planning was coming up on product side of things, actually some engineers got involved of like, oh, let's help the fine. Like how can we, how can I get this project prioritized? And it was like, well, like, if any project that moves this or this and this impact in our case, It was incremental growth booking, so us making more money. At some points, we cared about rider growth in certain areas,

so we can lose money on riders, but we just want to grow, first riders, first riders, turn percentage, et cetera. And engineers started to bring some ideas. And suddenly it felt a lot less of like, oh, here's the list we need to take off. And let's just get through the stuff that we use, so we get to the tech dump. It was more about, okay, let's do the important stuff and let's figure out, do we need to do this? And suddenly it just felt a lot more like a startup inside a big company. This was a $60 billion company at that point.

A couple of tactical things that, not tactics, I think actually strategic things that we did was, do you remember state of the union? Yes. Right. I think state of the union. Can you describe because that's so unique. It's funny because I'm about to do one right now at Google. And I was like, we're going to do a state of the union.

And I think after we had those, you know, those sessions and you and I met up. up, I came to you and I said, listen, I want to take a day off. We're going to go into a room together. We're going to plan a state of the union. And when I had joined the team, I'd had one-on-ones with a different, so it's part of now my onboarding playbook. It was not a playbook then, but I call them conversations, comprehension, conviction. So when I joined, if you remember, I'd met different engineers one-on-one. And I asked one of the questions, my last question is, if you were me just starting in this role, what are three things you would focus on in the next 90 days?

And a lot of them came back and they talked about on call. Remember? You remember? Yes. They came back and talked and I was like in my head. I'm so embarrassed about it. We had terrible on call. I was like,

I have nightmares about it. From everything I've read because I've never been a PM before. I was like from everything I've read, this did not show up in my how to be a PM manual. Like, how is on call something? Like, why do they expect me as a PM to do that? But I recognized, I was like, oh, there's something remiss here. So we then met up. And I still, I can't remember the exact flow, but essentially had the state of the union had one, how much we've accomplished.

And we had this graph where we showed how much incremental payments. And it was the equivalent of some country in the Polynesian islands. Do you remember? It was bigger than a country. It was bigger than a country. And we were like, We've had that much impact. That was like the first slide.

I still remember that. It was like green. And then we talked about like all the markets we had launched and all the payments. So the wins. And then we went into like, we had a team. We went into the dynamics of Uber and the markets. And I remember showing like gross bookings depending on market and first trips by market. And like the trends we were seeing that these markets, Brazil, India, bricks, basically,

were starting to like take off and push. Like a lot of first trips were no longer happening in the U.S. or UK, et cetera. And there were a lot of questions on that, because that then gave them empathy for why all these GMs are like, you are holding me back by not allowing me take payments.

And we ran some numbers on cash as well. We were able to, it was the first time we actually showed cash as a, how much percentage of cash is leading to first, I mean, in that context. Here's a fun fact, because it's been so many years

and the numbers are now clearly out of date, but I remember, is, I'm not sure people talked about this, but when cash hit $1 billion of run rate, meaning on an annual basis, $1 billion were flowing, that team, the team building cash, had one full-time engineer, a half of data scientists, and a half an engineering manager, and a lot of operations people, obviously, but this team was begging to get headcount, and would $1 billion a run rate...

They had to actually beat Uber Eats already, yeah. They had such a hard time. Well, we had such a hard time because this was a team next to me in Amsterdam getting headcounts. So it just blows my mind that this is possible. These days, I think, if a startup, you know, we're talking about startups who are hitting, you know, the AI start up's $100 million of run rate, et cetera, which is incredible. And they're valued a billion. And obviously, you know, they have 10, 20, 30, 40, 100 people. Something like that is still amazing.

But with one one full-time engineer, we did a billion dollars and we couldn't get headcount. Yep. And then eventually we got. but this was just, it showed me two things. One, you can do amazing things with a tiny team. And sometimes, and one of the reasons, and one of the reasons we couldn't get it, we were a distributed site.

We just, you know, the engineering manager and the product manager was there couldn't really tell a story. And I think, you know, that's something that you help with later as well. But I think it just comes to show that when you're inside a company, especially if you're an engineering manager or even a tech lead or a product manager, you really need to tell the story of why your team exists, how you're helping the business. If you get more headcount, how can you help them more?

And just as importantly, if they take away your headcount or get rid of the team, that can happen, what will happen? There's something, I don't know if you remember this, and this is one of the things that I think, till date, I will say, is why I have so much respect for you. So we didn't have cash, right? We had right, brighter payments. Yeah, it was our...

And, you know, Charles, who, by the way, deserves his own podcast, phenomenal leader. It's going to come on here. But we had, oh, fantastic. I feel like I need to do the, you know, like on Diary of CEO where you leave a question. I feel like I need to leave a question for him. But anyway, so he had basically that site, right, from an engineering perspective. And I think one of the things we did, so I went in, like at this time, the PM for Cash was not reporting into me.

But we went in a room. I remember it was the sleeping room, the nap room. Because it was the only room you could get for that long. Yeah. No one. Nap was for meetings. And it was me, him. data science lead, also Dutch guy, and we just jammed about sort of cash and its problems.

And we realized, we grouped them into like basically three buckets. One was basically do the right thing like trust and safety and the issues. The second one was actually, there were a bunch of things on cash that actually were because of the way the system was designed. So Uber systems did not have to think about marketplace systems, Uber's marketplace systems, did not have to think about low latency for payments because guess what? you'd walk out the car and you could afford to have two minutes before your payment goes through. But with cash, you're sitting in the car.

And actually, the way the business had told the story was there's a problem with cash. There all these is your cash. But actually, when you broke it down, it wasn't actually cash. Cash was just showing an underlying issue of a latency issue with the marketplace team. So actually, that gave us a narrative to say, hey, there are some P zeros that need to be fixed at the business level. Up front pricing was another one, right? But then it was the final group of things was actually cash itself

and improving the experience. But something you did, and you maybe don't remember this, was we then put, we said, let's put all the headcount back into a pot. And we all collectively agreed that cash was the number one thing. And you actually gave.

Charles did that. Well, I mean, but I was there. But you didn't fight. You were like, I agree and it's the right thing to do. And I remember we're sitting in that big room and some of your engineers moved over

to the cash team to fund that effort because we're like, we're not going to keep, we're not going to get the, wins and quite the noise until we fund this effort looking holistically. But going back to, so yes, so going back to the State of the Union, the other thing that we did was, and I still find it hilarious that you agreed to do this at the time because I don't know if I knew what I was doing.

I was like, so this issue came up in my conversations about on call. Can we tell a story about on call? Do you remember you were like, I'm going to go look up some, what do you want me to tell? And we jammed on the topic and you were like, okay, I can tell the story around. what's the source of the on call. And a big one was like flakiness and regressions, like the two chunks. And that's how we prioritize some of that work.

So we had three things in our planning, right? Now our weekly cadence. And I really have become a bit obsessed with like rhythms in teams. Because I think humans are hearts. Things work in rhythms. And the more you have a rhythm that doesn't break, the more people are in a groove, right? It's like if I start snapping and you can dance to my snapping,

you can now do funky things in the middle of the snapping, but at least you know the steps, and we all look like we're, you can speed it up, you can slow down. Yeah, right, but still on the beat, on the beat. And so one of the things we had with our rhythm was we had our one-on-one, then we would have, I still have this dynamic, by the way.

I call it, I call it like, it's like zoom in, zoom out, zoom in. And so I would, we would meet, you and I would talk. We would also talk about personal stuff. We would. I remember telling you about like my early dates. I remember you, you know, you were telling me about. your wife starting to learn HTML. Like, we would talk about it before the kids.

We would talk about personal stuff. And we had to also allow space for that. Because sometimes it's like, oh, let's, anyway, moving on to the topic. And it's like, actually, that stuff is important to understand who the move behind the role. And, you know, like, there was a point where I felt that we got closer. Because look, like, the way I looked at it, I'm just going to be honest, like, I felt like, I was there. I was in this new manager role.

I had so many things to do. You know, I had stuff to do at work. I was in a new country. I had to take care of that stuff. All the things. I had a lot of, I was trying to keep the people happy on my team. I was trying to keep my leadership team happy because we had injury managers. Product was very separate.

It was the different organization. And, you know, you came in. We started to initially, I was like, okay, what is this person doing? And then I started to kind of understand. But we kind of kept it out the like, okay, you know, like you're helping us. The way I was thinking you're helping my team, you know, do better work. That's great. But one breakthrough was we actually just went and grab dinner.

Yeah. And it was supposed to be, I think, two hours. I think we saved for a lot longer. But I just got to know the person behind the product manager. Which is my second principle. There we go. So principle number one is the roles, like the roles are a construct. And actually the magic happens. Like Lori design manager that we got at the end, she was used to say the magic happens in the confidence of our differences. And I've totally stolen that line because it's true. Can you repeat that?

The magic happens in the confluence. of our differences. That's beautiful if you think about it, right? Or you think about the Steve Jobs throwing rocks in a washing machine. The more we tumbled together, the more you and I came out as like perfectly polished pebbles. And actually, if you think about that friction as something that's good, then actually we're polishing each other and we're getting stronger versus I think a lot of people think

of the conflict as adversaries. Which actually, it's that tension is an opportunity, that friction is an opportunity, that pressure is an opportunity to be better, to create the diamonds. And that's what we did. So we had the one-on-one where we would sink and we would go on a walk and et cetera. And we started making it a thing of having periodic out-of-office dinners or I came to your house. Right. So we made that a conscious thing.

And that's my second principle, which is you really need to know the human behind the role. Like I just sent you a message, you know, for your birthday because it's in my calendar. And I actually say this all the time. And, you know, I'm like, do you know your engineering manager's birthday? And people literally give me a blank stare. And I'm like, that is literally the day this human showed up on this planet. It is probably the most important day to them. And you don't know it?

So what are we doing? How are you going to have a joint vision and goal if you don't even know that? And I think we're so simple. But we could generalize that as an engineering manager or as a team lead, the people on your team. Like what are they, you know, we remember, I remember when, you know, I became the PM lead. I knew when people wanted. to we're thinking of having kids. We're trying to do change mortgages.

Where, you know, as, you know, one of them had just moved a girlfriend from his home country and was moving in. Like, because that human is going to bring that into work whether you like it or not. You can say the whole leave, the personal stuff. That is not how humans work. We're not, you know, confined boxes. We don't work that way. So that's one of my second principles, which is like, and the third is this notion of, like,

the rhythm. And people take that for granted. Like, we never moved out one and once. You never like randomly canceled one-on-ones with your teams. Neither did I, right? Like, we had a cadence. And I can't stress that enough because humans are creatures of habit. So we would have that one-on-one.

We would talk it out. We would then have the team meeting. Then we would have the planning meeting where it would be you, me, and the other PM, remember? And we would come in and talk about like, who's staffing what? What are the concerns? Who's about to roll off a project and do we have enough? We would talk about things like, oh, this person's just been. in a slug doing this.

We need to give them something exciting. Remember, we would talk about that as well. So basically, it felt to me that after a while, I was the injury manager. And, you know, like in the end, it was my responsibility for, you know, someone to be fired for whatever on the team that would need to be me. But it felt to me there was we had, like you and then we had another PM. But you and me, we were kind of like being injury managers together a little bit. And being PM leaders together.

And actually, it worked wonderfully. So, for example, you, like, I would tell you whenever I saw, you know, good things or bad things about people on my team, for example, like I knew when people were, for example, looking for a new job outside of work. And I kind of both checking out or also looking for something new. And by the way, maybe I shouldn't say this, but I kind of encouraged it. I was like, look. I mean, I encourage it till today and I still work at Google. I'm like, it's so important. I actually say at more junior levels, you should probably have at least a recruiter conversation.

once every six months. Because here are a couple of things. And let's just cut the BS and get to it, right? I've had to let people go at Uber. We've all had to let people have a performance conversation or we've had to talk to somebody who wanted to go on to something else. And for example, one of the PMs on my team,

who you know, you know, he came to me a year before he got the role. We were literally having conversations about the right role and whether as he's interviewing for those roles, is there something in that role where he's like, Uber doesn't offer that? And after we got that, we're like, okay, I think it's time.

Actually, we've exhausted everything and it is the right time. But also because we've been openly talking about it for a year, you genuinely know I care about you, right? And you genuinely know that you want to leave this place in a, you want to leave your role in a, sustainable place. So we very nicely set up his dotted line who now stepped up into that role, who's now a head of product at booking.com, but like who stepped into that role nicely because we already knew it was coming. So I have this fundamental thing which is like the human transcends

the job. Right. And so it is your your goal is to help them realize their full potential. It's not to realize their full potential in the job because their full potential may not be in the job. But actually, if you come at it with this altruistic, I deeply care about you, they will feel that. And that actually works in your benefit over time. They may leave, they may come back. And so. And also, one thing that I feel, it was an accident, but we got to know each other on a personal level. You would often advise me.

And I would do the same thing on product, right? I would be like, oh, here's what I think we can do. Let me take some things on your plate. I had some engineers on my team. I wrote an article called the product mind of engineer, which is, you know, I get some good feedback for it, but honestly, was describing some engineers on my team. Some engineers, as soon as we started to do these, you know, you, you know, you see their names. Yeah. So do I, you start to tell, like, here's the metrics, here's business. Some engineers, you know, some engineers didn't care

that much and that's fine, but some were like really like, oh, okay, how, how can we have this wins? How can I help the business? You know, they love doing this thing. And they came with ideas. They came with ideas. And sometimes when you tell me, like, oh, I'm kind of swamped or, or we, need to do this but I don't have time. I'm like, oh, this person, this engineer would love to do it. So suddenly, like, our, and a lot of it felt that it was about trust. And one thing I see now, I think, you know, if anyone takes away something, if you're an engineering manager, a tech lead, a senior engineer, or even just an engineer, try to, you know, build, like, just trust the people around you, you know, build trust, like meet them outside of work, your product manager or people

on the team, because here's the interesting thing, you know, the, I feel these roles are. are kind of made up. I'm just going to say it. Like, what I did as an engineering manager, you would think it's like in a box. And there were some things that were expected of me, but especially the startup, it's made up. And AI will change a lot of this thing. But what will not change is if you trust some people, you can figure it out. So one of the reasons, you know, our team works so well. And we actually didn't have anyone quit on the team, like on over four years. That is crazy. We had no attrition. And I think we should pause and let the saints flow in the,

Well, in the four and a half years, I was there. So we didn't have anyone leave Uber. We did have, I think, there's two people who the team was just not a good fit for them. Like it was, they weren't meant to do product work. But once we got that stable team, literally it was that team for four years. And it's not like there's some cities where they're like no other options. This was around in a climate where you had like stripe coming in. You had, you know, flex port.

You had, you know, all these these data bricks. Data bricks. So you had a number of, you had opportunities. And I think at a certain point, then we now got to a point where it was like the pandemic, especially, it was like, okay, now it's time. People have kind of maxed out. And also some of the stuff we wanted to do was scaled back. Even I, like a year after I made the decision, I'm like, I have a clear number two. And she was brilliant and stepped into the role.

But it goes back to this thing that I think is at the core of it, which is when people, people love, and I, like, not just loving. So there's a definition of love that I like because I'm about to contradict myself by saying I like, but like, I'm not a fan of liking things, right? Because liking things feels very passive to me. And I like things, you know, I like things, but actually even better, I love things and I dislike and hate things, right? And so, and I think about that.

It took me a while as a leader to actually, you know, accept that about myself as well, that not everyone's going to love it. Like some people are not going to love this way of working. Some people want to be mentally checked out, just do the bare minimum and work is work. And some people, it consumes them. And we managed to get a team, like most people on that team, even those who thought they had started numbing, became more product-centric because it was just in. infectious of people around you are like, you know, so infected with this in love with this problem.

And love at its core, I use a definition by Bell Hooks. And she says, you know, love is the extension of oneself for the spiritual growth of another or of one self. So self-love is, I'm extending myself, I'm going out of my comfort zone. I'm reaching and doing more and being compassionate so that I can realize the full growth of myself. That's self-love. Or I care so much about Gerge. I'm extending myself because I feel like I love this person

and I want him to reach the attainment of what engineering manager means and vice versa and I genuinely felt that. And I feel like we had that in the team. To the extent that I did the, I officiated one of our engineer's marriages. You know this. Like, are you kidding me? You know, that's the height of my, like, you're such a friend and the love is so strong

that I literally read the vows of you and you, like, that is, you can't, you can't, there is no price. There's no, you can't, like, there are no words to describe how you attain that. And that's all from this team, right? So, yeah. I do think that there's this element of like, you know, when you. you have the right people, even when it's a small group of people who are willing to put skin in the game because they love a problem and love each other, there's so much magic.

And I mean, we have a whole roster of things to show for that. Do you know how many, like when I think back, the amount of vision stuff that we, the API that now processes over a billion dollars, you know this, by the way. Yeah. The Uber pay, which for multiple years, everyone said would never work. Yeah. The web payment flow, which at the time were like only 2% of traffic was going through web. And that was two engineers.

Who will I come up with the idea and a business plan. And we kind of ring fence them and let them build it up. So what happened is I tried to, I asked for headcount for the for it to get web payments because it was a really, really good. You know, they brought it. They actually put a business plan together. It was awesome. They had locks. You said it's great.

I said it's great. I asked for headcount, you know, from my, my management chain. or from product, whichever it was. And they said, that sounds great, but no. And so what I did with your support because, you know, we just trusted each other. And we're like, I mean, we did. So we just did it. We hit the two people.

We still shipped every one of our product. And then we came back in six months saying like, oh, so we've now built this. We have this many customers. We now like this many extra hat kind. And here is the business that we're driving now. And if we, you know, if you don't get it, like we have to just shut it down. And they're like, well, okay. I guess that makes sense. Yeah, that's a no-brainer.

Well, even more, like, that's a little, there was a, another policy thing that came up because, you know. It starts becoming bigger and bigger company. But, you know, and especially the EU was everything, a lot of policies. And there was a policy that was coming up in France. Oh, yes. Do you remember? Yeah. And we were like, holy cow, how the hell are we going to add this to our road.

Yes. And never mind the cop. We won't talk about the comment, the PM left, who I will, I will. will stand by till today for craftsmanship. Like this team came and said, you have to build this thing. It's a directive from Dara. And the PM said, they edited the comment later on. I saw it was edited.

I wanted to screenshot it and save it. And he said, I don't care who came up with this. It is a bad user experience. And I don't care of you give me Dara's name signed in blood. I am not approving this. And I was like, wow. Like, do you know what it takes? Do you know how much skin, how much guts you have to have in your decision to

that. But anyway, he said he did that. It just showed you the kind of love we had for shipping the right product. But maybe don't say CEO's name and blood next time. But anyway, these two engineers then came up and suggested building instead of, because Uber Eats had built their own like a flow which didn't have the policy stuff that we needed. And they were like, okay, we're actually going to build this and use it as the web platform that everybody can use across the different products. So they actually used a real problem, which I think is a very important thing that people miss when it comes to vision setting and getting a win. It's that it's very hard, actually, even at my level, to come up with something that is novel, right, that no one can see and somehow magically, miraculously get the blessing to just go off and do it.

So you're specifically talking with getting cat count for a team, may that be a platform or a product. Even at my level, it is so hard to pull that off. What you do, I'm a director of product. Like my skip level, sorry, my manager is a VP. That's like into big tech. That's the height of it, right? Yeah, yeah. There are only like five SVPs at Google or something.

So like that's the height of your career. So even at that, it is so hard to say, I'm going to ring fence five people to go play around with this new thing with no direct, like no direct core problem. The best ways that we, you and I always got visions off the ground was we took a problem. So in the case of Uber Pay, well, they needed us to integrate a payment method. And instead of just building that integration, which we would have done, which took, I still remember until today, 14 weeks of engineering. We have the lingo. We said, actually, we're going to use it to bootstrap this API, integrate this partner in Latin America. We'll still give you the thing you want, but use this slightly longer to get you something that actually unlocks many more payment methods.

And we did that every single time. Before we jump back into the episode, I want to let you know that the audiobook version of my best-selling book, the software engineer's guidebook, is out now. You can get it on all major audiobook platforms like Spotify, Audible, liberal.fm, Apple books, Google Play, and also DRM-free mp3 files. I started writing this book after a decade of working as a software engineer when I was working as an engineering manager for a few years already at Uber. Here's a review from the book from Senior Principal Engineer Tanya Raley, who is the author of the staff engineer's path. From performance reviews to P95 latency, from team dynamics and testing, Gargay Divisifies All aspects of a Software Career. This book is well named.

It really does feel like the missing guidebook for the whole industry. You can get the book at EngGuidebook.com or search for the Software Injured Guidebook on your favorite audiobook platform. I hope you'll enjoy it. And I think this is a tactic. I've gotten a lot of questions, especially since I wrote the book, building mobile apps at scale about how to fund a platform team. And a lot of Engine Manager's assets, like I'm now growing up.

I would like a platform team. How can I fund it? How can I make a business case? And there's a template. But I think the secret to funding any engineering team is build something without funding and then show it. May that be a prototype or something, but show that it's going to make money for, if it makes money for the business or it saves money for the business, you should have a case. Or growth or whatever. And if it doesn't do either that they care about, then what's the point, right?

Especially these days now that companies are paying about a efficiency. value add in doing it once, and yes, you always have to trade off like our design. You're always trading off relevance versus consistency. You may not get the 100% optimized version for your specific use case, because ultimately what is platform? A platform is a stage that allows multiple teams dance on it. So each person isn't building their own podium, right? Like that's how I like to think about it.

If no one is dancing on your platform and you can't, you know, then we'll, we'll, Why do you exist? I might as well go build my own stage or if I don't need one, right? Then actually we don't do platform for platform's sake. But in this case, we're like, we're going to give you a stage, this web platform thing. It works. We have a proven case. And it means that you don't have to waste your resources building that platform again.

Just dance on it. And it's like, you know what? Maybe I need to share it with other people. Maybe it's not exactly what I wanted. But actually, I can go use that extra resource to put more lights or change the outfit or whatever. I mean, I like using human analogies for these things. But I think that's such a crucial thing because when we go back and look at all these things that we bootstrapped,

we always used a very small example of a problem and turned it into something that we actually wanted to realize in our vision. Yeah. Right. And so in a way, at the worst case, if you think about it, you've solved the problem still. Yeah. Best case, you've actually built something that creates a billion dollars. No. Right?

Like, like, yeah. it's kind of win-win. Yeah, and I think it's good to remind, like, you know, anyone working in engineering that it's not supposed to be easy. Like, it's not supposed to be easy to get headcount or do a new initiative. So, you know, you put it in the work. You have to show, if I went and said, it's a very different game. So when you're raising pre-seats, so I do a lot of angel investing.

And I actually do it. Honestly, I've lost way more money than I gained, which is part of the thing. But actually, I do these things because I like to say, see what parts of something I've learned a skill or, you know, like knowledge. I like to figure out how much of this is a pattern that is reusable. Like I can reuse it versus how much of this is something that's just contained in what I'm doing, right? And so my onboarding flow, like, you know, conversations, comprehension, conviction, I have used that to onboard into many roles. I've used it my board position. I've used it at Lego. At Lego. I used it the same framework. I've used,

you know, like I even, I remember sitting with the chairman of the Lego board, the fourth generation. I was like, for the first month or so or two, it's going to, I'm going to look dumb because I'm just going to be listening and tell me who I need to talk to. And I asked all of them similar questions. Same playbook. Then I came back. I was like, here's what I understand. And then I came back and said, here is what I fundamentally think we should be doing, even though, you know, as a board, You can have conviction, but ultimately the exec team is the exact team. But I've used that. I also used it when I took on my ERG chairmanship within Google.

Same playbook, different people, nothing to do with tech. So I'm like, oh, this thing is a rinse and repeat. So now I can teach someone that playbook and stand in it. Same goes for like vision setting. I did vision setting in my GM role. I did it again with our state of the union, right? I did it again when I joined Netflix. I did it again when I joined Google.

Now it's worked so many times. I'm like, oh, this is a playbook. Like, I know I have a playbook here. And I know what doesn't work and what dyn, things, knobs I need to twist. Same goes for like fundraising and what I call perception shifting, which we had to do. So I had to do a lot of that within, like when I joined Google, the team I inherited, there was a lot of perception, not reality. Some of it was reality, but a lot of it was perception within the organization.

They're difficult to work with. They block. We had very some of the things at Amsterdam. Like, oh, they're difficult. They hold, you know, they block. they're this and it's the same playbook. I've used it again. I'm like, okay, quick wins, go and tell a story, consistent monthly updates. We had that, the Amsterdam newsletter, which had the Amsterdam pictures and like fun facts, right? And something that is engaging.

And then also like this actively road shoring. So we would go and meet the GMs. Remember, we would actually have this meeting to share the plan and have it blessed by like the VPs. same playbook. I have a plan. I do a road show with all the partner teams. Remember the first couple of years, my partners were like, oh my God, that's very expensive. I'm like, trust me. It's one day you will spend. You might think you're wasting it. It's multiple meetings of escalations you will save because you have a shared language and they understand what else you're doing. So not everyone thinks there is snowflake and like, my thing isn't getting prioritized. So I look for these patterns and what you tend to find is actually,

a lot of them scale beyond even tech. Well, but a lot of them really scale for entry management because I actually got the inspiration from you. So when I would go to San Francisco, the first few times I went to San Francisco, I would just, you know, like, just do like we work with a few teams in San Francisco. So I would meet with them. We would like, you know, talk about stuff. But I kind of saw that when you went, you met a lot of people.

And so what I started to do later, which turned out to be a really good decision is when I went, I actually prioritized meeting people and understanding them, telling them what we do, understanding what they do and trying to get to this point where we had like, you know, just tell me who are you? Like, you know, what is your background? Like, how did you get into Uber? What do you want to do after Uber? Like, you know, are you trying to, is this temporary and you're trying to, you know, be a CTO one day or you're actually really into it? And it's just it. And since I started to do that, I kind of, it felt cheating because I was not doing work per se, but it made everything so much easier. This is such an important point. This thing that you say, it felt like cheating. Like, we should actually unpack that a little bit because we've been conditioned.

Now, I'm going to, you know, A, B, the sort of like a philosophy. I'm here for it. I think we've been conditioned so much to like squeeze out efficiency. Like, I go in nine, I clock in. We get in room 30 minutes. It's like, let's get into it. And actually, that's fine. And I'm a big believer.

I actually think I'm highly efficient. But I go slow to go fast. So we might be in a one-hour meeting. I literally just met a UXR lead on the team. Never met him in person. One of the things I like to do, I'm not saying we want to do that. And maybe, you know, like I hug everyone, as you know,

I hug everyone. Because I'm always on a screen. Right? I'm always on a screen. 90% of the time I'm going to be talking to people on a screen. Like, you know, over continents, time zones. In podcasts. Except for that.

This is my second. person podcast. Can we do more of these? But like, you're always on the screen. And it's, if I meet you and for 30 minutes, I've come all the way nine, nine hours. And we spend that 30 minutes talking about something we could have hashed out on an email. You failed. For me, we failed. Instead, it's 30 minutes to see your body language. It's 30 minutes to understand this human, to hug them, to bring the 3D, the 4D, right? And we can go back and do the efficient stuff. by email. But how much more efficient will I be when I'm pinging that person a very blunt, you know, I'm horrible. I don't even do like, hi, I just get into it. Like I'm really, you know, I'm like, I just get into a message. That's how efficient I am. But when I meet you and I spend that time, whether it's a dinner or a lunch and it's a human connection, we will do so much more and go so much further on in the document when I say, I disagree with this. Because you've met A.B. the human and I've connected with Gerge the human that I disagree with this is contained into the

thing we're talking about not how dare she once again and egos and all of that so people think they're being efficient they go in a meeting five minutes how are you how's your weekend this sort of nonsense small talk and move on when I've been in meetings where I'm literally like how is your weekend and I have something in my weekly meetings where we say what's your personal win and someone was like I got married last weekend none of us knew it would never have come up right? I mean, this is this is not my core team. This was like a team I had just inherited for

one of the ERGs at Google. And then we were like, the rest of the meet, like for 15 minutes, how was it? Share us pictures, da-da-da-da. It was, you just had this little spark. And then we can go to the rest of the meeting. But you will never that those moments you just can't trade those. So I want to go back to it's not cheating. Like that's just,

it is not cheating to connect at a human level. Right? In a way that's comfortable for you. in working hours. Yeah, because that's what it felt. You will do so much more and achieve much more without the squabbling, the bickering, the, you know, whatever, because it's not a zero-sum game. It's a reminder that we're two humans at the end of the day

who are in this construct of a company because we both believe in a common goal. And if you can just remember that, so much more will be effective. So can we demystify? Let's normalize connections during working hours that are not about like some efficient whatever. And then your meeting might be five minutes.

And so you mentioned patterns that you've seen, but one pattern I'm interested. So you worked at Uber for a long time. You worked at Netflix. You're now working at Google. What are patterns you've seen truly standout software engineers be like across these companies? Like not at Uber, we had a team and maybe it was special, maybe it was not. But are there some kind of behaviors, either skill sets or things that people do that make them just a great engineer? Someone that you as a product manager are like, I can work with this person at either of these large companies. I'll start with the opposite. Let's just contradict for a second.

One pattern is everyone in their gut knows intuitively when they have encountered a genius jerk. Oh, yeah. I remember the ones I work with. And 10 times out of 10, remember we used to have a director, Daniel Isson. This is one thing I loved about him, and I still hear his voice in the back of my head, right? It drags the entire team down. So much. They might have brilliance in code and brilliance in execution, but when it comes down to it, those genius jerks, the net effect is exponentially worse.

than not having them. So I'll just start with that. And it's consistent across all the businesses. Different businesses have different tolerances, but it's consistent across all the businesses. Now, I'm packing that a little bit more. There are some people who may manifest as jerks. But actually, they've never been told.

And the moment they're confronted with their jerkness, they correct it. So we've had certain PMs who may come up abrasive, but actually they mean well. and when you actually have a conversation, you're like, oh, the human is a good person. They need to work on their comms. So I also want to, like, that's the second thing.

So you see these brilliant people who are not very good at like the social skills. That is different from a jerk. Yeah. Right. And you actually intuitively know the difference. Yeah. So that's the extreme.

I want to start with that because that is so important to remember and to state because our time on this world is limited. And I just don't think anyone deserves to be in an environment with anyone who makes them feel less. than period. No. Now, going in terms of the good patterns, I think the ones I have seen, and this is irrespective of, I'm talking from VP all the way down to like L4, I see, there's a pattern that you

see, the tracks, right? So I'm literally thinking in my head of like personas right now. One is they never stop learning. So my inch partner now, she, over. Christmas was like, I feel like I'm not up to speed on like the latest on the models. I'm just going to go spend some time and play with it. I remember like Daniel Isson, he would be like, I'm going to go write some code. I'm solving some lee, sorry, what do you call it? I'm not lea coding exercise, right? When I was building some side project. Right, building some stuff.

And this was the director of engineering, senior director of engineer, something like that. Phenomenal guy. It wasn't to everybody's liking or taste, but I loved it. Love him because like this was just a human who cared deeply. And this is actually a good example of. the second category I was talking about, where the delivery might have come across in a certain way, but actually at the core, it was just a good human. And so, you know, nobody hates it. No one truly loves it. It's what I believe as well. But anyway, but there's another persona at YouTube now that I'm thinking of a VP, been there for a while, phenomenal guy, Christos. And I remember when I join people are like, oh my God, Christos, you know, I don't know, you know, I'm just going to talk about it.

Like, you know, how I am. I just, you know, and they're like, oh, you know, that warning. And I'm, you know, we're in a meeting and he said something and I was like, I disagree. And people ping me later like, oh, no one disagrees with Christos. And I just saw a human who was curious. And we've gone on, like, we don't interact that much, but he's gone out of his way to literally, I, Google with something called spot bonuses. It's a weird thing. I still don't understand. Like, I get it and I'm like, you just gave me money for doing a good job. Okay. But anyway, but it's not so much about the money. It's a token of recognition. Literally my, my, my, you know, I have two spot bonuses from Christos because he's like,

you delivered something that took multiple people tried and failed. It took 10 years. Nobody shipped it. Thumbnail A-B. Thumbail testing. And you guys, you did it. And he, he saw that. And we went through what I just thought was a high friction. Because he was, this, this guy is like somewhere else in the org. And he was. was like, I am concerned about this for creators, explain to me, not his domain, but he cared deeply and never stop being curious. He was like, help me understand. So this is kind of a mix of caring and curiosity. It's curiosity. It's never stop learning. And one thing with Christos is VP, but you can bring up anything. He will go down to the detail. Like he understands it deeply.

And by the way, this, what I'm describing for engineering, for UX, for product, for data science, this ability to understand that you're a student of life and you keep learning. You never get tired of learning. So that's one thing I always see. Even the I sees, it's like, I just found, you know, the ones that send you, hey, I just played around with this new model. Check it out. Here's my observations.

Like this yearning for learning, right? So that's. Yeah. What I would add is at the engineer level, I think, you know, outside of the, the entry manager is a little bit different. But as engineers, they're not afraid to get their hands dirty. So they learn and get their hands down here. And you know, they will not just come like, oh, I've learned this.

They were like, no, like I wrote the code. Right. Here's a poor request that does it. And they'll often, you know, create a bit of a friction where they'll go to a team and they'll be like, oh, we'd like to do this. And a team will be like, nah, that'll take us like two, three weeks, can't do it. And, you know, these people. And the kinds are like, why?

Well, either they'll ask why. And then, you know, they'll get to a point that it's not that difficult and they'll do it. or sometimes they just do it. But they do it in a way where it's not showing off or something. No, it's just, it's like, no, like I did it. Like, can we progress? Or tell me what I'm missing because, you know, you're the experts. And I knew that used to piss off.

It can piss off people. Yeah. Yeah. But it's like, same with my inch partner, Matilda, same thing. She'll be like, I'm sorry, I'm going to call. I'm going to call, this is not passing my sniff test. Why is it two months? And then as they start going in, what you find is you'll be able to help them problem

solve. Oh, because you thought you needed to do. this extra thing. Have you thought about doing that? Oh, okay. Like there was something we were talking about recently. Like, we could just remove this traffic. Have we could, oh, okay, we didn't realize that was an option. And actually, you know, so that's, there's two sides to that. One is, they're willing to get their hands messy and, you know, roll up their sleeves. But the other side of it, which is they're also very comfortable with that being done to them. Yeah. Like the strongest leaders, they're the ones who in a room be like, huh, I never thought about it that way. That's a

a good point. They're willing to call out that they were wrong. Yeah. It's a phone. That's what I, this, this notion of vulnerability to your strength. Yeah, I think they basically, you know, they're competent, but they don't let the ego get ahead of it. Like they kind of put away their ego and they assume that they might not be competent all the time. And it's the same, I think the common, it's like, because you're a student of life and you're always learning, you understand that the more you learn in life, anyone who's a student of life knows it, the more you learn, the more you realize how much it you do not know. Right. like just how much you don't know, you know.

And so if you, but they have strong conviction, which I'll get to in a minute. If I say this is the way to do A, they're open, but you better have a strong rationale, which is where some people buckle because they're not willing, they're not able to have the vulnerable conversation to say, actually I disagree. And then, oh, actually, no, no, no, actually you were right. Right? So most people are like, I'm not even going to defend or challenge them because they have such a, you know, they're so.

clear in what is, you know, you know the type? It's like, you can't challenge them. No, no, no, they just thought about what they're saying before they open their mouth. Yeah. But they're usually open to being wrong. It's just that they've thought about it so much that you need to do the work to rationalize why it's wrong. And they're okay with being like, actually, you know what? Good point. Um, I'm wrong. Like in this case with this example, I was like, you know what I'm going to do? I, I hear you. I understand the feedback you're giving. I don't think it's a concern. but we may be wrong, right? But what I'm going to do is at every step of the rollout,

you're not in my chain. I don't need your approval. But I will send you an email with the metrics that I'm seeing and we should make, let's have a one-on-one or discussion. This is what I did with the VP Christos. Let's have a one on like what you think and maybe there's something I'm not seeing. And both parties are like, my case, I've not been at YouTube for that long.

This guy's been there for like 15 years. Like in his case, he also doesn't know, like, I know what I'm talking about. And so at each step, Yep. Actually, the conviction was correct. But the thing he called out made me think about, oh, these metrics that he's called out that I just need to make sure in the go-to market we solve for. So they are, one, students, they're willing to, they're always be learning. Two, they're willing to roll up their sleeves and get their hands in it. And that usually means you actually need to, like, dog food your own products. Sorry, PMs and people out there. It is not okay to never have gone through your onboarding flow. Like, because. And also, also, also. I'll call out the most efficient engineers were the ones who went through the at Uber, for example, create a driver account and, you know, drove and delivered food. Or even just do the simulator and see what the onboarding flow is like. Or open the competitors app and see what it takes to sign up there.

Thank you. And I think especially in big tech, people get so removed from the product that they just forget to use it. And I'm like, how are you going to have empathy? You're building something and putting it in the world to millions of people. You don't care enough to use it. that's I feel like it's

it's happening but I think it's good that we're talking about it and then this final piece which is that you know the conviction like they have a strong opinion

they have convictions where they say like this is the way they're not like wobbly like maybe whatever they're willing to have skin the game

but they're also willing to be wrong and be like you know what actually I take it back actually I didn't realize I see Matil do that all the time like on meetings she'd be like

oh no I didn't okay that's a good point Oh, I never thought about that. Right? So, but she's also been like, guys, I'm sorry. No, no, no. My sniff test, my intuition. Like, they trust their gut.

So, and that comes from years of training. So those are some patterns. And then, of course, there's some other tactical things like, you know, they're actually able to communicate. Like, you might not be, I don't mean you need to be able to go on stage and present or whatever, but you can just talk human to human. You can have a conversation. And because it's so important, even if you're like shy or task turn,

you're able to kind of distill what you're saying into simple. terms. And the ones I love the most are the engineers that don't make you feel like an idiot. And even at my, you know, I was an engineer. I think I'm actually good at, you know, technicalities. But there's some engineers in a room. They just throw out the acronyms and throughout this and throughout this and throughout the that. And I'm like, you think this makes you look smart, but you're actually isolating yourself. Actually, power is when you're able to take wisdom and I mean, you know, Buddha or Gandhi. They have these very simplistic quotes because they take something that's so complicated, distill it down where everyone can access that information and

that power. And that's powerful. Now, here's the, you know, the shock or whatever. Everything I've just described, I think, applies to every strong person that I have met. The designers, the PMs, the data scientists, it's the same patents. They're hungry. Stay hungry. Stay foolish. They have conviction. I'll just say that for software engineers. What I've seen, do not be afraid to get your hands already in code. Because there are the things that apply to everyone, but the people who I've seen fail at teams who look good as they just talk to talk, but they don't, they don't get involved for whatever reason.

But that's the same with designers who, design leaders who have not opened Figma to actually play with a mock. Yeah. My design partner, Brian, he literally will mock up something as we're talking. You know, I mock up stuff till today. Say close to the tools. I can write a PRD. Like, now I'm not going to be 100% as a fit.

but I can still do it. And that is so important because you have empathy for the person in the role, not just marching orders, you know? So like I really genuinely think it's like these skills. You get better and better by being the student all the time and not getting your hands dirty. One thing that you've done, which was really really interesting to me, is you mentored a lot of my engineers on the team. And they actually grew a lot faster professionally.

It was great. I haven't seen other PMs do it. What are tactics that you suggested to them? And these could be things that an engineering manager could also use a tech lead or even just an engineer who's, you know, like a senior or engineer who's mentoring other engineers because luckily there's more and more engineers mentoring. What works? I know I'm going to sound like a broken record, but I do believe repetition doesn't spoil the prayer. This is a phenomenal example of where the playbook tracks regardless of the role. So it's not just engineers.

I mentor to designers, as you know, on the team. Yeah, you did. Yeah, I actually even managed the team. I managed the design team. Yeah, you managed it. When our design manager went out on parental leave. And then you were swamped. And then you wrote some PRDs for you.

Yeah, I was so swapped. You wrote the PRDs. Which, by the way, is one of the tactics. It's like, care so much about the product. Be a product leader first. You care about the data. science, you care about the metrics, so that you are a participant in what are these artifacts that you contribute to? It's the vision doc. It's actively participating in the PRD. It's, you know, and this would

apply not just for product managers, but for injury managers or anyone who either in a leadership position or thinks that, or wants to be in one. You know, the Oprah Giff, Oprah Winfrey Giff, she's like, it applies. So, you know, and it's not like checking a box. It's, it's, you know, and it's not like checking a box, it's something meaningful because when you now go to that PM that you helped out or that busy partner or that marketing partner or that designer to say, hey, endorse my promo, they are like filming at the bit to do it. Yeah. Because they've seen you actively participate, right?

Yeah. So I think caring about the product in a way where you're also a contributor actively to like the OKRs, the whatever, you know. So when you say caring about the product and the business, right? Why we're here, why we're working here. Actually, we didn't do that. You know, product is, like, three things. At its core, it's the business impact. Yep.

It's the feasibility, the technical, you know, what's possible. Yeah. And it is the customer experience. That's product. That's the definition of product. So when I say we're all product leaders. You never told me this before. No?

I don't know where I read that from it. Oh, it's supposed to say some people call it viability, usability, feasibility. That's what we used to call it back then. Yeah. I like the second one better. And that is actually why I like to say we are all product leaders because there is no product if I come up with a shiny UX mock and it will be great for the business. But engineers are like, this thing is going to take two, three years.

But I think this is just really good to think about because these days I feel more and more engineers will become product people. Because for example, you leave your tech company, you have a lot of savings, you start a startup to build a product. You're a product leader. You're now a product leader. You join a team where there's not a product manager. Either you become a product leader or, you know, like you're not. Like, I mean, there are multiple founders, but linear that, you know, we remember working with him.

They hire for product sense and taste for all of engineers. And the reason they have so few product managers, they now have one or two because everyone is one. It's working. Yeah. Yeah. Which makes it that more, this is another podcast, but that more, that much more. much more important that I used to say this, you remember me saying this, if you take a PM out from a project, there should be an order of magnitude exponential effect. It's not like you went from 9 to 10 because we've worked with Eng leaders. We had people on the team who could do the 9 to 10.

They were really thoughtful in sending the updates, in, you know, the stand-ups. So a PM comes in, your goal should be like an order of magnitude. And so in a world where like, what do PMs do? I'm like, if you are going from 9 to 10, you need to go rethink what you're doing as a PM. It's like it's exponential. It's not immediate, but it's exponential. So going back to like this stuff,

I think one is be a product leader. Now we all have the same definition. And that means you understand the business implications. You understand how the metrics that you move ladder up to the core businesses metrics. Like there's a direct correlation. We knew how. We knew how incremental or whatever moved Uber's numbers.

I think the second one is treat your career like a project. What do I mean by that? Most of the time, I'm not a fan of when people reach out to me like, hey, I have this issue. Can you be my mentor? Sounds horrible, but nine times out of ten, I don't even engage because I just don't know enough about you to help you. I think mentorship and I've become more of. a big believer in sponsorship, which is even more important than mentorship, I think. So I didn't do, I didn't, I met everyone on the team at the beginning, but over time when I

became more of a lead of the, the, the, the, the, the, the, the, the, um, those kind of ambassadors of the product. The ones that I knew were like at the top, top fifth percentile, who they could have an exponential effect. They would come to me and tell me, something is wrong with the architecture or there's something. And then I would catch it and that's where we did the architecture, a sprint. Remember, to redesign the stack. But that came from a one-on-one walk with an engineer flagging it, right, who cared enough to bring that to me.

So I start thinking more about sponsorship, which is like, I'm a voice for you when you're not in the room. No. I am, you know, helping you sort of get to the next level. It's not just fixing skills. It's like we're actively getting you to the next level. So I start to say, you know, look for sponsorships instead of mentorship. But your sponsors and mentors should be people who are deeply aware of your work.

It's not some random person online that you message on LinkedIn. That's not, you know. So when you have that, your career becomes a bit more like a project. Because if this was a project, you would check in on a weekly basis. Maybe you'd have monthly updates. You'd be aware of what the results are, what the challenges are, what the objectives. know, PPP, progress plans, problems. Too many people have that conversation when it's too late.

After you've gotten your rating and they're like, oh my God, what did I do? It's like, actually, why don't you have an active forward-looking conversation where you're like, hey, Gergei-Manager, I'm aware that I'm not doing X, Y, Z? How can I fix this skill? Yep. What are examples of other people who are doing a really good job of this skill that I can emulate? That is such a more collaborative way to step up because it comes from a place of curiosity and learning, which we just talked about, right?

And then I think the final one I'll say is this is going to be hard. And this is why sponsorship is so important. I've never gotten a job that I applied for. I know. Wow. Never. I've never gone online, clicked apply. Is it because you didn't apply or do you got jobs else, the different way?

Somebody spots, it's like, we need to hire her, recruiter reaches out, and then I apply. every single job. Now, I have an atypical CV. I'm a Nigerian girl. Like, we can go and, you know, like, you know, I'm not a typical profile of like 10 years or whatever. But I'm not a CV that, you know, I mean, now maybe. But at the time, even when they hired me as a PM, what did I know about product management? Yeah.

Right. But it took people who I'd worked with as a GM who were like, I know her from West Africa, engineering brain, and that was like the folks in, um, um, um, um, um, um, um, um, you probably remember them now, but the ones that literally worked on the bin numbers, the operations folks who had worked with me as a GM who told my hiring manager, like, we know her absolute, like, joy to work with, da-da-da-da.

And that's happened consistently. Like people come to me like, oh, how did you get on the Lego board? I met the recruiter five years ago, talking about something else, entirely different. And from just sharing knowledge and talking, when the time came, and, you know, they put my name in the hat.

So in every opportunity, if you focus on doing good work and you focus on making every moment a teaching altruistic, I'm not like, I'm not doing this because I want to like get something. Like it's it's not like I'm doing this because I want to check a box so I can get promoted. I feel like people smell that stuff. Yeah, they do. Right. And I just, I'm just like I see what you're doing. Like most people. Yeah.

And I also remember people who were doing this and I look back, you know, 10 years later and they're stuck where they were. Yeah. And the ones who just did good work, we've been talking about them in this room right now. If somebody pings me and they're like, even if they don't know and they're like, would you refer this person? I'm like, oh my God, there are people I've said, I would give Move Mountains to work with them again. They don't even know. And it goes both ways. When people ping me as well, then they're like, hey, this person, I'm like, you know what, that person did X, Y, Z to their team.

These are the good things. These are bad things. I'm not sure I would choose to work with them again for these reasons. It goes both careers along. And so play the long game. And so if the long game is ultimately you care deeply, we've just been talking about people in this room, right? We remember them, Charles.

Like, I know what Charles did for, Charles was the one who came to you and said, you should listen to your PM, right? There's something to be learned from, right? Like, you could have had another manager. It was like, oh, screw product management. They always think they're the CEOs. But if you play a long game and you just care about

doing the best that you can in that moment, like if you were, in a sports team. I really like using sports team or musical team. When you're reading your notes in an orchestra, you're like, I'm going to play the best that I can for me and this group of this note. It's not like I'm doing it so I can

become, you know, you're just like, there's this love for it. I come back to this word. When you do that, I feel like the rest follows. There will be people who will stand up to sponsor you. And then you don't need to be, you know, think of your career, be aware of it, not just forget about it, but at the same

time, let that not be the thing that defines you. Because I feel like in a world where everyone is doing everything for some outcome, it's just so refreshing to meet people who are doing it because it's like the right thing to do. So then wrapping up the, so the three things that you mentioned, the first one was caring. Be a product leader. Be a true product leader. Yeah. So all those are product leaders, sponsor people where you can and play the long game, right? Yeah. The, Be a product leader. Treat your career like a project. Periodic check-ins.

Don't wait until... You wouldn't talk about a product when it's shipped. You would talk about it along the way. So treat your career with your manager, with your peers, like, hey, how am I doing in my this? How am I? So check-in periodically because people are more willing to give you low-stakes feedback when it's not like Perth.

Right? And finally, don't go out actively just looking for like mentorships and checking the boxes, just do great work because the sponsors will come who will sponsor you when you're not in the room by just caring. Well, A.B., this was wonderful and just really good to reconnect. I know, I know, I know. I wonder what our next eight years will look like. Wow, eight years. I hope you enjoyed this conversation with A.B.

In a slightly different format than what we do with most podcast episodes. You can connect with A.B. on social media as listed in the show. notes below. For more tips on how to work with product managers, C deep dives in the pragmatic engineer also linked to the show notes below. If you've enjoyed this podcast, please do consider leaving a rating on the podcast player you're listening on. This helps more listeners discover the podcast. Thanks and see you in the next one.