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

We're doing a special in episode feature on the future of AI powered incident management with our friends and sponsor X Matter. People as a primary integration layer is really fragile. With multiple people and all of that coordination, you become slower to find the root cause. The slower you find the root cause, you then don't know what action you need to take to resolve it. Getting to that fast is the goal.

Later in the episode, Mike Bennett, who leads the engineering team at X Matters, shares why human-driven coordination creates outage risk and how AI-powered orchestration can dramatically accelerate your path from event to resolution. 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 expertise. 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. 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 GoCool. 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 Goku Rajaram.

First off, Gokul, just wanted to say thank you for joining us. How are you how are you doing today? What's going on? Uh 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 and join us again. I know that there we 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 serving 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, 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 in 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. Now those are somewhat.

abstract and hard for any any given team or individual to 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 say to becoming a customer to becoming a loyal customer or becoming a loyal customer for one product to also ups 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 us get rewarded, promoted, etcetera, and get more impactful products. More ourselves feel more satisfaction. that we're 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?

And a lot of dissatisfaction and enuy and just overall unhappiness in companies is 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 what needs to shift in order to more directly make these types of lanes? The biggest thing that needs to shift is the leaders, you know, both leaders of product and 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 I think we we'll talk about more of product versus engine 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 ten thousand monthly active users to twenty thousand monthly active users. So now we're getting ten thousand 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 a numerical goal within a time frame. And then the product engaging team needs to be given the flexibility to say, hey, there are ten different ways to accomplish this goal. One of which is to launch an Android app, because app

Apps generally result in higher usage and daily usage and whatnot. But there are other ways. Maybe we need to send set up a C R M system or maybe there's six other things we could do. So I think we need to give flexibility to the teams to 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 uh 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 million people are using our service on a daily basis, versus this app launch.

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 or 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. uh versus oh they're just building XYZ in the platform. Platform teams especially suffer from that listlessness because they just feel super removed from everything that's

We're taking a quick break for a special feature on the future of AI powered incident management with our friends and sponsor XMAT. Mike Bennett, who leads the engineering team at X-Matters, shares why human-driven coordination creates outage risk and how AI-powered orchestration can dramatically accelerate your path from event to resolution. We're the ones that are correlating the alerts across the platform.

We're the ones that have to remember that a similar issue happened six months ago and this is what we did about it. We're the ones that have to figure out this is a symptom in service A. But it has a dependency in service B that we need to know what that dependency is and how that could impact this thing. We decide on who is gonna be page based on some informal knowledge.

It's it's not scalable. I mean that all of that works in a in a very small scale environment. But as as systems grow, as teams grow, people as a primary integration layer is really fragile. So the outage risk is with with multiple people and all of that coordination, it you become slower to find the root cause. The slower you find the root cause, you then don't know what action you need to take.

to resolve it. The risk there is not knowing immediately what the problem is, so you don't know what the route for that mitigation is. With all of the information that is out there, getting to that fast is the key goal and is the key problem when you've when you're relying on people to do it. When a signal comes into X Matters, the first thing that you can do is based off of that signal, you can then make a call out to the right people.

Rydyn ni'n ymwneud â'r proses yn ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses ymwneud â'r proses From there, the incident commander can then use automations that are set up in the incident because it it automatically creates an incident for us.

It's linked to the ticket that generated the incident. And from there we can determine, okay, well I've seen I've seen this before because my incident suggestions is saying this looks similar to this incident you had last week. We've got built-in automations that can do stuff. So within an instant you might have an automation that says automatically restart pods or automatically rollback services. Like I mentioned before, we can also do that as part of a response.

to the signal that comes out to say, okay, this has happened, do a rollback and I can just Touch my phone and go back to bed without even getting out of bed. All of the automation, the flexibility of the tool and all the the things that you can build in along with the data that you've got with the service catalogue, with your on call, with your who's on duties and get you to get the right people at the right time on the call if you need to get to a point where you're in a conference.

X Matters automates the entire incident lifecycle, taking you from initial event to final resolution. To see how their purpose-built AI slashes your resolution times and gives your team the context to stop disruptions before they start, head to xmatters.com. That's x-ma-t-t-e-r-s.

