How engineering leaders can better drive business outcomes & increase alignment between product and engineering w/ Gokul Rajaram #198

The product engineering and design relationship is so important because disempowered engineering teams will just lead to the status quo because then the organization is not benefiting from their they're the smart. I mean the reality is they are some of the smartest people in the company. These are just business problems. They're much easier to solve than crazy engineering problems. So give them the opportunity to work on them.

Hello and welcome to the Engineering Leadership Podcast brought to you by elc, the Engineering Leadership Community. I'm Jerry Lee, founder of elc. And I'm Patrick Gallagher and we're your hosts. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. This episode is all about strategic thinking and business impact. We're joined by Gokul Rajaram to talk about how engineering leaders can better drive business outcomes and create alignment between product and engineering. Our conversation covers a lot of different topics, some of them including how to shift your leadership to focus on organizational change. We talk about how to facilitate goal setting conversations in a high impact, meaningful way. We also get into navigating the shift to become more customer centric. We talk about decision making, accountability, strategies for high impact meetings, aligning engineering with product, and so much more. Let me introduce you to Gokul. Gokul is an early stage technology investor helping founders build enduring companies. As a product leader, operator and board member, he's helped build seven generational technology companies including Alphabet Block, Coinbase, Doordash, Meta, Pinterest and the Trade Desk. Enjoy our conversation with Gokul Rajaram. First off, Gokul, just wanted to say thank you for joining us. How are you doing today? What's going on?

Nothing much, just meeting with founders, had some meetings in sf. It's a nice day, not too cold, so hopefully we'll go out there later today. Always good to get some nature.

Just another day in the life. Love it. Well, we appreciate you being able to come back and join us again. I know that we threw out a couple topics for what we want to focus on today and it ranges from strategic impact, talking a lot about outcomes, cross functional collaboration, career growth. So I know we've got a lot of exciting things to get into, but I was hoping we could start with strategic thinking and driving outcomes because when we were surveying our community, one of the top challenges that people were trying to solve is how do I become a better strategic thinker? How do I impact the strategy of my company at a greater level? And I know this is something that you spend a Lot of time thinking about. So I wanted to, I guess, start off with, with, you know, you and I were talking about this idea of engineering leaders driving outcomes. Can you introduce us to this perspective here and what this means to you and why you see this as critical for engineering leaders?

Yeah, in general, I think almost any person at a company, engineering or otherwise, their impact and their growth in a company is very much dependent on their ability to affect the things that matter at a company. And what things matter at a company or to a company? If you think about the very top leadership, the CEO and the cfo, the things that matter to them are business outcomes and the investors of the company. Business outcomes are things like revenue, profit, things like that. Now those are somewhat abstract and hard for any given team or individual influence, but one level below it. I believe that almost every business outcome can only happen when customer outcomes are influenced or changed. A customer outcome is something like, oh, you know, a customer was not a customer. They went from a state of not customer to a state of becoming a customer or a customer went from state of becoming a customer to becoming a loyal customer or becoming a loyal customer for one product to also getting upsold to get starting to use their second product. All of these are customer state changes, you can say, or customer outcomes. Of course, a customer, negative customer outcome is from a loyal customer to churning. The more we can show that our work as engineers or for any other function can directly influence those customer outcomes which then result in business outcomes, the more we can both build a reputation as someone who cares about the big picture of the company and get rewarded, promoted, etc. And get more impactful products, more ourselves, feel more satisfaction that we are working on something that matters. I think a lot of people, they basically will be working on a thing, a feature, and they look up and say, why? Why am I working on this? How does this connect a lot of dissatisfaction in NUE and just overall unhappiness in companies because people don't feel like their work connects to something at the company. So I think outcome focusing is also a way for you to feel your work is connected to something that matters at the company level.

So you're saying focus on the customer state changes and like connect everything that you're doing within your team or your organization back to how is that influencing or impacting those specific state changes. And I really like what you're saying about like the NUE or the satisfaction is that when you can concrete link those things, that sense of listlessness that maybe people face in their role or like purposelessness can be solved. So how do you do this? Like what needs to shift in order to more directly make these types of links?

