## Intro [00:00] 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 h maybe whatever. They're willing to have skin in 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 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 cuz it's so important even if you're like shy or tester, 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 dirty 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 the 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? Either the director of product at YouTube and previously worked at Netflix and at Uber. As it happened at Uber, when I became an engineering manager, Ebie 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-atterns 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 ## Engineering and Product working together: a rocky start [02:19] together like I think to like it it was the most productive working relationship that I had uh in my professional career and and also it's just very rare to see so we turned like this small side 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 to uh Amsterdam. You joined as a as a new PM. We didn't really know you. My I I I was a new EM and and my team was a bit burned from like this this this massive project and we had a large backlog in front of us and we just it was just all 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 in in the newsletter I now have a growth article which 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 project and so I had a team that kind of built a bunch of payment methods here and there our road map was built like 20 more there was no no coherence And then you showed up and then I I'll be honest, I was a little upset because the first thing you you start to do is you you came to a meeting and this is just strange because I'm just saying how it was you you shared how the product review meeting went really badly and I was like what what are you doing? Like you're demotivated demotivating all of the engineers and and the engineers were blinking. They're like what's going on? You were you were saying look if 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 is she doing?" Like, "What are you trying to do? Are you trying to are you trying to like and that was that?" That's how it started. What product review is this? Do you remember? Uh I I I think it was a pretty early one, but I think was it a weekly review meeting that we had? So it it was the weekly meeting. So, we had a weekly team meeting and you you attended I didn't even know until then, by the way, that that a product review existed because my the previous product managers never told me about this, but you told me like, "Oh, I've just been at this this monthly product 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 not looking good right now. Yeah. Which was a blessing is it was always a bless. The cander 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 but this this is how it started. So I I was blinking and I I I think afterwards I pulled you out like like was I asked you are we on the same team like or something like that. Yeah. Exactly. And 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 would 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 st remember the the jelly bean cheat we had with the staffing um which at the end we didn't have that but like at the beginning it was so we was so important to 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 peer but like who's the TL who's the person like really under you understand what I mean and I 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 is to have this shared understanding but going back to the directness maybe knowing what I know now I've also try to tried to refine my approach to onboarding right so there is an element of like yeah okay you can be direct but um trust is trust is given and then you earn more of it this episode is brought to you by work OS if you're building a SAS app at some point your customers will start asking for enterprise features like SL authentication ski provisioning and fine grain authorization That's where Work OS 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 OKIT for up to 1 million monthly active users. It's a drop in replacement for Ozero and comes standard with useful features like domain verification, role-based access control, bot protection, and MFA. It's powered by Radics components, which means zero compromises in design. You get limitless customizations as well as modular templates designed for quick integrations. Today, hundreds of fast growing startups are powered by work OS, including ones you probably know like cursor, versel, and perplexity. Check it out at work.com to learn more. That is works.com. You know what later happened actually turned out to be an amazing thing because before that for like what happened is none of the engineers and as an engine manager neither did I I didn't know a monthly product review existed that product managers went there and they they presented their teams also at Uber product gave us headcount which was unusual I think at some maybe some companies work 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 And you know you started to do this every every every month or so you share it and and we start to understand oh this is the what does what does product care about right the product team is the combination of all the differences it's the edge like when you say product product is you too and that was something we 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 oh 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 we have you know you would have skin in the game and so I think what it came down 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. Yeah. 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 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 to come to. One is a fundamental belief and took us a while to get there, but that actually we want the same thing. Yeah. And and it 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 I consider everybody in that group a product leader the UX UXR data science but I see PMSGE UX you know you see UX say like oh I would I would love to have more polish but always cuts my scope like the moment you start having those does does the UX person understand that there is literally a missionritical 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 this 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 and viability and usability and you'd be able to balance that tradeoff and you would ship it. You wouldn't hold it back because UX believes in Figma, it should look pretty and engineering disagrees. Like that's not how it works. Same goes for edge, right? You would not um 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 P 0 metrics as we would if we were a startup and we had the numbers that we cared about like you know the the gross book the gross number the conversion rate the failed payments the cancellations etc that was cash etc etc 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. Yeah. And now you have engineers even coming up with ideas like we actually should create a web platform because it will unlock Bookings because if you look at like Door Dash compared to Uber Eats, I mean that came purely from two engineers on on the team, right? And maybe we can describe it cuz I'm not sure it'll be clear for everyone who's who'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 weekly meeting and, you know, the product manager would be there. We would share the the pro here's the progress on these projects, those projects. Okay, that would be it. And then we would talk a bunch you know the the second half of the meeting will be about tech depth 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 before you joined and uh at the time you know most engineers on my team they were very very interested and focused on paying down tech because we had so much it was just so painful developer experience improvements etc. you know, everyone was busy with that. And back then, we ## Working as a startup inside a large company [12:35] 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 me start 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 with my product manager. Like every week we would spend like 30 minutes of, you know, like what what what's on your mind? And I would be like, well, you know, there's this person on on on my team who's having I don't know, like some trouble and and I'm 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 we're having this review about headcount in in a month and I don't feel we're ready. And I was like, oh, can can that help something? So, suddenly we started to do that. Then on the team meetings you would there would be a 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 it would just be bit of introduction but it would all of our meetings would usually always start with product like here's here's on the product side of things here's the wins that we're seeing here's here's what's working here's here's what we're working on with with designers any engineer who wants to be involved results objectives challenges that was the format yes thing rock yeah and and and then an interesting thing started to happen you know engineers eventually would start to chip in you know Usually the schedule would have been like 5 minutes or 10 minutes of product, five minutes or 10 minutes upgrade and often it would just stretch out because because you know engineers on 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 the next half's planning was coming up on product side of things actually some engineers got involved of like oh let's help define like how can we how can I get this project prioritized and it was like well like if if any project that moves this or this and this impact in our case it was uh incremental growth booking so us making more money uh at some points we cared about writer growth in certain areas so we can lose money on riders but we just want to grow f first riders turn percentage etc. And engineers start to bring some ideas and and suddenly it felt a lot less of like oh here's the you know list we need to take off and let's just let's just get through the stuff that we so we get to the tech dub. It was more about okay let's do the important stuff and let's figure out do we need to do this do we and suddenly it just felt a lot more like yeah like a startup inside inside a big company. This was a $60 billion company at that point. Yeah. A couple of tactical things that maybe 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. I've never seen It's funny cuz 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 um I think after we had those, you know, those sessions and you and I met up, I came to you and I said, "Listen, I'm going to take 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 had had one-on- ones with the different so it's part of now my onboarding playbook. It was not a playbook then, but I called them conversations, comprehension, conviction. So when I joined, if you remember, I'd met different engineers one-on-one. Yeah. And I asked one of the questions, my last question is um um if you were me starting in this role, what are three things you would focus on in the next 90 days? And they, a lot of them came back and they talked about on call. Yep. Do you remember? Yes. They came back and talked and I was like in my head I'm so embarrassed about we had terrible on call. I was like I have nightmares about it. From everything I've read cuz 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 I like why do they expect me as a PM to do that? But I recognized I was like, "Oh, some there's something a miss remiss here." So we then met up and I still I can't remember the exact uh flow but essentially had the state of the union had won 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 um the Polynesian islands. Do you remember it? 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. And I still remember that it was like green and then we talked about like all the markets we had launched and all the payment methods. So the wins and then we went into like um we had a team um 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 US or UK etc. And there were a lot of questions on that 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. Yeah. 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 how much percentage of cash is leading to um uh first trip. I mean, in that context, here's a fun fact because it's been so many years and the numbers are now w clearly out of date, but I remember this 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 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. This team was begging to get headcount and with $1 billion of run rate. They they had to actually beat Uber Eats already. Yeah, they they had such a hard time. Well, we had such a hard time because this was a team next to me in Amsterdam getting headcount. So, it just blows my mind that this is possible these days. is I think if a startup you know hit we're talking about startups uh who are hitting you know the AI startups $und00 million of run rate etc which is which is incredible and obviously they you know they have 10 20 30 40 100 people something like that is is still amazing but with one one one full-time engineer we did a billion dollars and we couldn't get headcount y 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 Uh and one of the reasons and one one of the reasons we couldn't get it uh we were a distributed site we just you know the engine manager and the product manager who was there couldn't really tell a story and I think you know that's something that you help with uh later as well but I think it just comes comes to show that when you're inside a company especially if you're an engine 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 important ly if they take away your hatcount or get rid of a team that can happen what will happen there's something I 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 when so we didn't have cash right we had writer 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 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 um but anyway Anyway, um so he had basically that site right from an engineering perspective and I think one of the things we did so I went in I like at this time the PM for cash was not reporting into me but we went in a room I remember it was the the sleeping room the nap room cuz it was the only room you could get for that long. Yeah. No map we use for meetings, right? For meetings. And it was me, him and the data science uh uh lead um 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 2 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 always there's a problem with cash. There are all these issues with cash. There all these whatever. 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 0 that need to be fixed at the business level upfront 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 Charles did that well well I mean but I was 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 you 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. Um but going back to so yes so going back to state of the union the other thing that we did was and I I still find it hilarious that that you agreed to do this at the time because I was I I 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?" And do you remember you you 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 this story around what's the source of the on call." And a big one was like flakiness and regressions, like the two 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. Um uh and I I I really have become a bit obsessed with like rhythms in teams because I think humans our 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 speed it up yeah right but still on the beat on the beat. And so, um, 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, um, uh, it's like zoom in, zoom out, zoom in. Um, and so I would, we would meet, you and I would talk. We would also talk about personal stuff. We 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 prep before the kids. We would talk about personal stuff. And we had to also allow space for that cuz sometimes it's like oh let's let's anyway moving on to the topic and it's like actually that stuff is important to understand who behind the role and and you know like there there was a point where I felt that we got closer cuz look like the way I looked at it I'm just going to be honest like how I felt like I was there I was in a new manager role I had so many things to do you know I I had stuff to do at work uh I was in a new country I had to take care of that stuff I I I had a lot lot of I was trying to keep the people happy on I was trying to keep my my leadership team happy because we had engine managers product was very separate. It was the different organization and you know you came in we we start to initially I was like okay what is this person doing and then I start to kind of understand but but we kind of kept it at the like okay you know like you're 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 grabbed dinner. Yeah. And it was supposed to be I think two hours. I think we we say for a lot longer but I I just got to know the the person be behind the product manager and 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 always used to say the magic happens in the confluence 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 tumble 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 where 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 the the we had the one-on-one where we would sync and we would go on a walk and etc. And we we started making it it a thing of having periodic out of office dinners or I came to your house and 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 um you know for your birthday because it's in my calendar and I 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 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 it's so simple. We could generalize that as an engineering manager or as a team lead. The people on your team on your team like what are they you know we remember I remember when um when I you know I became the PM lead I knew when people wanted to were thinking of having kids were trying to do change mortgages where um you know as you know one of them uh had just moved a girlfriend from his home country and was moving in like the 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 our one-on- ones. You never like randomly cancelled 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. Yeah. Remember, we would talk about that as well. Yeah. So, so, 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 is to be fired for whatever on the team that that would need to be me. But it felt to me there was we had like like you and and then we had another PM but you and me we were kind of like being engine managers together a little bit. So so you PM man PM leaders together 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 people on my team for example like I I I knew when people were for example looking for a new job outside of work checking out kind of both checking out or 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 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 a couple of things and let's just let's just cut the BS and get to it, right? I've had to let people go at Uber. Yeah, 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 um who 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 you genuinely know that you want to leave this place in a in a you want to leave um uh your uh role in a sustainable place. We 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. Yeah. Right. And so it is your 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 like over time. They may leave, they may come back and so well and and also one one thing that I I feel it was an accident, but I I you know, we got to know each other on on a personal level. You would often advise me and I would I I would I would do the same thing on product, right? I will 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 I wrote an article called the product minded engineer, which is, you know, I uh I I get some good feedback for honestly with describing some engineers on my team. ## Product-minded engineers [30:24] Some engineers as soon as we started to do these, you know, you know their names. Yeah. So do I. You start to tell like here here's the metrics, here's the business, some engineer, you know, some engineers didn't care that much and that's fine. But some were like really turned like oh okay, how how how can we have these wins? How can I help the business? you know, they love doing this thing and they came with ideas. They came with ideas and 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 here's the interesting thing you know the I feel these roles are kind of made up I'm just going to say it like like what 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 a 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 four years that's crazy we had no attrition and like 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 it was they weren't meant to do product work and they once we got that stable team literally it was that team for four years and it's not like there's some cities where there like no other options. This was around in a climate where you had like stripe coming in you had you know flexport you had you know all these these data bricks data bricks. Um, 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 it goes back to this this this thing that I I I think is at the core of it which is when people love and I like not just loving. So there's a definition of love that I like because um I'm about to 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 I like things. I'm, you know, I like things. Um but actually even better, I love things and I dislike and hate things, right? And so and I I think about that. It took me a while as a 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 you know 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 ccentric because it was just 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 um a definition by Bel Hooks and and she says you know love is the extension of oneself for the spiritual growth of another or of oneself. 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. Yeah. To the extent that I I I I did the um I officiated one of our engineers marriages. You know this like are you kidding me? You know, I that's the height of my like you're such a friend and the love is so strong that I literally read your the vows of you and your like that is that you can't there is no price there's no you can't like there no words to describe how you attain that and that's all from this team right so no I do think that there's this element of like you know when 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? Do you know this, by the way? Yeah. Uber Uber Pay, which for multiple years everyone said would never work. No. Um the web payment flow, which at the time were like only 2% of of traffic was going through web. And these two that was two engineers uh trying to come up with the idea business plan and we kind of ring fence them and let them build it up like we no so so what happened is I tried to I I asked for headcount for the for to get web payments because it was a really really good you know they they they brought it they actually put a business plan ## Getting headcount for Engineering [36:00] together you said it's great I said it's great I asked for headcount you know from my my management chain or or from product whichever it was and they said that sounds great but no and so what what what I did with with your support because you know we just trusted each other and we're like I mean we did we so so we just did it we we we we hit the two people we still shipped every everyone of our product and then we came back in 6 months saying like oh so we've now built this we have this many customers uh we we now like this many extra head cannon and and here's the business that we're driving now and if we you know if we don't get it like we have to just shut it down and they're like oh okay I guess that makes sense yeah that's a no-brainer well even more like like like that's a little there was a another policy thing that came up because you know it started to become a bigger bigger and bigger company but but you know and especially the EU was you know everything the a lot of policies and there was a policy 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 um never mind the we won't talk about the comment the PM left um who I will I will stand by till today for craftsmanship like this team came and said, "You have to build this thing. It's a directive from DAR." And the PM said, they edited the comment later on. I saw it was edited. I 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 if you give me um Dar's name signed in blood. I am not approving this." And I was like, "Wow." Like, do you know what it t do you know how much skin how much guts you have to have in your decision to do that? But anyway, he he so he did that. It just showed you the kind of love we had for shipping the right product. Um but maybe don't say co's name in blood next time. But anyway, um 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 this the 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 is 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, so you're you're you're specifically talking about getting headc count for a team may that be a platform or a product. Even at my level, it is so hard to pull that off. You're director of product. I'm a director of product like my my skip level, sorry, my uh my uh manager is a VP. That's like into big tech. That's the height of it, right? They're 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 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 till today 14 weeks of engineering we have 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 bestselling book, The Software Engineers Guide Book, is out now. You can get it on all major audiobook platforms like Spotify, Audible, Liberal.fm, FM Apple books to 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 Reley who is the author of the staff engineer's path. From performance reviews to P95 latency, from team dynamics to testing, GG diversifies 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 ngeguidebook.com or search for the software engineers guide book on your favorite audiobook platform. I hope you'll enjoy it. And I think this is a tactic like 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 managers ask this like I'm now growing. 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 if it makes money for the business or it's it saves money for the business, you should have a case. And if it doesn't grow 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 efficiency clear value ad in doing it once and yes you always have to trade off like our design you always say 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 that's really how I like to think about it. If no one is dancing on your platform and you can't, you know, then 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 cuz 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. Yeah. Right. Like like Yeah. It's kind of win-win. Yeah. And I I I think it's good 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 to get headcount or do a new new initiative. So you know, you need to put a startup. You have to show if I went and said it is it's it's a very different game. So when you're raising preede so I do a lot of angel investing and I actually do it honestly I've lost way more money than I've gained which is part of the the thing but actually I I do these things because I like to 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 um uh conversations uh comprehension conviction I have used that to onboard into many roles I've used it my my board position I've used it um that Lego that Lego I used it the same framework I've used you know like I I I remember sitting with the uh chairman of the Lego board, the the fourth generation. I was like, for the first month or so or two, it's 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's what I fundamentally think we should be doing. Even though, you know, as a board you can have conviction, but ultimately the exact team is the what the exact team. ## The importance of a "vision" and meeting people [43:58] But I've used that. I also used it when I took on my um 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. I like I know I have a playbook here and I know what doesn't work and what d 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 um they block we had very similar things in Amsterdam like oh they're difficult they hold you know they're blocking 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. Um, and then also like this actively road sharing. 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. Yeah. Same playbook. I have a plan. I do a road show with all the partner teams. My remember the first couple of years my, you know, 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 that not everyone thinks they're a snowflake and like my thing isn't getting prioritized. So I 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 scared 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 worked 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? Uh what do you want to do after Uber? like, you know, are are you trying to is this temporary and you're trying to, you know, be a CTO one day or 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 cuz I was not doing work per se, but it 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, now I'm gonna, you know, ab the sort of like philos um philosoph I think we've been conditioned so much to like squeeze out efficiency. Like I go in nine, I clock in, we get in a 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 1-hour meeting. I remember I literally just met um a UXR lead on our on the team. Um never met him in person. Uh one of the things I like to do, I'm not saying everyone should 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, podcast. This is my second inerson podcast. Can we do more of these? Um, 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 9 9 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 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 I'm horrible. I don't even do like hi. I just get into it. Like I'm 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 AB the human and I've connected with Gerge the human. The 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 was 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 a this is not my core team. This was like a team I had just inherited for um um one of the ERGs at Google. And 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 let's just it is not cheating to connect at a human level right in a way that's comfortable in working hours in working hours because you will do so much more and achieve much more without the squabbbling the bickering the e you know whatever because it's not a zero sum game. No, 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 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 you you mentioned patterns that you know you've 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 at Google. What are patterns you've seen truly standout software engineers be like across these companies? like not not you know at Uber we we we had a team and maybe it was special maybe it was not but are there ## Traits of standout software engineers engineers look like? [50:44] some kind of behaviors either skill sets or or things that people do that that make them just a great engineer someone that you as a product manager are like I I I I can work with this person at either of these large companies I'll say I'll start with the opposite let's just contradict for a second y one pattern is everyone in their gut knows intuitively when they have encountered a genius jerk. Oh yeah, I I I remember the ones I work with. And 10 times out of 10, remember we used to have a a director, Daniel. 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. 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. Oh yeah. 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. Um, now unpacking that a little bit more, there are some people who may manifest as jerks, but actually they're not they they've never been told. And the moment they're confronted with their jerkness, they correct it. So, you know, we've had, you know, like um certain PMs who may come up abrasive, but actually they mean well, and when you actually have a conversation like, oh, the human is a good person, they just they need to work on their comms. So, I want to also want to deem 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 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. Um 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 IC there's a pattern that you see the tracks right so I'm literally thinking in my head of like personas right now um one is they never stop learning so my 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 Essen, he'd be like, I'm going to go write some code. I'm solving some Lee uh sorry, what do you call it? Um not uh Lee coding uh exercise, right? Lee when I was building some cyber building stuff. And this was a director of engineering, senior director of engineering, something like that. Phenomenal guy and it wasn't to everybody's liking or taste, but I loved loved him because like this was just a 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. Um um and so and I you know nobody uh nobody hates it. No one truly loves it. It's what I believe as well. But anyway um but but there's another persona at YouTube now that I'm thinking of a VP been there for a while. Phenomenal guy um um uh Christos. And I remember when I joined people were like, "Oh my god, Christos, you know, I don't know, you know, I'm just going to talk about it like you know who how I am. I just, you know," and they were like, "Oh, you know, like warning." And I, you know, we're in a meeting and I he said something and I was like, "I disagree." And people ping me later like, "Oh, no one disagrees with Christos." And I 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. I get it. And I'm like, you just gave me money for doing a good job. Okay. But anyway, um, 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 AB thumbnail testing. And you guys, you did it. And he he saw that and we went through what I just thought was a high friction comp because he was this this guy is like somewhere else in the org and he was like I am concerned about this for creators. Explain to me not is his domain but he cared deeply and never stopped being curious. He was like 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. They're like even the IC's, it's like I just found, you know, the ones that send you, hey, I just played around with this new model, da da da, 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 engine 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 dirty. It's a nice and and you know, like they they will not just come like, oh, I I've learned this. They were like, no, like I I wrote the code here here's here's a poll 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 the team will be like, "Nah, that'll take us like two, three weeks. Can't do it." And, you know, these people they'll either they'll ask why and then, you know, they'll get to the point that it's not that difficult and they'll do it or sometimes they just do it and but they do it in a way where it's not showing off or something. It's it's like no like like I did it like can can can we progress or or or tell me what I'm missing because because you know you're the expert and and I know that used to it can piss off people. Yeah. But but it's the like same with my partner Matild. Same thing. She'll be like I'm sorry. I'm going to call uh I'm going to call this is 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 this traffic. Have we 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 good point. They're willing to call out that they were wrong. Yeah. It's a v that's what I this this notion of vulnerability is your strength. Yeah. I I 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 they assume that they might not be competent all the time, right? And is 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 that the more you learn, the more you realize how much [ __ ] you do not know, right? Like just how much you don't know, you know, and so if you but 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 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 I I hear you. I understand the feedback you're giving. I don't think it's a concern, but I'm we may be wrong, right? But what I'm going to do is at every step of the roll out, 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 uh the VP Crystals. 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 I know what I'm talking about. And so at each step actually the conviction was correct and but the thing he called out made me think about oh these metrics that he's called out and I just need to make sure on the go to market we solve for. So they are one students of they're willing to they 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. Yeah, sorry PMs and people out there. It is not okay to never have gone through your onboarding flow like because and also also engineers I'll call out the the most efficient engineers were the ones who went through the at Uber for example create a driver account and you know and delivered food or or or even just do the simulator and see what the onboarding flow is like or open the competitor's app and see what it takes to sign up there. Thank you. And I 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. Yeah. That that's I feel like that's it's it's it's happening. But I I think it's good that we're talking about it. And and then this final piece which is that you know um the conviction like they have a strong opinion, they have conviction. So where they say like this is the way they're not like wobbly like h maybe whatever. They're willing to have skin in 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 that. I see Mattil do that all the time like on meetings. She'll be like, "Oh, no, no, I didn't. Okay, that's a good point. Oh, I never thought about that." Right. So, but she's also be 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 or 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 tester 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. Yeah. And even at my you know I I I was an engineer I think I'm actually good at you know technicalities but there's some engineers in the room they just throw out the acronyms and throw out the this and throw out 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 tr 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 patterns. They're hungry. They stay hungry, stay foolish, they have conviction. I I'll just add that for for software engineers what what what I've seen do not be afraid to get your hands dirty and code like because because there there are the things that apply to everyone but the the people who I've seen fail uh at teams who look good is they just talk the talk but they don't they don't they don't get involved for whatever reason. The same with designers who design leaders who have not open 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 efficient, 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 like 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. Uh it 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 injury manager could also use a tech lead or or or even just an engineer who's you know like a senior or or or engineer who's mentoring other engineers because luckily there's more and more engineers mentoring. what what works. Um, I know I'm going to sound like a a broken record, but I I do believe repetition doesn't spoil the prayer. Um, this is a phenomenal example of where the playbook tracks regardless of the role. Really? So, I it's not just engineers. I mentored designers as you know on the team. Yeah, you did. Yeah. I actually even managed the team. I managed the design team when our when our design manager went out on parental leave and then you were swamped and then we wrote some PRDs for you. Yeah, I Yeah, I was so swamped. She wrote the PRDS um which by the way is one of the 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 dock it's actively participating in the PRD it's you know and this would apply not just for product managers but for engine managers or anyone who either in leadership position or thinks that or wants to be involved. You know, the Oprah gif, Oprah Winfrey gift where she's like it applies. So, 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 BIS 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 so I think caring about the product in a way where you're also a contributor actively to like the OKRs the what you know so when you say caring about the product and the business right why 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 y it's the feasibility the technical you know what's possible and it is the customer experience that's product that's the definition of 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. Oh, it's like say 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 the first. That's 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 like this thing is going to take two sweet years. But I 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 you you leave your your tech company you have a lot of savings you start a startup to build a product you are a product leader you're now a product leader you you join a team where there's not a product manager either you become a product leader uh or you know linear like I mean them multiple founders but linear that the you know we remember working with him they they hire for product sense and taste for all of the engineers and the reason they have so few product managers. They now have one or two because everyone is Yeah. Yeah. Which makes it that more this this another podcast but that more that much more important that I used to say this ## The value of a great PM [01:06:54] you remember me saying this a if you take a PM out from a project there should be an order of magnitude exponential effect. it not it's not like you went from nine to 10 because we've worked with nge leaders we had people on the team who could do the the nine to 10 they were really thoughtful in sending the updates in you know the standups so a PM comes in this like 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 this stuff I think one is um 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 business's metrics like there's a direct correlation we knew how we knew it right we knew how incremental whatever moved Uber's numbers um I think the second one is treat your career like a project what do I mean by Most of the time I'm not a fan of when people reach out to me like hey I have this issue I and can you be my mentor sounds horrible but nine times out of 10 I don't even engage because I just don't know enough about you to help you. Yeah, I think mentorship and I've become more of a big believer in sponsorship which is even more important than mentorship I think for the 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 money hub site I started meeting what I called like the like for me like the the those sort of 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 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. Yeah. I am um 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 an 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 risk the results are, what the challenges are, what the object, you 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, Gay manager, I'm aware that I'm not doing XY Z. How can I fix this skill? Yeah. 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 the the the final one I'll say is this is going to be hard and why 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 you got jobs else the different way? Somebody spots. It's like we need to hire her. Recruiter reaches out and then I apply. Mhm. 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 had 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 uh uh you probably remember them now, but they were the ones that literally worked on the bin numbers, the operations folks who had worked with me as a GM who like told my hiring manager like, "We know her absolute like joy to work with." D. And that's happened consistently. Like people come to me like oh how did you get on the Lego board? I met the recruiter 5 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 in every opportunity if you focus on doing good ## Play the long game [01:11:50] 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 cuz 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 I 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 talk, 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'm 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 and they're like, hey, this person like, you know what, that person did XY Z to their team. These are the good things. These are the bad things. I'm not sure I would choose to work with them again for these reasons. It goes both. careers are long and so play the long game and so if the long game is ultimately you care deeply we just look 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 was like oh screw product management they always think they're 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. Mhm. So then wrapping up the so the three things that you mentioned, the the first one was caring, care, be a product leader. Be be a be a true product leader. Yeah. So, so like all all of us are product leaders. Sponsor people where where you can and play the long game, right? Yeah. The the the um be a product leader. Treat your career like a project. Periodic check-ins. Don't wait until you wouldn't get talk about a product when it's shipped. You would talk about it along the way. So, treat your career in that way 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. Yeah, when it's not like PF, right? And finally, don't go out 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, well, Aie, this was wonderful and just really good to reconnect. I know. I know. In person. I know. I know. I wonder what our next eight years will look like. Wow. Eight years. I hope you enjoyed this conversation with AB in a slightly different format than what we do with most podcast episodes. You can connect with AB on social media as listed in the show notes below. For more tips on how to work with product managers, see deep dives into Pragmatic Engineer, also linked in 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