dot com. I want to go back to what you mentioned about the distinction between the 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 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 um 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 can we'll talk more about how they operate as a unit. But they need to when given a more tactical goal, uh, which is like I said, much more specific around do this. They need to push back. It's 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 can 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. Let me 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 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 sh making that shift to structure based on customer outcomes? You start I think you st uh it's a great question. You first have to prove to the org that it's work. Orgs have uh you know, many orgs might have done this for years or even decade plus, where they're just focused on being

feature focus. They just launch feature after feature after feature and that's how they measure their success. Ask for promotions, you know, celebrate things, etc. To move from that to an outcome or customer focus org, you need to prove

Likely anything you need a hypothesis. Hypothesis is that this org, customer-focused, outcome-focused 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 once once a company stops acquiring new customers, however good your retention is, your growth is going to slow down and eventually go to zero. Or eventually going to be very slow, maybe even 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 your customer acquisition or sales or something, they don't have a dedicated product engineering team focused on your 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

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 might be placed 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've figured out how to work with product marketing, etcetera. And they are part of the team that gets this new customer goal. And and basically operates at it and you'll very quickly see that 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 that are new customers. So people start

understanding and appreciating and and being more customer centric just by the nature that they 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 who you want to be. So you start with the 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 start for more dedicated engineering. They know that if certain onboarding flows or self serve things can be expedited or or even some SEM things or SEO things, you know, can be done better with engineering, instantly things will improve. Uh but they don't have the ability to ask for it because

What is the the next step for a broader rollout? So we've we validated this this model works. How would how would you recommend engineering leaders start to continue to reorient and and build around this this type of operating model? We basically figure out what are the customer we 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 of articles of a month times the average or 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 are already a customer prior month plus reactivated times average order value. So you basically have a team focus on each of those three. And sometimes to start with you have the churned and reactivator repeated reactivator in the same bucket.

Maybe you 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 and then you basically have each team have a goal around increasing or keeping flat depending on what it is or preventing leakage 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 I like this idea of brainstorming where not in a group session where everyone gets together and some people are, you know, not engaged. Everyone brings four ideas. P you know the product manager, whoever it is, lays the context out. Here's a 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 ten thousand to twenty thousand. 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 are have an hour 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 twenty different ideas.

Um and I think you can quickly sort rank them. So how you rank them, I I use a simple framework called ICE, which is impact, confidence, and effort. And impact confidence effort, you you basically it's like what's the impact design? If you did this and if it worked. How many people would it impact? It's like the reach essentially, you know, and 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 ten thousand to twenty thousand. This thing can add five thousand new users or this thing can add three thousand users or one thousand. So you sort it 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 you again t-shirt size it. And then finally, effort. How much does it actually cost to basically roll this thing out or to implement this? So that's basically ice.

And then you look at those three scores, you know, or or t-shirt size, then 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 ten thousand 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 time frame is important, the smaller the amount of time, the less you have to go fit the 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 hypotheses? 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 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 you know, web app we could create and and surround it with other is 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. Uh, but the things that are easier to test.

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 a feature is a customer facing Hypothesis And you're basically doing something to change the customer's experience or to test his hypothesis. And typically you should only do it for

Five or ten percent of customers. If it works, then you roll it out. And a feature launches when you roll out this experiment to hundred percent of customers. So and 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 the biggest challenges that engineering leaders face when they're they're making this shift to focus on on driving customer outcomes? Lack of data. Lack of data to quantify different things. That's why I think analytics of data science is an important fourth pillar to add. Good analytics of data science can quickly give us the data that

that that we might not have to be able to to able to make the choice or even have some essentially hypothesis. How do we actually test these hypotheses in in in statistically significant ways and really be able to make choice. So I think that's one and the second one is just

the business equation, being able to decompose those. I've seen that when companies move to this model, a tribe model, 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.

I especially in the way you laid out comparing and testing, like and thinking about impact, high competit confidence, low effort, like even just approaching something from that level, I can get some quick wins within the first three months or some really high, high impact wins. So it feels like you could s get signal on like the the momentum is building uh 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 engine leaders that you can't think of engineers and 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. And you start building hypotheses 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 the teams to stay together for twelve to eighteen 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, learning so that new people can be easily onboarded and loss of team members is not acutely felt.