The biggest thing that needs to shift is the leaders, you know, both leaders of product engineering, but the leaders of the company or leaders of a business unit, they need to move away from dictating tactics and micromanaging teams and instead move towards holding the product and ENG teams. I think of them as one unit. I mean, I think we'll talk about more of product versus eng, product engine design teams accountable for customer outcomes. So the goals should be framed as outcomes. In particular, goal setting should be framed as outcomes. For example, instead of saying our goal is to launch an Android app, that's not a goal, that's the decision that engineering and product team should make. Instead the goal should be, I want to grow from 10,000 monthly active users to 20,000 monthly active users. So now we're getting 10,000 new users from a state of not monthly active instead of being monthly active within a time frame. So it should be phrased as a numerical goal within a timeframe. And then the product ranging team needs to be given the flexibility to say, hey, there are 10 different ways to accomplish this goal, one of which is to launch an Android app. Because apps generally result in higher usage and daily usage and whatnot. But there are other ways. Maybe we need to send set up a CRM system or maybe there's six other things we could do. So I think we need to give flexibility to the teams who do that and that empowers them to think of ways to accomplish the goal and focuses them on the outcome versus on the tactic. And I think the similar thing, it's similarly true that we should also celebrate achieving outcomes versus product launches. I think a lot of companies just celebrate a product launch and a product launch is just a product launch. It's a company centric milestone, not a customer centric milestone. What we want to celebrate is a million people are now using this app on a daily basis or a million people are using our service on a daily basis versus this app launched. So what now it's a PR event, but within the company. I think we need to be sober and just realize that all goals should be framed in terms of customer outcomes. And things that are celebrated and acknowledged and recognized in the company should be impact on customer outcomes versus like things like launching XYZ and so on. And customers can also be internal customers, especially engineering teams. Platform teams have developers as their customers, for example. And you can think that their goals also should Be in terms of developer productivity, developer efficiency and things like that versus oh, they're just building XYZ in the platform. Platform teams, especially from that listlessness because they just feel super removed from everything that's happening.

I want to go back to what you mentioned about the distinction between the goal setting conversations and focusing more on like the numerical and timeframe. I was wondering if you could kind of walk through like how you facilitate this conversation. Because I think the way you're talking about, think about the outcome you want to get to and then like the engineering team have having the ability to come up with different options and then to choose those different pathways, like how do you facilitate that conversation? And then what does the decision making process look like if you're going to those outcomes? There's an infinite number of ways to do that. What does that look like?

First of all, it needs to start with engineering and product teams. I think the product manager is an important part of the equation here because they together with their partner, the engineering team and the design team should be a cohesive team where they basically operate as a unit. And we'll talk more about how they operate as a unit. But they need to, when given a more tactical goal goal which is like I said, much more specific around do this. They need to push back all around goal setting. Right. In a company who sets goals, in many cases, I think it starts at the planning level. Typically goals are set as part of the annual or quarterly planning process. The CEO and the CFO will have some financial goals and they are struggling. In many cases there's this interesting transformation that happens from a financial goal to the set of tactics. So that sausage making in the middle needs to basically happen in a more structured way where these financial goals need to be decomposed into customer outcomes. And then we need to have an org structure where teams can actually own customer outcomes. Many orgs are not set up to do that. For example, an org might be set up across, oh, here's an Android team versus an iOS team and a web team. They can't really own customer because the Android team, the only thing they do is ship an Android app that might or might not deliver a customer outcome. So part of it is the org needs to be set up around owning customer outcomes and cleanly. The org's mission also needs to be I am the dau growth team, for example, I mean that's too specific, but something like that. Or I'm the new customer acquisition team. I am the customer retention team. And then I have customer specific orgs versus platform specific or tool specific orgs or something like that. So I think it starts with the right structure which then helps the leadership team frame their goals. Because the leadership team is like, well the org is set up like in these ways. So therefore we need to decompose our goals into tactics because these orgs can't solve for the customer because they are focused on one kind of platform or one kind of tool or something like that. So it starts with resetting the org and the structure of the org.

Can you talk us through your thought process for how you think about making that shift to structure based on customer outcomes?

You start, I think it's a great question. You first have to prove to the org that this works. Orgs have, you know, many orgs might have done this for years or even decade plus where they're just focused on being feature focused. They just launch feature after feature after feature and that's how they measure their success. Ask for promotions, you know, celebrate things, et cetera. To move from that to an outcome or customer focus org you need to prove like with anything, you need a hypothesis. Hypothesis is that this or customer focus outcome focus org is going to lead to more happiness, more productivity and more direct alignment with company goals. Productivity for both teams and individuals. Okay, let's prove this, let's prove this to an A B test. Let's take one group of people. New customer acquisition I think is one of the most important things for any company because they are the lifeblood company. If one. Once a company stops acquiring new customers, however good your retention is, your growth is going to slow down, eventually go to zero or eventually going to be very slow, maybe negative. That's a place where you can start, where we can create a team focused on new customer acquisition. What happens is many times marketing is focused on new customer acquisition or sales or something. They don't have a dedicated product engineering team focused on new customer acquisition. They have a bunch of features that they want to activate and acquire these customers, but they're all distributed amongst many different teams. So instead let's consolidate a group of people. Maybe have four or five people engineers, a product manager, designer whose only job is to figure out how to help us grow from. And the definition of a new customer also depends on company to company. Let's assume it's an activated customer, a customer who's actually used the service. You know, in doordash's case, maybe place their first order. Netflix's case could be entered the credit card and watched a video, some definition of activation. So you Go not just acquisition, but activation. So that's their job. They figured out how to work with product marketing, et cetera. And they are part of the team that gets this new customer goal and basically operates it. And you'll very quickly see when everyone's united around oh, what are the set of product things we can do. Everything you're doing now is around new customers. You start going and even your framing of your mission statements around new customers. So people start understanding and appreciating and being more customer centric just by the nature that their mission is new customers. And instantly this team, I bet you within three, six months will operate in a different way and will be recognized by their cross functional peers, by leadership and by other engineering and product teams as that's the exemplar of team I want to be. So you start with a test. Could take any or it could be a new project. But I think new customer acquisition is a great place because that's where the cross functional teams outside of engineering are starved for more dedicated engineering. They know that if certain onboarding flows or self serve things can be expedited or even some SEM things or SEO things can be done better with engineering instantly things will improve, but they don't have the ability to ask for it because everything is split up across different things.

What is the next step for a broader rollout? So we validated this, this model works. How would you recommend engineering leaders start to continue to reorient and build around this type of operating model?

We basically figure out what are the customers first. The next step is to break down the business equation of the company into customer outcomes. So the business formula of the company, we talked about revenue, profit. So we need to say okay, the business equation of the company could be assume it's a marketplace. It could be I want to grow GMV gross merchandising volume of a marketplace. Gross merchandising volume is equal to number of active customers in that month for a month is equal to number active customers a month times the average order value for that month times the take rate that I have now. Number of active customers in a month is equal to number of new customers plus number of repeat customers that repeated over plus number of people who churned the month before and were reactivated. So it's new plus repeat who repeated who were already a customer prior month plus reactivated times average order value. So you basically have a team focused on each of those three. And sometimes to start with, you have the churned and reactivated or repeated reactivator in the same Bucket, maybe call it the retention bucket. You have the new customer bucket and then you have the average order value bucket, which is an interesting one because that increases the average order value. And then basically you start with that, you create teams around that and then you basically have each team have a goal around increasing or keeping flat, depending on what it is or prevent at each of those. And you start with that.

So going back to like within these conversations, so you've got like the engineering, product marketing, sales, like different cross functional partners within these conversations. What does it look like to facilitate like the different approaches that you could do to impact these customer outcomes? And how do you help guide the team to make the best decision or like develop a really clear hypothesis to move forward. What does it look like to like choose which path to go down when there's a lot of choices?

Very simply, two things. One, you need to have a brainstorming access to first, brainstorm all the different paths before you can choose. Second, you need a way to compare them. And third, you need a way to test them. And so to brainstorm, I think it's done really by, not just by engineering, but you should involve cross functional people who can bring new perspectives. And I think you want to brainstorm. I like this idea of brainstorming where not in a group session where everyone gets together and some people are not engaged, everyone brings four ideas. The product manager, whoever it is, lays the context out. Here's the context, you know, the context is, here's what we've seen worked for this thing. Maybe it's new customers. We want to go from 10,000 to 20,000. Here's what we have tried, here's some ideas, you know, but I want each of you to come up with your top three ideas and why you think this is a good idea to increase new customer acquisition. And so everyone brings their ideas and emails them, ideally to the product manager before it's collated. And then we basically group them together into themes and then we look at each theme. So now you have a real brainstorm where the brainstorm's goal is not to generate new ideas. You can generate new ideas by looking at them. There's probably some interesting things. So you have an art where you look at, okay, are there some interesting things you can do with these ideas? But I always like idea generation in private and then synthesizing in public. But after that you have to choose. So I think if you have five, six people, even a small team and each of them three, that's like 20 different ideas. And I think you can quickly sort rank them. So how you rank them, I use a simple framework called I.C.E. which is impact, confidence and effort and impact on the effort. You basically, it's like what's the impact if he did this and if it worked, how many people would it impact? It's like the reach essentially, you know, and how many people would impact and how much would it move this number by confidence? So it will actually add, say, say something. We have to go from 10,000 to 20,000. This thing can add 5,000 new users or this thing can add 3,000 users or 1,000. So you sorted by that and again, I don't think you put an actual number. You say it's T shirt sizing, small, medium, large. It's high impact confidence is the other one, how much confidence we have. This is actually going to have the impact. Something could have high impact but low confidence. And so you again T shirt size it and then find the effort. How much does it actually cost to basically roll this thing out and to implement this? So that's basically ice. And then you look at those three scores, you know, or T shirt size and you come up with some way to weight them and you see which ones rank at the top. And again, I think you do want to, if there is something which is medium impact but high confidence and low effort, you probably want to go for those things. But of course ultimately you have to get to 10,000 or some number like that. So earlier in the quarter you want to try the things that you basically want to do which have high impact potential because as the quarter dwindles because that's why the timeframe is important. The smaller the amount of time, the less you have to go for with the low hanging fruit even, even if they're not going to impact, you want to try the highest confidence or highest impact things early on. So that's what comes down. The third part is testing. So then the question is what are some lightweight ways to test each of these hypothesis? Because each of them, each of these ideas or tactics have underlying it a way to test it. And so this is where I think engineering ingenuity comes in, which is, okay, what is a simple way and product ingenuity and all of these things. What is a simple way to test this without writing too much code, writing the minimum amount of code, how can we test this thing? For example, we don't have an Android app, for example, if an Android app is a thing. Now launching an Android app, building one in three months is super hard. What's the way to Test it. Well, could there be a web app we could create and surround? It's somewhat janky, but could we test that this works in like two weeks instead of spending two months building a full fledged Android app? And then maybe slowly we can do it. So different things and some things may not be easily testable. You've got to have a leap of faith there. But the things that are easier to test are probably the ones that a team should prioritize because you can quickly get a signal on it in a week or two versus waiting two months and then it's the end of the quarter. I'm thinking of quarterly timelines, obviously for younger startups is monthly and there you have an even faster pace of testing. So that's the way it would work, I think. Generate ideas, rank ideas and then test them. I always think that a feature is an experiment designed to test a hypothesis. Is this hypothesis correct? It's an experiment. So feature is a customer facing hypothesis and you're basically doing something to change the customer's experience or to test the hypothesis. And typically you should only do it for 5 or 10% of customers. If it works, then you roll it out and a feature launches. When you roll out this experiment to 100% of customers, so and you test again, you celebrate not the launch of the feature, but the impact it has on the customer behavior and customer state.