The other element of this we 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 an engineering world.

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 or like excellence of engineering work in many cases versus customer impact.

And so many times a 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 uh seventy percent of performance review should be based on performance.

Which is performance against customer outcomes. And thirty percent should be based on things like code quality, eng culture, organizing all hands, referring people, etcetera. And as soon as you say look,

Seventy percent of your performance review score is based on your your teams and your ability within that team to influence customer outcomes. So I think that that changes your mentality instantly. Where do you think like resistance comes from for like increasing accountability within engineering organizations?

I think it's again the product changing 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 the CEO of the product. And they basically truly don't let engineering be part of the idea generation stack ranking. So engineering is limiting fees, they have no voice and they just have to implement something that some other org. decided. And if that happens, that's again leads to

frustration. And of course then the engine 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. 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 marketing, whoever it is, task managing resources. They need to provide data or or why do we think? This specific uh feature request, which again I hate the word feature request, this specific 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 exp 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. And all of I think all of uh Zuck's directs at this point are essentially ex engineers, Chris Cox, Boss, et cetera. It shows I think at Meta engineers are running the company.

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 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 twenty years ago it was much more of a waterfall model where product writes 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 to the product leader and say one of our teams, the product managers, and then that get the product leader to basically step in and take action. So I think it 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 together because then product leaders depend on engineering to get stuff done. They really need engineering. It's fine. And in fact, one of the number one input into product leaders' own performance review is the engine leaders feedback. So I think that's the easiest way to do it where you make

Two in a box. I I I actually always see. In fact, I was at at a review of large public company yesterday and both the engine and the product leader came to deck together. I mean they basically one of them they could almost see them competing each sentence. They go to 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 that 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. And 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 you painted the picture of this tightly connected engineering and product leaders coming together. So I'm gonna use that as the vision. We're gonna jump into cross-functional collaboration now.

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 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 states? Part of it is there is an implicit it.

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 engineering 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 engineer might set up. 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 there needs to be 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 compliments them, is not trying to usurp them because it'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 uh at being like shunted out or pushed out and like s lack of self consciousness 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, this man.

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, uh Square was basically I was I was 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 back-end team. And then there was a product team and 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 going to g give you the same grade for the outcome of this part. 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 or 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 are we either float together or sink together. Instantly everything changed when I reorganized and basically 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 th 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 engine especially

Look, there are some parts of the company where product and range can do stuff by themselves. If they they do it, it happens. But in many companies, there's sales and marketing and other teams, and product and inch 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 are fully aligned with each other, but they are doing excellent.

while my sales team is doing why, I have to play referee because my sales team is complaining about the product managed team and product managed 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 change teams are s completely misaligned.

So that's the other once product and engineers are aligned, then the question is how do you get aligned with the go-to-market 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 whole 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, et cetera. So that is, I think, a huge source of dysfunction. Why was the product manager role created twenty-five, thirty 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 be 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 facilitate the conversations more than their facilitator and reporter.

So you could argue that just like product results reporter for these two teams, but they don't manage them. They're peers of them. Similarly, uh 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 to engineering. You don't even need design 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 Project 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 at this time period? Where are we? And what is the contribution? And this person also decomposes the

goal or the delta. So if I if I like go from ten thousand to twenty thousand, that's ten thousand is a delta. Out of that, product and engineering contributes five thousand, three thousand comes from sales and marketing or marketing, one thousand comes from sales and one thousand from operations or something like that. each entity or each part of th that kind of gives an update on

how they're contributing and then you know 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 a

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 design 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 is a very powerful thing. So that has been at companies like Doordash and Uber, the strategy and operations function, where these people are called general managers, has been a great unlock. For cross functional deal.

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 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 like either increase the bandwidth or the alignment? Well the simplest one is something that happens every day, which is a quick stand up essentially. The stand-up is a way to get everyone on the same page. It's a check-in, you know, are we on track? and then there's a more sit down kind of thing where, you know, once every couple of weeks you evaluate whether you're on track

back for the goals. But the other other role which I didn't mention is the analytics role, which I mentioned briefly. It's 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. 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're 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, is directionally right. Let's double down on this thing. It's working. Let's double down. Let's put in fact