What do you think are some of the biggest challenges that engineering leaders face when they're making this shift to focus on driving customer outcomes?

Lack of data, lack of data to quantify different things. That's why I think analytics and data science is an important fourth pillar to add good analyst. Data science can quickly give us the data that we might not have to able to make the choice or even have some essentially hypothesis. How do we actually test these hypothesis in statistically significant ways and really be able to make choice? So I think that's one and the second one is just, just the business equation, being able to decompose those. I've seen that when companies move to this model, try it, it takes three full months and the first quarter is, I shouldn't say a wasted quarter, but it's a quarter where you are struggling to do things in this way. So patience is the other thing that is needed where it takes, I think three months for the team to get used to it and you start seeing some wins at the end of the third month and then the next three months are where you really expect this thing to really, really shine because a.

Different way of thinking, especially the Way you laid out comparing and testing and thinking about impact, high confidence, low effort, even just approaching something from that level, I can get some quick wins within the first three months or some really high impact wins. So it feels like you could get signal on the momentum is building pretty quickly that way.

Exactly. And I think this is why engineering teams and these teams should be durable. In other words, I always recommend to founders and CEOs and even engineering leaders that you can't think of engineers or team as chess pieces to be moved around on a monthly or quarterly basis to build understanding of a problem domain or of this customer problem statement. That's the other reason it takes two or three months to understand oh new customers, where are customers finding us? And you start because you're focused on new customers, you really start living and breathing customers or not customers at this point and you start understanding why are they not customers. You start building hypothesis in your mind and so on. And if you suddenly get moved to another team, all of that knowledge that you've been building up suddenly disappears. So I do expect that teams to stay together for 12 to 18 months to really build up a body of work and maybe one or two people move in a team at any point. But the team needs to have continuity of knowledge, understanding so that new people can be easily onboarded and loss of team members is not acutely felt.

The other element of this I know we want to talk about was creating, introducing or reinforcing accountability. So in this world, like some of the dilemmas that you see in this space and what engineering leaders can do about it to either introduce or reinforce more accountability in engineering orgs, the biggest.

Thing is when you have performance reviews. And this is based predicated on the thesis that incentives drive behavior everywhere. In performance reviews you see when you go into n job performance reviews that impact is really measured by amount of code or like Excell of engineering work in many cases versus customer impact. And so many times the customer impact is well, the product was not well defined, it's not engineering's fault. But I think the reality is you are part of the team. In fact, engineers within a product engineering pod, engineers are the largest part of the team. So I do think 70% of performance review should be based on performance, which is performance against customer outcomes. And 30% should be based on things like code, quality, end culture, organizing, all hands, referring people, et cetera. And as soon as you say look, 70% of your performance of your score is based on your teams and your ability within that team to influence customer outcomes. So I think that changes your mentality instantly.

Where do you think resistance comes from for increasing accountability within engineering organizations?

I think it's again the product ranging divide. And this is where I think the wrong product structure is where product managers, especially younger, more immature product managers think of themselves as a CEO of the product and they basically truly don't let engineering be part of the idea generation stack. So engineering limiting fields, they have no voice and they just have to implement something that some other org decided. And if that happens, that again leads to frustration. And of course then the engineering team have no choice but to say, look, we weren't even involved in the decision making here. So I think that's engineering leadership's goal is to have engineers play an active role in decisioning and play an equal role. And I think I've been in organizations, very pragmatic engineers, engineering managers who will not allocate engineers. If a PM just goes and says I want two engineers to work on this is, hang on, what's the goal here? How's it going to change our outcome? We are, what's the data point we have? And so that's the onus on the product manager or the team or market, whoever it is, ask managing resources they need to provide data or why do we think this specific feature request, which again, I hate the word feature request because experiment will result in the movement of this metric versus all the other experiments that we have in progress right now. But yeah, that's the reason I think the product engineering and design relationship is so important because disempowered engineering teams will just lead to the status quo because then the organization is not benefiting from their expert. They are the smart. I mean the reality is they are some of the smartest people in the company. These are just business problems. They're much easier to solve than crazy engineering problems. So give them the opportunity to work on them. And all of, I think all of Zuck's directs at this point are essentially ex engineers. Chris Cox, Boz, et cetera. It shows, I think at Meta engineers are running a company.

I think that's really exciting evidence in the case of engineers, Engineering leaders being some of the smartest people within the company, put them towards your biggest problems. So I want to talk about bridging this because for the people listening to this, they're serving in the engineering leader role. And so if they're facing this maybe PM Persona where they're more prescriptive with this is what we need to do. What can the engineering leader do to.

Bridge that gap First I think go and talk to the product leader directly. I think most good product leaders are much more enlightened today. I think 20 years ago it was much more of a waterfall model where product rides the specs, engineering implements it, qa, qas it and customer gets it. But I think over the last 20 years, last 10 years see change in all of this. So I think it's typically isolated instances of this happening in good companies. The first thing to do is to raise it with the product leader and say one of our teams, the product managers and then get the product leader to basically step in and take action. So I think it's very important. Therefore the engine, the product leaders are very, very tight. And I've seen that at most good companies they operate as a pair, they always go to stuff togethers because then product leaders depend on engineering to get stuff done. They really need engineering spine. And in fact one of the number one input into product leaders own performance review is inch feedback. So I think that's the easiest way to do it where you make two in a box. I actually always see, in fact I was at a review of large public company yesterday and both the engine, the product leader came to deck together. I mean they basically one of them, they could almost even competing agent sentence. They got all meetings together. So they obviously lead different things. But you're getting both their, both their brains together. And if the two of you show this then your teams also start collaborating together. I think so that modeling is good and then also it helps build that relationship where you can point out and maybe they can also point out a little bit. Look, there is engineering teams that you have who don't want to engage in this brainstorming who are saying look just tell us what to build and we'll build it. And that's also not the right attitude. We want engineers to be involved and we don't want them to just be like feature request takers and builders. We want them to be. I think part of it is again you need to sprinkle some more product centric engineers throughout the org. There are these folks and then they serve as a model for other engineers as to what is possible.

So you painted the picture of this tightly connected engineering and product leaders coming together. So I'm going to use that as the vision. We're going to jump into cross functional collaboration out. So when you're thinking about like those relationships, like what are the challenges or the dysfunctions that you see when it comes to engineering and product teams working together that are preventing them from getting to that like tightly coupled, really aligned, finishing each other's sentences and being very strategically aligned state.

Part of it is there is an implicit it's. It shouldn't be the case. It's. Sometimes the CEOs can inadvertently introduce a tension or dynamic between the product engine teams which put them at odds where the CEO might relay feedback because the engineering leader or the product leader might go to the CEO and complain or like express dissatisfaction with the other entity. Like they might say, well, the engineering team is not executing well or the engineering team. So I think that engenders distrust. So I think that's the thing to make sure that the trust element needs to be there and they need to have an open dialogue if there's trust, they have an open dialogue and they need to mutual respect. If they both respect what the other brings to the table and both see that the other brings something quantifiable and that that complements them is trying to usurp them. Because there's always the nervousness that each of them have will the other take my job? Because sometimes you see, you know, the same person runs both. So if both of them are confident in themselves, yet see what the other has to offer, they go into it with an open confidence and the openness to meeting of a mind versus nervousness at being like shunted out or pushed out and like lack of self conscious because they know that their team is not executing or their complaints, all of those things. So I think that's what results in unfortunately an impotence mismatch.

Do you have a story or example either that you've observed or that you've experienced with the different organizations you've run where you've been able to resolve that or establish that from the get go.