Let's deep prioritize the other things for this core that let's double down. That's a scorekeeper for the product engineering team, 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 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 uh or highest like in some many cases engineers, sometimes PMs, whoever, but now there's a neutral arbiter can say, look, the data says that we should do X, Y, Z.

So it really facilitates communication in a more objective way because most product rangering they do want objectivity. But between them you need a third person or third party, which is data science. So I I always say the triad of product engineering design should actually be a quartet. You also add analytics on data science to it. The highest paid opinion uh syndrome I think is no one's they're saying the quiet part out loud.

So in that case, bringing in a neutral party, is there other elements to help like make more, maybe not equitable decision making, but I guess like effective decision making where it's not just defaulted to pastry?

Um, 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, you know, it becomes fairly easy. I think everyone needs to align. I think at some point if there are people in the team who insists on ignoring the data. uh and and hypot and 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 leader, can debug what is going on. Is this um 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, like when we think about strategic impact and strategic thinking, you know, we were talking we were talking about

How to navigate like the move fast and break things sort of 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 it basically implies that it is okay to move fast and break 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 century helps a lot. Trying to understand what role your product plays in a customer's lives is uh is a great way to understand how you should trade off uh reliability versus speed. I remember very well one of my angels said

I was giving them a goal. I basically because of some outages we were having, this was several years ago, uh we were not able to maintain we had an uptime goal of ninety nine, a five nine uptime goal. I said, Why aren't we able to maintain a five nine uptime goal? It's only like ninety nine, like ninety ten point nine percent. He said

Well, here's the thing. What is your product velocity? I say, what do you mean? He's like, you want to, 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 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 hundred percent uptime because I'll make sure every piece of code is tested ten 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 up 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 velocity and and really balance it against uptime. And I think the engineering, the leader, now the engineering 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 I don't so I I think it's actually a continuum between hundred percent uptime.

And hundred percent. I think every company's a hundred percent like, you know, instantaneous like feature uh like code complete to feature deployment. I think there is every company is somewhere along the continuum. We just need to figure out where we are. And sometimes companies might go from left to right based on where they are in the lifecycle or or the type of launch they're doing or something else.

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 customers' life. So in the instance if it's like a 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. That's why it's important for engineers to go in and observe how customer uses product. If it's a side thing, if they use it periodically, it's going down. It's not going to impact their business.

I remember very well we had uh offline mode at Square, which is when the internet goes down, you still want to take card payments. Uh and this is very important. We never realized that we needed to have because at festivals like outside lands and so on, in San Francisco there would be no internet access. And so I remember the first time outsyland happens.

We we thought the internet access is everywhere. This was even ten years ago you can get it through hotspots and so on. Turns out there was not. Hotspots were jammed. There was 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 a

for the first year 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 they got Wi Fi so it was 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 and the metric specifically was for these festivals, which are a big part of our GMV.

they know, basically never let them go down or never have them go down because of lag. But it's a that's an example where we realized that our product was literally I mean and it was fresh product and produce should go bad and thousands of dollars of losses per merchant. So you've got to really understand financial, you're right. It is either financial health or something which is that kind of level of Maslow's hierarchy in your business or customer's life.

The lower you are on the business, the 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.

Goku, 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 uh Mistborn. Uh I I read a lot of fantasy recently. Uh on one side I'm reading a book called The Mistborn series by Brandon Sanderson, who's a fantasy writer. And then I basically most recently

Uh, read More Money Than God, a book on hedge funds by Sebastian Mallaby. 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 is methodology is getting things done. So it's a it's it's a program called GTD, which helps you be more productive. So I have incorporated that into how I do email, how I think of tasks in my life and and basically how I don't let things clutter my 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 is actually a T V 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 they're stoking their pet paddles on fire.

So I'm not sure. Patrick, we need to play for a game of we're gonna 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. We'll and we'll I'll 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 Exuperi 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 see. And so I found just such a beautiful code because it's all about not being too, hey, build an Android app, but get them excited about the customer, the the mission, and then they will figure out what to do to get that done.

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. Uh thank you so much, Goku. 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.