When I joined Square, Square was basically I led product engineering and design. Square was organized as a monolithic team and it was actually organized as a functional team. There was an iOS team, an Android team, a web team and a backend team. And then there was a product team and a design team. And so what I did was essentially created seven or eight different pods, each with a product leader, a design leader and an inch leader and said you are all three in a box. So I think it has to come from the top where I said I'm going to look to all three of you and I'm to give you the same grade for the outcome of this pot. You're not going to get different grades at the margin. Your 80% of your grade is going to be the same 20% could be different based on what each of you are doing. But 80% is the same. So if indeed you're going to grade them the same, guess what. 80% of the grade is the same. They both are super aligned on the fact that both of them are in it together and they both fail together or succeed together. Once again, incentives drive outcomes. So I think the more you separate the product and design team from an objective perspective, the more they feel separate. But just like at the engineering evaluation, if you say, I'm going to hold you accountable, customer outcomes, the head of the company or the head of the teams, if they say, hey, product and engineering, you might think that you're going to get different evaluation. No, both of you working on the same team or same customer outcome, you're going to be valued the same way. Instantly. You're like, okay, we either float together or sync together instantly. Everything changed when I reorganized and basically the aligned performance, where they got the same grade for 80%, which is a performance piece, and then there was culture and other pieces, they got 20% different instantly. Behaviors changed and became much more collaborative. They were already, I think, part that that was more of a structural issue. But then after the structure, you still need them to collaborate and you put the right incentive in place for the performance review. The other dysfunction is product and eng especially. Look, there are some parts of the company where product range can do stuff by themselves. If they, they do it, it, it happens. But in many sales and marketing and other teams and product range can't just operate in a silo. There's massive. One of the biggest challenges that CEOs of larger companies have is a product range team. They're fully aligned with each other, but they're doing X while my sales team is doing Y. I have to play referee because my sales team is complaining of the product range team and product range team is saying sales doesn't understand what's going on. And so that's maybe the huge source of dysfunction where go to market and commercial functions and product range teams are completely misaligned. So that's the other. Once product range are aligned, then the question is how do you get aligned with the go to market team teams? And I think this is where I increasingly recommend to not do product reviews at all with just product and engineering teams. Instead to do initiative reviews, which are, like I said, the new customer acquisition, you can't just review. You can't just do a review with the product engineering team for new customers. You have to include the marketing lead for that. You have to include the sales lead and you've got to review it holistically. So most initiatives have a holistic piece. There's product engineering is an important part, but it is part of it. Without marketing spending the paid marketing dollars to bring people in, without sales doing the work of whatever it is, and without ops and all of these things, it won't work. So I think that's the other big hole, which is product ranging. Feeling that together they are kind of untouchable and they'll do whatever the hell they want. And GTM has to take whatever product ranging give them and go with it without really understanding the pain the GTM faces the GTM team, broadly, which I mean sales, marketing, ops, etc. So that is, I think, a huge source of this function. Function. Why was the product manager role created 25, 30 years ago? Why was it even needed? It was needed because engineers do all the work. Let's be clear, product manager doesn't do any work. Their work is to really curate and really to be the helper to engineering and design who are actually doing the work to make sure they're pointed in the right direction and to make sure the team is brainstorming the right ideas, put the structures in place and do some outside reporting and so on on how the team is performing and to really facilitate the conversations more than their facilitator and reporter. So you could argue that just like product is a reporter for these two teams, but they don't manage them, they're peers of them. Similarly, when you expand to include marketing, sales, ops, etc. Customer success, you need a different role, which I would call strategy and operations or maybe a general manager role or business manager role who's like the PM but for the entire group of functions that are working on it. If you're running the ads auction team at Facebook, the auction team at Facebook doesn't really. They literally you can do your work, no one really understands what you do. So you can purely be product engineering. You don't even need design for, for the most part. So you don't need sales, marketing, etc. But for most other teams there's some touch. So there that person, this GM or business manager also can be called strategy and operations is the one who runs this meeting and runs overall that initiative of which product engineering are an important part, but one part. So you always saw this start this meeting with goals. What are the goals of this team for this quarter, this time period? Where are we and what is the contribution? And this person also decomposes the Goal or the delta. So if I go from 10,000 to 20,000, that's 10,000 is the Delta out of that product. And engineering contributes 5000. 3000 comes from sales and marketing or marketing, 1000 comes from sales and 1000 from operations or something like that. Each entity or each part of that kind of gives an update on how they're contributing and then they talk about the initiatives they're doing, but it's all orchestrated by this other person. Just like engineering and design work is orchestrated, you could say, but they do the work, but it's just presented and synthesized by the product manager. So this person is a product Manager for sometimes PMs themselves are used in this role where the product manager can. But it puts a lot of burden on the product manager to orchestrate both engineering and designs work at one level, but then zoom out also to orchestrate sales and marketing work. And there's also suspicion because product management, you are kind of doing product development, but you're also orchestrating. So having a neutral third party in some ways who's agnostic and who's not favoring one or the other, but, but really, you know, basically just analyzing objectively is a very powerful thing. So that has been at companies like DoorDash and Uber Strategy and operations function, these people are called general managers, has been a great unlock for cross functional teams.

So we talked about aligning incentives and then don't do a product review, do an initiative review. I'm wondering if outside of the incentives or some of the structural components of doing an initiative review, if there are other effective communication strategies that you've seen that help ensure alignment between product engineering, either communication strategies or structures of communication that you find help either increase the bandwidth or the alignment climate.

Well, the simplest one is something that happens every day which is a quick stand up. Essentially the standup is a way to get everyone on the same page. It's a check in are we on track? And then there is a more sit down kind of thing where once every couple of weeks you evaluate whether you are on track for the goals. But the other role, which I didn't mention is the analytics role, which I mentioned briefly, is really make sure that all the experiments you're running, the data from the experiments is presented back to the team. Because a feedback loop is very important. Important in the earlier way of doing things, there's no feedback loop. You just launch a feature, you're done, you move on. Now, since you are perennially on a customer problem, you need continuous feedback loops to know are you Making progress towards this customer goal that you have. And so who's giving you progress in a real time, semi real time way. And so that every experiment you have, every hypothesis you have, okay, it's directionally right. Let's double down on this thing. It's working. Let's double down. Let's put in fact, let's deprealize the other things for this cordless double down. That's a scorekeeper for the product engineering. That's the analytics team. Continuing to keep score on a real time basis, helping us figure out which initiatives we should double down on, which we should stop. And really also helping using data to generate new hypotheses is basically the analytics team. Again. Many product and engineering teams are very insular in many cases. And adding analytics earlier initially they might protest, but instantly they see lack of data leads to basically a hippo syndrome, which is highest paid person's opinion. And I think our highest, like in some, many cases, engineers, sometimes PMs, whoever, but now there's a neutral arbiter because they look the data says that we should do xyz. So it really facilitates communication in a more objective way. Because most product ranging they do want objectivity, but between them you need a third person or third party, which is data science. So I always say the triad of product engineering and design should actually be a quartet. You also had analytics or data science to it.

The highest paid opinion syndrome I think is no one's saying the quiet part out loud. So in that case, bringing in a neutral party, is there other elements to help make more? Maybe not equitable decision making, but I guess effective decision making where it's not not just defaulted to pay structure. Are there other elements besides bringing in a neutral third party?

I think once you have data and you have an experiment that you've run, it becomes fairly easy. I think everyone needs to align. I think at some point if there are people in the team who insist on ignoring the data and data presented by our partner, the analytics team, then it's got to go up the chain and you've got to figure out why this is happening. And hopefully the two leaders, the product range leaders can debug what is going on? Is this some something else that's at play here?

I wanted to go into a couple specific perspectives that you have that dive a little bit more into strategic thinking or some strategic perspectives that maybe affect these things. And so one of these we think about strategic impact and strategic thinking. We were talking about how to navigate the move fast and break things, demand for early stage companies, but how to do this thoughtfully. And so I was wondering if you could talk about the demands of that environment and how then engineering leaders can better approach or think about that type of demand.

It's a great question. When I was at Facebook the motto was move fast and break things. But when I joined Square, I quickly realized that move fast and break things wouldn't work there. It really comes down to speed versus quality. So there's a product quality and I wouldn't say even quality, I would say stability. I think move fast and break things. It basically implies that it is okay to move fast and break things things. Turns out there are many environments where breaking things will result in your customer's business going down or time sensitive information not getting to the right place. So you've got to look to the context and the product. This is where again, product sensitivity helps a lot. Trying to understand what role your product plays in a customer's lives is a great way to understand how you should trade off reliability versus speed. I remember very well one of my angel leaders. I was giving them a goal. I basically because of some outages we were having, this was several years ago, we were not able to maintain. We had an uptime goal of 99, a 5, 9 uptime goal. I said, why aren't we able to maintain a 5, 9 uptime goal? It's only like 99, like 9, 10.9%. He said, well, here's the thing. What is your product velocity? I said, what do you mean? It's like you want, I can give you 100% uptime goal with zero new launches. Is that what you want? I'm like, no. He's like, how fast do you want checked in code to get to production? I'm like like as fast as possible. It's like great because if you, if you're willing to give me a month before any piece of code gets to production, I can make sure that it's 100% uptime because I'll make sure every piece of code is tested 10 ways and, and nothing breaks. But if you're telling me that every time someone checks in a piece of code and a new thing is checked in, it needs to wake up. We have run these experiments to quickly get out some experiments because the experiments are designed to be lightweight and some things might crash. So basically I realized that that's, you know, a good check metric and that's actually, it's good to understand what is our desired feature veloc and really balance it against uptime and I think the engineering, the leader, the engine leader should present the different trade offs and then the business leader should veto a certain set of trade offs that don't make sense. But I don't. So I think it's actually a continuum between 100% uptime and 100%. I think every company's 100% like you know, instantaneous, like feature, like code complete to feature deployment. I think there is every company somewhere along the continuum. We just need to figure out where we are. Sometimes companies might go from left to right based on where they are in the life cycle or the type of launch they're doing or something else.

And so just like for the sake of being able to summarize. So like when you talk about like the question of what role does the product play in our customer's life. So in the instance if it's like a big fintech product where reliability like matters, then you probably want to focus on reliability if it's.

Yeah, if it's used to run their business or plays a role in their life, which is akin to running their life life. That's why it's important for engineers to go in and observe how customers use this product. If it's a site thing, if they use it periodically, it's going down. It's not going to impact their business. I remember very well we had offline mode at Square, which is when Internet goes down, you still want to take card payments. And this is very important. We never realized that we needed to have because at festivals like Outside Land and so on in San Francisco there would be no Internet access. And so I remember the first time outside happens, we thought the Internet access is everywhere. This was even 10 years ago. You can get it through hotspots and so on. Turns out there was not. Hotspots were jammed, no Internet access. And so the vendors couldn't take cards and people were not bringing cash with them. So all commerce at the festival stopped. It was completely stopped for the first day. And so we got tons of support and we didn't know what to do. I mean we then shipped I think some kind of WI fi things we sent. I mean they got WI fi so it's super expensive and hard. So we started building offline mode for this purpose. And that's an example of the engineers actually came up with this. And the metric specifically was for these festivals which are a big part of our GM DMV basically never let them go down or never have them go down because of lag. But that's an example where we realized that our product was literally, I mean it was fresh product and produce. It should go bad. And thousands of dollars of losses per merchant. So you got to really understand financial. You're right. It is either financial help or something which is that kind of level of Maslow's hierarchy in your business or customer's life. The lower you are of the business, lower you are on the Maslow's hierarchy, or the more foundational you are, the more important it is for your product to be stable and be up when your customer needs it.

The Maslow's hierarchy of customer needs. That would be a fun breakdown. I love that. Gokul, we're nearing the end of our time. We've got a couple rapid fire questions if you're ready to jump in.

Yes.

All right. What are you reading or listening to right now?

I don't listen to stuff. I only read stuff. So right now I'm in the middle of Mistborn. I read a lot of fantasy recently. On one side I'm reading a book called the Mistborn Series by Brandon Sanders Anderson, who's a fantasy writer. And then I basically most recently read More Money Than God, a book on hedge funds by Sebastian Malaby.

Next question. What's a tool or methodology that's had a big impact on you?

I'd say the number one tool that has had an impact on me, probably his methodology is getting things done. So it's a program called gtd which helps you be more productive. So I've incorporated that into how I do email, how I think of tasks in my life, and basically how I don't let things clutter my mind. Mind.

What's a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet?

Pickleball. But pickleball is easily mainstream.

I just got a paddle delivered yesterday.

I'd say pickleball media. There's actually a TV channel called Pickleball TV or I think, I don't know if it's a YouTube channel or Pickleball. We were discussing that it might be more interesting to have more media for pickleball. Just like Tennis Channel has actually become a pretty lucrative property. So pickleball media might be an interesting thing, which is an offshoot of pickleball. But when you have a sport just like NFL Network media around it is also owning media properties around it could also be very interesting.

My favorite subset of pickleball media has definitely been like the pickleball celebrations, the different celebration dances that you can do. Like my favorite one's the fire. You know, they're stoking their paddles on fire.

We need to play for a game of. We're going to meet for a game of pickleball one of these days.

I'll bring my. I'll bring my paddle next time I'm up in San Francisco and I'll make the commute down to South Bay. We'll do it.

Let's do it.

All right, last question. Gokul, is there a quote or mantra you live by or a quote that's been resonating with you?

Right now, it's by Antoine de Saint Exupery, who wrote the Little Prince. French writer. He said, if you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. And so I found this such a beautiful quote because it's all about not being too hey, build an Android app, but get them excited about the customer, the mission, and then they will figure out what to do to get that done.

Such a beautiful and profound quote. To close off our conversation, I just want to say thank you so much for taking your time. An incredible conversation ranging from business impact, customer outcomes, cross functional relationships. Thank you so much, Gokul. Thank you.

Thanks, Patrick. Thank you for having me.

If you're listening to this and you're wondering how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community click our chapters page. You can see that on the menu on the left. Find your local chapter and click Join. We're hosting virtual and in person events all the time and this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to ELC.community, join your local chapter and get involved. A huge thank you to all of our local leaders who make community happen and thank you for listening to the Engineering Leadership Podcast.