Best of 2024: Mastering Intentional Leadership and Building a Winning Culture in Product Teams

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand. Ashok Sivanand It was never about telling different people from different teams what to do, but instead explaining the overall solution and the context and what we're trying to achieve and figuring out what the best solution forward would be. On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] Ashok Sivanand This is what teams are made of. Ashok Sivanand Welcome back to the Convergence Podcast, folks. Ashok Sivanand In our final Best of 2024 episode, we've compiled insights, stories, and advice from our expert guests and leading technology executives on intentional leadership and fostering a strong culture in product organizations.

[00:00:58] Ashok Sivanand We have gathered stories and advice from leaders at Amazon, Netflix, Shopify, Pivotal Labs, Whoop, and a lot more. Ashok Sivanand Leadership and Culture were certainly not things that I learned at engineering school. Ashok Sivanand I observed a lot along my career, made a ton of assumptions, read books and things like the Netflix Culture Deck.

[00:01:20] Ashok Sivanand But it wasn't until I moved into leadership roles myself and ultimately founded and grew a company that I was really challenged with what it took to lead through influence rather than authority and how to be deliberate in facilitating a culture with intention.

[00:01:39] Ashok Sivanand Through many attempts and iterations of trying, reflecting, even crying and then trying again, I developed a more structured and methodical approach for myself. Ashok Sivanand And I'm excited with the clips that we've compiled that reflect approaches that very successful technology leaders use to lead their teams and foster a culture that's aligned with their organization's goals.

[00:02:06] Ashok Sivanand On the episode, we talk about inspiring communication. Ashok Sivanand We talk about learning about the current state of your systems and your team by going and seeing or Gemba for you lean nerds. Ashok Sivanand Guests share some pretty counterintuitive tips on facilitating meetings that drive durable decisions and effective problem solving. Ashok Sivanand We also get to hear examples of how organizations who prioritize writing tend to surface and share the best ideas

[00:02:39] Ashok Sivanand We also do a bonus deep dive specific to product management. Ashok Sivanand Some very successful product leaders talk about how they hire and train their PMs. Ashok Sivanand Subscribe to the podcast to get future episodes as soon as they're published. Ashok Sivanand If you find this helpful, give the podcast a five-star rating on your podcast app or hit that like button on YouTube.

[00:03:09] Ashok Sivanand Our first set of clips today is about communicating effectively as leaders. Ashok Sivanand The First Guest is Ben Foster who co-founded the Prodify Group. Ashok Sivanand He was also the chief product officer at the wearable fitness company Boop and is super tenured in the product space, Ashok Sivanand Ben Foster who co-founded the marketing company Boop and is super tenured in the product marketing.

[00:03:33] Ashok Sivanand Ben talks about the importance about being inspiring in your communication to every single member of your audience. Ashok Sivanand And in this case talks about communicating product roadmaps. Ashok Sivanand I love alignment there because I noticed that a lot of the time the naysayers or the folks that seem like the folks that are being roadblocks,

[00:03:58] Ashok Sivanand Often times when you go to a person level with them and try to understand why, you realize that it's often times a lack of context or missed context. Ashok Sivanand And so communicating the roadmap, arguably more important than nailing the roadmap. Ashok Sivanand And what are some things that you've seen that have worked really well to get everyone on board where they're remembering that?

[00:04:22] Ashok Sivanand Yeah, you know, Ashok, your point about communication is just such an important one because it's not just about coming up with the right answers, right? Ashok Sivanand It's about coming up with the right answers in such a way that everyone is inspired by those answers, that everyone is motivated to go get their stuff done, that they understand the other parts that other people are working on, that they're not stepping on each other's toes, etc.

[00:04:43] Ashok Sivanand And all that really stems not from just answering the question of what should we go work on next and why, but making sure that there's real alignment through that communication that you're referring to. Ashok Sivanand So when it comes to communicating a roadmap, I usually like to bundle it with a communication or at least a reminder of what the vision is. Ashok Sivanand You know, where are we headed? Ashok Sivanand If we're going to plant a flag at point B and we're standing at point A today, what does point B look like? Ashok Sivanand What is this kind of like promised land that we're trying to get to?

[00:05:12] Ashok Sivanand And then to describe the strategy, you know, in order to get there, here are the steps that we're going to need to take. Ashok Sivanand Here's the bets that we feel like we need to make. Ashok Sivanand Therefore, the roadmap has the following major kind of like themes that are part of it. Ashok Sivanand We've worked with the engineering team, we've done the customer research, and here's why we're doing the things that we're doing. Ashok Sivanand This team's going to be working on this part of it. Ashok Sivanand That team's going to be working on that part of it. Ashok Sivanand Here's how it all comes together. Ashok Sivanand Are there any questions?

[00:05:35] Ashok Sivanand And I think it'd be sort of like framed that way, as opposed to saying here's a Gantt chart that has a bunch of dates and a bunch of random projects on it. Ashok Sivanand You know, you're kind of getting at the why. Ashok Sivanand And I feel like sometimes that's the part that gets forgotten. Ashok Sivanand Because like you said, that's what allows the empowerment of the teams to go make their own decisions, right? Ashok Sivanand Because you're providing them not just you're not just giving them orders like go build this thing. Ashok Sivanand What you're saying is, I want you to go solve this problem. Ashok Sivanand And here's the context that's behind this. Ashok Sivanand Here's why you need to do that. Ashok Sivanand That's actually.

[00:06:06] Ashok Sivanand It's especially inspiring and it's especially empowering to those teams when you can provide that kind of thing, because now they get what they're trying to achieve, they get how it's going to be measured. Ashok Sivanand And now they have the freedom to make the kinds of calls that they need to, so they can build the right kinds of things for the customer and for the business. Ashok Sivanand Next, we have Janice Frazier, another extremely tenured product person. Ashok Sivanand I got to learn directly from Janice during our time together at Pivotal Labs.

[00:06:35] Ashok Sivanand Among the various roles she's done, she's a co-author of her book, Farther Faster Way Less Drama. Ashok Sivanand She's held product lead positions at TaskRabbit and even used to work on product at Netscape in the mid 90s. Ashok Sivanand In this clip, Janice talks about communicating vision to your team and the importance of clarifying both point A, which is today's current state, and point B, our destination.

[00:07:03] Ashok Sivanand She goes deeper into her opinion on how to do well on both, to inspire your team and being really engaged collaborators and joining you in that journey. Janice Frazier It all starts with knowing where, like knowing that path from point A to point B, right? Ashok Sivanand So if you say, here's where we are right now. Ashok Sivanand So the model we use is SCQA. Ashok Sivanand This is Barbara Minto. Ashok Sivanand She developed this back in the 60s.

[00:07:32] Ashok Sivanand Situation, complication, question, answer. Ashok Sivanand So she created the communications protocol that's used by McKinsey even today. Ashok Sivanand So if you say, well, what is the current situation? Ashok Sivanand The current, you know, let's have a hypothetical. Ashok Sivanand We were just talking about tied laundry detergent. Ashok Sivanand The situation is that we know that plastic use is a problem. Ashok Sivanand We know that we need to reduce carbon emissions.

[00:08:02] Ashok Sivanand There are these ESG guidelines. Ashok Sivanand Every company on the planet has a 2030 carbon reduction goal and a 2040 carbon reduction goal. Ashok Sivanand So that's the current context. Ashok Sivanand But that's not the whole situation because there's a complication there. Ashok Sivanand The complication is that companies like Procter & Gamble, every company that's publicly traded, is beholden to a board of directors,

[00:08:26] Ashok Sivanand Who's beholden to the analyst phone calls every quarter, who are beholden in turn to the shareholders. Ashok Sivanand So there's this immense quarterly pressure to maintain current amount of sales, right? Ashok Sivanand To grow sales quarter over quarter, year over year, to increase not only top line, but to maintain a strong bottom line, right?

[00:08:50] Ashok Sivanand So there are all these externalities that are forcing companies like Procter & Gamble to take up a certain amount of shelf space at the target at the Walmart. Ashok Sivanand And how do you take up that much shelf space if suddenly the form factor of your product is tiny, right? Ashok Sivanand It tanks your sales.

[00:09:14] Ashok Sivanand So now what are the, there are good reasons to maintain certain amount of linear feet in the laundry detergent aisle. Ashok Sivanand So now you have these countervailing forces and you have to figure out what would need to be true in order for us to go to market with a smaller package.

[00:09:32] Ashok Sivanand So the situation complication question answer is like, so the complication is that we have two competing external forces at the same time demanding different movements from us. Ashok Sivanand So that's just true. Ashok Sivanand So now how, so then you can ask the question and devise an answer.

[00:10:02] Ashok Sivanand And the question is, how might we meet both of these apparently conflicting goals of, you know, changing our formulation and package in order to meet our ESG goals compared to maintaining our prominence on store shelves in order to meet our sales. Ashok Sivanand So our consumers sales throughput.

[00:10:30] Ashok Sivanand And, you know, there's, there's, when you really get to this level, there's no good answer, but you can't come to an answer unless you have a good formulation of the question. Ashok Sivanand So that's what we really focus on is what is a good formulation of the question. Ashok Sivanand And once you have smart people focused on the right question, then you can begin to devise answers. Ashok Sivanand And I can't speak to what, you know, we're now in very theoretical P and G imagination land.

[00:10:59] Ashok Sivanand So I don't know what they're doing to reconcile those two things, but that's how I go about the process. Ashok Sivanand Fostering an engaged product organization and aligning them with the principles around lean, human centered design and agile will more than likely lead to successful business outcomes for your organization. Ashok Sivanand But getting started or getting unblocked can be hard. Ashok Sivanand This podcast is brought to you by the player coaches over at integral.

[00:11:28] Ashok Sivanand They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile. Ashok Sivanand Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:11:48] Ashok Sivanand During this session, the integral team will facilitate a problem solving exercise that gives you clarity and confidence to solve a product design or engineering problem. Ashok Sivanand That's integral.io slash convergence. Ashok Sivanand Now back to the show. Ashok Sivanand Let's go back to something else you mentioned around point A and point B.

[00:12:13] Ashok Sivanand And I've been super lucky that I got to be trained personally by you on a lot of the facilitation techniques. Ashok Sivanand Point A to point B is a term that I had used a lot previously. Ashok Sivanand And I thought, okay, I'm going to skip over this chapter of this and kind of zone out a little bit and realize that there's so much more than I had thought about really getting into the depth of both point A where we are and then point B where we want to get to.

[00:12:40] Ashok Sivanand So maybe let's hear your version of how to be maybe rigorous or disciplined or things to think about when you're defining each of them. Ashok Sivanand So point A we've touched on. Ashok Sivanand I really think about this situation complication component. Ashok Sivanand And when I think about what is the situation, that's usually the easiest part. Ashok Sivanand But if I tell the situation myself, I'm going to get one version of it.

[00:13:09] Ashok Sivanand But if I ask two other three other people, what is your version of the situation? Ashok Sivanand Okay, now we have a really rich picture because it's inevitably that that you or they see the world see the situation slightly differently. Ashok Sivanand And this is where having a diverse team helps and I mean functionally diverse any any dimension of diversity. Ashok Sivanand I happen to believe in, you know, diversity inclusion as a business success strategy.

[00:13:35] Ashok Sivanand But if you get people from different points of view, simply stating their version of current state, you will have a much richer, much more diverse picture, a much clearer picture of what is actually true because you're looking at the problem from multiple sides.

[00:13:54] Ashok Sivanand Now, then you do the same thing with complication and especially if you're working from a functional diverse team perspective, you're going to get a very different set of circumstances than if you just think of it yourself. Ashok Sivanand This is where I, you know, for a while I was calling this, the whole book, I was calling it facilitative leadership because the leadership motion that's most important is facilitating other people sharing information, right?

[00:14:22] Ashok Sivanand So if I, if the prompt is, what's making this hard? Ashok Sivanand What makes it difficult to move forward on whatever this initiative is, you're going to get and you have a cross functional team, you're going to get that cross functional viewpoint. Ashok Sivanand Now you're equipped with a much richer understanding of the challenge in front of you. Ashok Sivanand And, you know, you can. Ashok Sivanand There are two ways to get that data. Ashok Sivanand Number one, you ask for it up front and you get a rich picture up front and you start to strategize around how we might move forward despite the

[00:14:52] Ashok Sivanand Number two, you get stuck somewhere in the execution phase and you get frustrated and people get mad at each other or, you know, you or, and, and then you have to do a big fact finding uncover like why are we blocked. Ashok Sivanand So if we just take even an hour, half an hour to evaluate from multiple points of view, what is the situation? Ashok Sivanand What's the complication?

[00:15:16] Ashok Sivanand We're going to be able to create a better strategy for enacting whatever the, you know, the objective is the motion. Ashok Sivanand And then how about on the point B and any tips on clarifying the vision or the destination? Ashok Sivanand We tend to plan point B as a result, like a, an output, right? Ashok Sivanand At the end of this, we will have a report at the end of this, we will have a something.

[00:15:47] Ashok Sivanand And it's, that's a, I think of that as a very fragile way to organize a plan is much more effective if you organize a plan around outcomes. Ashok Sivanand It's like, what is the result? Ashok Sivanand If we were to do these things, if we were to create this, whatever the noun is, this output, what will, what will now be true?

[00:16:09] Ashok Sivanand And the analogy that I use is like, you know, if I'm on San Francisco Bay and I'm sailing a boat, I can say I want to get to Berkeley and I can sail my boat from San Francisco to Berkeley. Ashok Sivanand It's not going to be a straight path because, you know, the wind changes and something, you know, another boat comes out from under the bridge or whatever. Ashok Sivanand Right?

[00:16:32] Ashok Sivanand So our plan, the way that we normally plan is like we say, I'm going to get in my boat, I'm going to sail straight ahead, I'm going to turn left, and then I'm going to sail straight ahead again, and then I'm going to turn right and I'm going to like be there. Ashok Sivanand Like we make this plan as if we can anticipate exactly what's happening. Ashok Sivanand But you know, the world is dynamic right now and crazy stuff is happening every day. Ashok Sivanand So you just never know.

[00:16:55] Ashok Sivanand So having a plan that is organized around outcomes is much more durable and resilient, and it allows for just in time planning of the different activities. Ashok Sivanand So it releases just some of the pressure to execute on the plan exactly as you wrote it in the first place, as if you had a crystal ball and could imagine a perfectly executed plan.

[00:17:21] Ashok Sivanand Next, we have Jose Moreno. Jose is the CEO of Newlight and was the lead engineer on Netflix's shared account feature that resulted in billions of dollars for the company globally. Ashok Sivanand He shares a leadership principle from his time at Netflix, which is context over control.

[00:17:47] Ashok Sivanand You were the lead on a pretty critical service that was used by all the users in all the countries, and you maybe had to change the way you allocated work to folks on your team based on this value. So is there anything that you can recall there in terms of changing your leadership style? Ashok Sivanand I think a lot of it was getting buy-in. Ashok Sivanand Once again, like context, not control is another one of those lines that they use quite a bit.

[00:18:17] Ashok Sivanand And something that I ultimately really love. Ashok Sivanand For me, it was never about telling different people from different teams what to do, but instead explaining the overall solution and the context and what we're trying to achieve. Ashok Sivanand And then having a conversation with them and figuring out what the best solution forward would be. Ashok Sivanand Right? Ashok Sivanand Like, I think it's very egotistical for anybody.

[00:18:43] Ashok Sivanand And this is a big part of what I loved about Netflix and what I think makes them so successful. Ashok Sivanand It's that you're not relying on a CEO or VP that knows all of the answers in the world and exactly like how customers are going to react in order to make sure to decide how you're going to move forward. Ashok Sivanand But instead, you take the diversity of opinions from everybody to try to find what that best solution is. Ashok Sivanand As long as nobody's egotistical or like says, I need my solution to be the thing.

[00:19:12] Ashok Sivanand But instead you actually sit down and find what the best solution is, and then you all agree and march forward with that solution. Ashok Sivanand That ends up being a lot more effective than relying on one person's skills. Ashok Sivanand Rounding out our tips on effective communication. Ashok Sivanand We flash back to an episode where I hosted Bailey O'Shea, who is our head of product at Integral and now leads product teams at Trans Impact.

[00:19:40] Ashok Sivanand Bailey and I both talk about how to engage product teams by contextualizing technical work in the lens of who we're serving and what problem we're solving for them. Ashok Sivanand I can think of a time we were kicking off a new engagement with a client and the client's goals were around kind of their they were rapidly scaling startup rapidly scaling.

[00:20:03] Ashok Sivanand They wanted to transition to more of a technology enabled startup and they wanted to build out their technology team and their capability internally. Ashok Sivanand So they talked a lot about that, but not as it related to kind of the product vision specifically. Ashok Sivanand So as we were going around the room, somebody said within the press release, you know, this company is named as Forbes top 100 places to work. Ashok Sivanand The CEO and everybody really responded to that.

[00:20:33] Ashok Sivanand And then we had a conversation around like what is the developer experience? Ashok Sivanand What is the product experience that they need to have in order to hire the right talent where this could be where this is true in the future? Ashok Sivanand So we were not only talking about what we were building, but how we were building it and the principles and the methods and the norms that needed to be in place to scale it accordingly. Ashok Sivanand Yeah, I love it.

[00:20:57] Ashok Sivanand And I think, especially for teams where you're not used to hiring product team members and you're transitioning toward being a technology company, that insight is really helpful to get all the way up to the C-suite so that you're not making decisions like you are hiring for a manufacturing company or a finance company. Ashok Sivanand And you're thinking about what tech hiring is, and it is certainly nuanced. Ashok Sivanand So it's a good opportunity to get that conversation also planted as seeds across the team.

[00:21:27] Ashok Sivanand I think another great element over here is also it can lead to, it's an opportunity, not necessarily the press release, but this conversation more broadly. Ashok Sivanand It's an opportunity to share what difference we're making for the customer. Ashok Sivanand And I think regardless of what role that you play, whether you're on the technical side, the customer side, the business side, you can resonate with things if it is stated in a more relatable way.

[00:21:55] Ashok Sivanand I remember that one room we were both in, the founder of auto refinance company talked about how they were able, they showed an example. Ashok Sivanand And I don't know whether, I still don't know whether he did this intentionally or it was one of the, when he did a demo of the existing product that we were refactoring, he, he, he showed us a case of a veteran that they reduced the car loan from a 25% interest rate down to like 6% or 5%.

[00:22:23] Ashok Sivanand And I could see in the room, everyone, regardless of what role they were playing, were really jazzed about going out and building things that can help have more of those stories and improve the lives of that many more people. Ashok Sivanand Another one I remember was when we worked on a, a ride hailing application for, for medical transit.

[00:22:46] Ashok Sivanand And the product lead or the business owner came in and she talked about how this is a problem that impacts around 3 million Americans who don't have access to healthcare because they can't get there. Ashok Sivanand And very quickly, you could see people in the room starting to think about someone in their family, someone in their community, someone in their neighborhood that relies on a friend or family or someone else to get to their dialysis or chemotherapy or whatever else.

[00:23:12] Ashok Sivanand And how, how, how much harder their life is than what we assume. Ashok Sivanand And it gets the team really inspired about, in that case, driving accessibility to mobility. Ashok Sivanand And you, you, you bring in extra ounces of energy for sure when you can really relate to the problem and you feel like you're making a difference in the world.

[00:23:31] Ashok Sivanand And I think there's another, I'm going to leave you with one third story here and really drive home the point that I think the business person in the room, the person who is familiar with why this is being done, it maybe takes another 10 minutes of prep to really share some of these stats that can, stats or stories, frankly, that can get the team energized.

[00:24:04] Ashok Sivanand And I remember the product team wasn't necessarily very jazzed until we realized these are folks that don't, that haven't sat in that room, in the F&I room at a dealership for three hours waiting for that one person while their kids are running around, just driving everyone insane in the dealership.

[00:24:25] Ashok Sivanand And how we were able to then share like, Hey, this is this many hours on average multiplied by this many people who are buying a car every day that now they're able to do this with a few clicks online, spend more time with their family or whatever they're passionate about. Ashok Sivanand I don't know too many people who are passionate about spending time in the F&I office, no offense to anyone there.

[00:24:46] Ashok Sivanand And all of a sudden you could see that transition from saying, Hey, we're building an online leasing and financing application to a, we are bringing a lot of delight to a number of Americans and reducing the friction or the frustration that comes from sitting and waiting and drinking the mediocre coffee in this office. Ashok Sivanand And, and then all of a sudden the team's a lot more energized. Ashok Sivanand You find that people show up with ideas the next morning, right? Ashok Sivanand Trying to find new ways to solve the problem.

[00:25:17] Ashok Sivanand And for me, I'd rather have more ideas, even if I have to sift through a few more, because it tells me that the team is on board with solving this problem. Ashok Sivanand There's a high level of engagement there. Ashok Sivanand Fostering an engaged product organization and aligning them with the principles around lean, human centered design and agile will more than likely lead to successful business outcomes for your organization.

[00:25:46] Ashok Sivanand But getting started or getting unblocked can be hard. Ashok Sivanand This podcast is brought to you by the player coaches over at Integral. Ashok Sivanand They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile. Ashok Sivanand Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:26:12] Ashok Sivanand During this session, the integral team will facilitate a problem solving exercise that gives you clarity and confidence to solve a product design or engineering problem. Ashok Sivanand That's integral.io slash convergence. Ashok Sivanand Now back to the show. Ashok Sivanand The next set of clips is about how we gather information and form opinions as leaders.

[00:26:39] Ashok Sivanand Both lean manufacturing and lean product folks have likely heard the term Gemba, or going and seeing where the actual work is happening. Ashok Sivanand In product organizations, the where can be a little amorphous, especially in today's hybrid world. Ashok Sivanand Farhan Thaur, the head of engineering at Shopify, joins us.

[00:27:02] Ashok Sivanand And he talks about a few ways that he both gathers and shares context with his extremely large engineering team using a very hands-on and unique approach. Ashok Sivanand And a lot of the things you said, whether it's recruiting, other reviewing, like pull requests and other things like that, you're staying sharp as a leader. Ashok Sivanand And that's not necessarily the case across the enterprise, right?

[00:27:28] Ashok Sivanand So what is like advice you have for your peers or people that report into you about staying sharp that way? Ashok Sivanand Yeah. Ashok Sivanand I actually like that, your accountability club idea, like the 5am club. Ashok Sivanand So one of the things I try to do here is scheduling like pairing hours. Ashok Sivanand And so what will happen is my admin will basically like just ping a different direct report every week and say, Ashok Sivanand Hey, Farhan's going to pair for an hour with someone on your team.

[00:27:54] Ashok Sivanand And then she will schedule an hour with that person and then I will just pair with them on whatever they're working on. Ashok Sivanand Sometimes it's, you know, I paired with somebody, they were building developer tools. Ashok Sivanand It was a BS code plugin. Ashok Sivanand Like these are kind of really just way for me to get to know a person, but also to like be in, be in like an editor when we're talking and ask questions. Ashok Sivanand And what I find is even if I don't know the language, like I was pairing with somebody, they're doing Lua.

[00:28:19] Ashok Sivanand I've never done Lua, but it's, it's interesting for both people because it's interesting for them to hear how I'm thinking about what they're working on. Ashok Sivanand And it's interesting for me to watch them go through the developer workflow and see the entire end to end of trying to build something. Ashok Sivanand Sometimes you get something built in an hour, sometimes you don't get that far, but I think that's one way. Ashok Sivanand Well, I'm curious. Ashok Sivanand Do you think it drives discipline? Ashok Sivanand Because like all those folks know, hey, Farhan could drop in to pair with me anytime.

[00:28:46] Ashok Sivanand So I'm going to relatively keep my house in order. Ashok Sivanand So I'm not doing a bunch of cleanup and stuff retroactively because there's a guest coming or. Ashok Sivanand I think, I think maybe yes and no, I think that yeah, culturally, if the leaders are more technical and ask detailed questions and do technical reviews, like that gives the, the team and the company like leeway to say, you know what? Ashok Sivanand I need to prioritize this against features because I know that, you know, the, like the Steve jobs, the inside of the Macbook must also be beautiful. Ashok Sivanand Right.

[00:29:16] Ashok Sivanand So I think that is, that is, that is nice. Ashok Sivanand But I also just think that it shows them that depending on which career path they want to go down, whether it's individual contributor, because you can, you know, go all the way now at Shopify or management, that technology is something that we are in love with. Ashok Sivanand We are technologists and we are, you know, in love with, you know, software. Ashok Sivanand So if that is not your ethos, then maybe like Shopify is not the right place for you.

[00:29:43] But if it is, you can figure out so many ways to have impact here via your love of R&D and software. Ashok Sivanand Next, we have Earl Newsom, the CIO of Cummins. Ashok Sivanand Before that, Earl was in the Navy, played Division One football and held CIO roles at Lind, Praxair, TE Connectivity and Estee Lauder companies.

[00:30:09] Ashok Sivanand Earl also talks about a hands-on approach on how he connects and learns for him, his organization in today's remote world. Ashok Sivanand I love both of those lessons. Ashok Sivanand I want to go a little bit deeper on the second one, especially the point that you mentioned about getting in there and getting your hands dirty with the team.

[00:30:28] Ashok Sivanand I find that this is something that some executives that I come across require a little bit of coaching or nudging to do, maybe because they don't write as much code or they're not as familiar of the modernity of the code that's being written today. And there's just some level of vulnerability maybe or some other factor where they don't want to feel exposed around the team or they feel like they're too far removed from it.

[00:30:53] Ashok Sivanand I'm curious, what advice do you have for those folks or any stories you have about getting in there, rolling up your sleeves and how it's different from other executives you worked alongside? Ashok Sivanand I think, again, that's a great question. And, you know, there's going to be times where you're not going to know because the syntax is different, right? You know, but that's really just a syntax issue. It's not a logic issue, right?

[00:31:15] And so what you can do is bring your logic to bear and your insights to bear on any particular, you know, challenge regardless of the language, right? And so, you know, there is, you know, as I think about that, this idea about how can we learn and apply, you know, what we've seen and intuit it and apply it to somewhere else. And so I think that's this logic idea and that you should be able to see patterns, right?

[00:31:43] And so what we're bringing, you know, to bear as executives is our ability to see patterns in our experience. So it's experience and patterns, right? You bring those two things together to whatever problem is where they're talking about a Python problem, a C++, a COBOL, a Pascal. Now, I was a Pascal programmer, a UCSD COBOL programmer and those kinds of things. You know, got into C Sharp a little bit.

[00:32:08] But, you know, today it's Python and Databricks and whatever it is and low code kind of things. But what you can do is you can bring your ability to see patterns, right? And so don't be shy about your inability to code in Python. You know, I can't code in Python and I don't intend to. But the idea is I can talk to somebody who's a Python programmer and use my experience and patterns to have a discussion with them about how to do it.

[00:32:38] You know, here's what I need this code to do. Here's how to talk to customers. Here's how to talk to end users. You know, you use your practice of ethnography. And I love that concept of walking around and seeing what people do and implying human insights to whatever the technology is because we need both.

[00:32:57] So we need your expertise, your ethnography to walk around and see what your developers are doing, what they're creating, and then help them see through your experience and your ability to recognize patterns to make it even better. That's how you get your hands dirty. You get your hands dirty with what you can do. Janice Frazier is back.

[00:33:18] And she talks about perhaps an anti-example of how a company made assumptions instead of going and seeing and how it led to maybe more costly iteration than what could have been. Like we talked about, the complexity of outcome measurement trickles down into complexity of performance measurement against that outcome as a subset, right?

[00:33:42] One of my favorite things in basketball is, sure, we've got points and rebounds and all the things that you would usually see on like your rookie cards. And there's another stat that is measured called a plus minus where when that player is on the floor of the five players, what is this? Like is the score generally higher or lower?

[00:34:05] And they may not add two points or rebounds or assists directly, but there is a stat that says, we don't know why maybe from this one stat, but the team's usually 10 points ahead when this person's on the floor. For sure. For sure. I love this. I love this concept. I wish that we had a universal name for it. And so I have two stories about this. There was this guy, his name is Aaron. He was a designer at Pivotal.

[00:34:33] And when there were new pivots, when somebody, so working at Pivotal for those who aren't familiar, working at Pivotal was a very specific kind of culture, right? There was a certain amount of emotional intelligence that was required. And we just had a way of working that was really unique. And it usually took a few months, two, three months for people to sort of detox from their previous work experience and to just kind of settle into the deeply empathetic workplace that we had.

[00:35:04] When Aaron was on a team, new hire pivots, within a month, they were completely onboarded and working seamlessly. Nobody knew how he did it. But we all knew if we had to get a new pivot up and running really quickly, you'd team him with Aaron. It just doesn't matter what role they are. You just put them on the same team as Aaron and they would come up to speed really quickly. Super magic. It was magic. It made people productive.

[00:35:31] Because what I would imagine would be done is if the company is trying to optimize for onboarding, they'd look at Aaron and say, Hey, there's something that Aaron is doing that's different. Let's go do in the day in the life study or something like that to understand what's Aaron doing differently. And they'll come up with what they think is the reasons, but really are probably closer to assumptions or hypotheses.

[00:35:58] And then tell all the other designers or team leads to say, Hey, going forth, you must do these things as a checklist. Tell me if you're doing them or not. And sometimes forget to say, Hey, what we want to do is optimize for bra sales or we want to optimize for having the lowest onboarding time. And there's some benefit in studying what Aaron, like what makes Aaron successful. And there's also some pitfalls. And so help me navigate through like, well, that's not what they did. What not do. Yeah.

[00:36:27] There are two things that they did. Yeah. Two things that they did. I just, I feel, I feel like you say this. These are the mistakes that they made. They made Aaron a manager. Aaron was, Aaron was not a great manager. Aaron didn't want to be a manager. It was too stressful for him. And part of what made him so good is that he was really empathetic and he was very kind to the people. Right. So, so he just was a great individual contributor. So that was the first thing.

[00:36:51] The second thing was somehow make Aaron in charge of the onboarding process. Also not at all what he was good at. And so eventually we all figured it out and Aaron just went back to being the person that they would pair you with if you were new. But it would have been much better to go examine day in the life. What is it that he does? And how is that different from what other people do?

[00:37:22] And yeah, but that wasn't your question. So what was the question again? Yeah. I mean, let's carry on. Right. Like in that hypothetical where we said what would have been better if they did the day in the life of Aaron. And I think the concern or the question comes up for me around, okay, this is something that's specific to Aaron and may or may not apply to everybody else. And say we come up with onboarding guidelines for the other folks that are pairing in with the new hires. We could give them a list of things Aaron does and have them optimize for that.

[00:37:51] And that's starting. My gut tells me that's a little bit more on the output side versus saying something like, hey, we really need to onboard folks quickly. Help us out with that. This is maybe something that works. And that's my best guess. So I'm curious to know what you might do with that information later to do the outputs versus outcomes thing. Yeah, yeah. This is really interesting.

[00:38:12] So the outcome is that being on a team with this individual means that people get it faster. So if that's the outcome that we want to replicate, I would look for, you know, what are the things about Aaron that I would come up with hypotheses? What are some things about Aaron that are making it possible for that person to come up to speed?

[00:38:37] And then I would see if I could find other people who exhibit the same characteristics. Rather than trying to have a checklist or whatever, do this, do that, do the other thing. It's like there's this really ambiguous outcome. The ambiguous outcome is ready faster.

[00:38:53] And probably the inputs that are creating that outcome, ready faster, probably the inputs are something about emotional intelligence and kindness and articulate about describing their craft and willing to take time to explain the whole organization, that kind of thing. Like, okay, these are things that this person does naturally. Let's see if we can find five other people. Okay, now maybe we can say, well, let's do a buddy system.

[00:39:22] Let's just like have people who are natural onboarders. Right? And let's keep an eye out now for the profile of person who's able to welcome people in in a really effective on target kind of way. So it's like if you value the outcome, then you can actually come up with three or four different experiments. Right? To say, well, what if we make my manager? Nope, that didn't work. What if we make him in charge of training? Nope, that's not it. What if we, right?

[00:39:50] So by valuing the outcome, we give ourselves permission to make a flawed plan. Notice that the plan is flawed. Try again. And that way, yeah, folks have the context to iterate their way towards why we're doing all of this in the first place and also some level of coaching and context and, hey, this is what's worked for everyone else.

[00:40:09] And I like the behavioral aspect because I think we forget about that in terms of it's not what is Aaron doing, it's what is it about Aaron and how they show up and their values or their behavior. And the thing that I think is really notable about this from an outcome output standpoint is outcomes, outputs, and activities are kind of the three ways that we talk about this. There's a thing you could do, right?

[00:40:36] There's the result of work done, you know, the tangible outcome or output from work done, and then there's the outcome. And in this case, the actions would be what is Aaron doing? The thing is we don't know what Aaron's doing, so we could make a plan around those actions, and the plan could not deliver the outcome, right? The plan was let's make him a manager. Let's make him in charge of training.

[00:40:59] Let's make him do, like, we can come up with these actions, but if we're not focused on the outcome, then the actions will never deliver value. This is the thing that frustrates me. So much work is done that delivers zero value. Outrageous amounts of work is done in this world that delivers zero value. I heard a statistic, and I've heard it repeated about once a decade for the last 30 years, that, like, 85% of IT investments never see the light of day.

[00:41:28] So it's all this work time. Like, that's a lot of work time. Even if that number is inflated, you know, is double what it is. That's still an outrageous amount of waste in the system at a time when our planet cannot handle waste. Like, we need to be much more effective.

[00:41:51] We transition to segments about facilitating effective meetings and how, as leaders, we can support durable decision making and making sure that we're solving meaningful problems in our meetings. We have Janice continuing here, and she shares a framework that I think is super actionable and easy to implement right away. I learned about it from one of the partners at Bain Consulting.

[00:42:21] And I call it the Bain Decision Making Model. And it is a two-meeting solution. And the first meeting, you prepare for it. Somebody prepares for it. And it's a one-page, you know, summary of facts and alternatives. Here's the decision to be made. These are the salient facts. Here are the options available to us. And the purpose of meeting number one is to agree.

[00:42:50] This is the decision to make. These are the salient facts. And these are the options available to us. If you can agree on that, that's the whole point of meeting number one. Then you take a week, two weeks. You do any research you need to in between times. You have your side conversations. You figure out kind of what needs to be figured out in between times. You have a second meeting. And that second meeting is only half an hour, 45 minutes long. It doesn't have to be long.

[00:43:17] And that meeting is for decision and resourcing. So at the second meeting, the second meeting's purpose is not just decision. It's actually resourcing. And what that does is it creates durable commitment. So you have this framework that everyone in the decision process agrees to. It says our first conversation is about these couple things. Our second conversation is about those couple things.

[00:43:45] And everyone shows up ready to do those things. I love this process. I've run it several times. It works like a charm. Having the resourcing part of that makes it a prioritization question, not just is this a good idea? Is it a good enough idea? Is it better than the other ideas that the same budget and the same constraints are drawn against? And it creates lock-in. It creates actual, like, we are leaving this room committed.

[00:44:13] We have committed resources to this course of action. Josh Seiden, a product expert and co-founder of Neo, acquired by Pivotal Labs, talks to us about how leaders can facilitate meetings that drive progress rather than just talking about status updates.

[00:44:30] Now, while he's specifically talking about running an update or check-in for OKRs, I think that the framework can be applied to breathe life and usefulness into any milestone or check-in meeting. Any caution or advice in terms of how do we make these meetings and check-ins really productive and energizing versus another status meeting that doesn't necessarily drive any new prioritization or decisions or insights?

[00:45:00] Yeah. So, the first rule of thumb is you want most of the meaning to be forward-looking. Right? So, let's look at the numbers. Let's understand where we are today. Right? But most of the meaning is about planning what we're doing next. Right? What are we doing next week? Right? Right? What are we doing next month? And so, that's part of it.

[00:45:28] The second is that it really is, I think people need to understand their roles. That OKRs are really, really good for problems where we are working to discover the answer. Right? Right? So, we always want to be talking about what we've learned, what we're deciding based on what we've learned, and what we need to learn next. Right?

[00:45:57] And I think, you know, if it gets into sort of teams defending what they've done, then we've sort of lost the script. So, I think, you know, for a leader in that meeting, it really is, tell me what you've learned in the last week. Let's say, tell me what you've learned in the last month. Because that's really where the weekly meetings are for the team. That's it. Right?

[00:46:26] But it's that monthly meeting where we're sort of having a more formal presentation to leadership. The questions around leadership are, what have you learned? What have you decided based on what you've learned? And what do you need to learn next? Right? And then the next question is, you know, how can I help? Right? But that what do we need to learn next is really the focus of the meeting.

[00:46:50] And I think in some ways, if you've spent any time in the design world, right, the sort of attitude here is that this is a critique. Right? We're trying to make the work better. Right? We're not trying to hold the team's feet to the fire. We're not trying to, you know, prosecute people. Right? We're working together to make the work better. So what do we need to do to make the work better? And what do we need to do? Where's the learning focus for the next period?

[00:47:20] Good writing is oftentimes undervalued. I know this personally as someone who avoided any courses in university that required writing and also in my early jobs. I was faced with reality when I rose to ranks in the corporate world. I needed to learn on the job to write well, to increase the leverage on my time and the value that I brought. And I even ended up having to hire a writing coach. Farhan is back here.

[00:47:46] And he talks about the benefits of the good writing discipline they have at Shopify. Going back to the process cannot be a replacement for thinking. You know, I had some, like, dumb luck when I was in engineering school. And you probably had the same where you're forced to do non-engineering electives. And I hated writing, which is, like, kind of ironic because I spend so much time trying to learn writing now.

[00:48:10] And so I would go find, like, the multiple choice type of examination courses and only pigeonhole myself because I knew I could do well at those. And I'm optimizing for grades, not for learning, unfortunately. But anyway, one of the things I got to learn was critical thinking because that, again, ironically, critical thinking was a multiple choice course, which I don't know if it should be or not. And I've heard that at Shopify, you mentioned thinking here.

[00:48:34] I've heard that Toby also, like, really focuses on this, like, science of thinking or this, like, thinking about thinking. And he's at thinking clubs and stuff. You and I have talked about mental models before. So how do you do that as a culture? How do you do that as a big organization where you focus on the skill of thinking? Yeah, it's a very – so Shopify is a very cerebral organization. We have a book bar which has, like, systems thinking is one of its books. We interrogate mental models a lot.

[00:49:04] We think about things, like I mentioned, like, you know, process shortcuts to say, hey, don't have a process if it's not going to enable something new or make something 10 times faster. We have a writing culture. So when someone asks a question, if we can't point to a link or a doc or some write-up, we have a hard time reasoning about it because we don't know if somebody has actually spent the time to actually interrogate their thinking process there.

[00:49:28] Now, there's a downside to this where you could overthink and overwrite. And now, you know, you write a document and everyone's got to read it. Like, are you just wasting everyone's time? So you have to be careful on, like, what you're actually trying to accomplish.

[00:49:44] But culturally, we do a lot of the thinking in – I would say inside the company, like in public inside the company, whereby, you know, if someone's asking me a question about how should we think about payments infrastructure or how we think about resiliency, like, we will – someone will have likely thought about it and written something down. And we might codify it somewhere, either in our wiki or we have something called the codex.

[00:50:09] And that allows us to then share the fully formed version of the principle to everyone else. So that's a shortcut for them to use in the future. But it is much more a writing cerebral company than I've ever been at. And sometimes feedback you might get from something might even say something like, you know, how did you come to this conclusion? Right?

[00:50:34] In which case, having somebody walk through the thinking and you say, oh, I see an assumption you made here, but I've got context over here that you might not have that might change how you think about it. Let me tell you about it. You might say, oh, knowing this information, my conclusion might change now. So let me take that new information.

[00:50:51] So we try to, like, you know, face – like, come face-to-face with reality quite often because that might actually change your thinking and then change the conclusion of where you end up. And I know I'm speaking, like, in the abstract, but it's not that abstract. It's like, here's a project. Here's the data we've seen. I mean, we know the customer likely knows way more about the problem than we do, but at the same time, we likely know more about the solution than they do.

[00:51:16] And so let's come together, spend time and figure out, like, what is – do we understand the problem better? And then can they understand how our solution might help them solve that problem? But you want to make sure you are doing both sides of that. And we do think – we do do a lot of thinking here. But I will say one thing before people, you know, if they're listening to this podcast, say something like, wow, you know, there's lots of thinking and a lot of doing.

[00:51:42] We have this other principle, which is maybe counterintuitive to what I've said, which is something around action creates information. And so actually doing things – so yeah, of course, thinking and there's docs, but, like, actually doing something, like building a prototype, trying something multiple ways, will produce information that you can then refine your thinking on. So one big thing happens here is somebody will say, I'm not sure which way to go, A, B, or C. I'm like, cool, go all three ways.

[00:52:11] Try all of them. And then let's look at – if it's a coding example, build a prototype with all three different libraries, look at the coding and the runtime characteristics, and then decide. Versus researching and talking and writing a Google Doc, that's probably not something that is, like, how Shopify works. Our next clip features Deepika Yaraguntha.

[00:52:37] Deepika is the head of platform products at PepsiCo, and she brings a wealth of leadership and product experience for her time at both Intel and at Amazon. You may have heard about Amazon and how they famously did away with PowerPoint presentations in lieu of well-written documents. And Deepika shares her experience about it at Amazon.

[00:53:02] Inside a company like Amazon, how does something get greenlit before it comes to you? And then maybe from there I can come back to this, but segue into what you learned about how product strategy looks like at Amazon. Yeah. Such a good question because I wish that more companies thought about innovation as a culture. Right?

[00:53:29] Everyone talks about innovation, and innovation is something that we bring it as an afterthought. There's a team that does innovation. Like, you'll hear this so many times. Oh, I was in the innovation team at AT&T. Right? But to take what the innovation team builds and bring it back into the business is almost like an impossibility.

[00:53:47] You know, because, again, change management, culture shifts on Amazon is the, I think, biggest, like, example of how innovation should be part of the DNA of every team. Right? When you talk about Amazon and you say, oh, I want to compete against Amazon. Which part of Amazon? Amazon has 1,500 companies combined into one. Right? Every team had a startup mentality.

[00:54:16] We worked in silos intentionally, like you were a startup without any hindrance in moving as fast as possible. Right? And the biggest thing there, the artifacts, frankly, were the six-pager document. Right? This infamous six-pager document, and I'm sure you've heard about this innumerable times, was the idea that you were a startup founder. And Deepika, build a $100 million business for me.

[00:54:45] And I am the VC. Right? And I will hear your pitch out, ask you all the hard questions. And then if I like it, I will give you enough money to go start a two-pizza team. Right? The term two-pizza team is how many people can eat two pizzas? Just about 10 people. So that was sort of the fundamental, you know, plan. Right? But, of course, there were like variations of this. The six-pager document was never a six-pager document. Right?

[00:55:14] It was written as a PR FAQ. So it would start with a press release, followed by three FAQs written from the customer's perspective, the, you know, engineering or development team perspective. And then lastly, the partner perspective, depending on, you know, what perspectives you needed that weighed in on building that product. And what does partner mean in this context? In this context, for example, TV manufacturers could be a partner. Right? Got it.

[00:55:44] Understood. Yeah. So this idea that you want to answer the topmost questions on anybody's mind forced you to build products that only somebody would buy. Right? So, you know, onboarding, for example. How would I enable Alexa in my TV? Like that could be a question on my FAQ document.

[00:56:08] And in order to answer that, I have to now have a detailed plan on what are the requirements for that onboarding experience? Is it like a, you know, capture? Is it a phrase? Is it a code that I get to my phone? I have to really think through these things? I have to work with engineering. I have to work with design. I have to have the most seamless experience. Right? And so that's the rest of your strategy. Some of these documents took me like, I don't know, four or five months to write and get approved.

[00:56:37] But it showed you that before we made any investment, every possible thing that we could analyze and kind of remove. Right? Any assumptions that you were making where you qualified those assumptions. And you said, great. I tried to answer it to the best I could by talking to a partner. They gave me these answers. I'm satisfied with these two data points, but I don't know what the rest of the market will say. Right? And stating all your assumptions up front was amazing.

[00:57:05] I mean, you know, some of these documents ran to like 36 pages, I won't lie. But the fact was you answered every possible question there was and had a lot of confidence in building these products. And, you know, at the time that I was at Amazon, I think there were like 5,000 product managers. And I will say that it was a very strong product management led company.

[00:57:27] And so I think that that allowed for a lot of innovation to happen organically through different aspects of the company. Our last segment today is about recruiting and enabling a really solid product team. We get to hear from Farhan on his philosophy of trying before you buy when it comes to hiring and recruitment and how he likes to collaborate with the recruitment team as their head of engineering. You're a much bigger org than when we work together. How involved are you in recruiting now?

[00:57:57] And like, how much can you delegate? How does that look? Yeah. So I'm pretty, I mean, very, very involved. I mean, I know when we kind of changed models, right? When I first got to Shopify, I remember meeting with the recruiting team because I am, you know, somebody who likes to get involved in recruiting. And I remember meeting with that team and they're like, oh, you don't like, we don't need your help that much. Like we actually have like this own machine that's kind of running. And I was like, it's not really how I like to do recruiting. Like I like to be chatting with people out in the industry all the time.

[00:58:25] I make connections from people right out of school and interns all the way up to like senior people. And I like to play it as like a very long game, right? Like meaning you might meet somebody like one day and then three years later, they might reach out to you and you've, you know, stayed in contact with them about the problems that they're working on. And then it turns out that the overlap of what they're doing and what you need has come to fruition only then. And so from a recruiting perspective, I spend a lot of time talking to candidates.

[00:58:54] I like to inspect the process as well. And so when I meet candidates and then they apply, I actually will have a back channel. Like I'll say, hey, well, how was it? Like how long did it take? How was this interview? Did you find it useful? What about this part? All the way through to the offer. And it's a good way for me to kind of spot check our process. I'm always trying to like do that feedback loop. The other thing I would say is I'm a big fan of like try before you buy if you can do it. Meaning like, can you have like have somebody be an intern?

[00:59:23] It's like a job interview for them and us because they could realize it's not for them. Same with like contracting or same with people onboarding. I try to make sure that the first three months of anyone starting is really a way for us to both see if this is a fit from a company perspective and what we expect. And if it's not, let's, you know, call it early. If it is working, let's double down and make sure that we're focusing on the strengths of the person and what their new role is.

[00:59:51] And so, you know, we have this idea also where we like to be pretty hands-on. Meaning like we say in these words sometimes explicitly like, hey, we don't think like micromanaging is a bad thing. Like we want to make sure that everyone's pairing and involved in all the decisions. And that could be different for someone coming in from the outside. Right? Everyone's going to be involved. You might comment on your PR. Like that's normal. And that's because we want the best people working together with the rest of the best people.

[01:00:20] It's not like hire smart people and let them do what they want. It's like hire smart people and pair with them. That's literally what we try to do every day. Jose is back and he talks about the keeper test at Netflix. The keeper test essentially asks whether or not you're better off paying the person that you're paying at that current position for the work that they're doing and the expectations that you have for that specific role.

[01:00:45] Or if you would be better off going out to the open market and finding somebody else at that same exact salary. Basically, is this person meeting the expectations of that role for the compensation that they're making? That's the question that they ask. And managers are supposed to do it every single quarter. Now, you don't have that conversation with your manager every quarter, but you can ask your manager where you stand in terms of that keeper's test whenever you want.

[01:01:16] And so it's a constant evaluation. And this isn't just like managers doing it for the people on the ground. This is directors doing it for managers, VPs doing it for directors and CEOs doing it for VPs. I saw change at every single level at Netflix during my tenure there. And so the keeper test is something that happened from top to bottom. Right.

[01:01:42] And then, so the answer to that question, was it kind of binary of yes, no? Is there like maybes? How did that all work out? I think that there's a concept of a tie. Why? So if you look at a person in a role for a specific salary and you say, you asked the question and you're wondering, are they better off keeping that person or are they better off going into the open market? And you're thinking, I'll find about the same level of talent. Then you're definitely better off staying with that person.

[01:02:10] There's an extra dimension that you have to think about after letting somebody go. Right. It takes time to fill that role again. It could be six months, depending on the level. For higher levels, it could be longer than that. And so it has to be like the person has to not be meeting those expectations to really make that decision that you're better off going over to open market. Because you're essentially saying, if I pay somebody else the same, they're going to do better than the person that I have.

[01:02:35] But if you're going to go out to the open market, invest six months and try and find somebody else and they're doing the same work that the person that you have is doing, you're better off staying put. It's a really difficult decision. I think when I first became a CEO, when I founded the business and I remember the first person that we had performance issues with and we had to terminate. And I asked a bunch of my peers who had been running businesses longer about their advice on it.

[01:03:01] And it's like everyone was taught by some mentor somewhere to say the same thing, which is the only thing I regret was not doing it sooner. And I can see how this is something that will drive that urgency and discipline rather than urgency, maybe of not going too long where you're not making a decision that needs to be made.

[01:03:24] And really, as much as it looks like the company is better off because they're hiring someone else, in many cases, I have seen that the employee ends up finding your role that is more energizing for them as well.

[01:03:38] And so one might be able to argue that it's beneficial to both sides, but there's a decent counter argument to that as well, which we don't necessarily have to get into right now because I'm curious to know more about the values there where when you have a really powerful team and you're constantly checking around this powerful team, you end up, I think, providing a lot of autonomy to these super high performers.

[01:04:04] And there's values like freedom and responsibility, which is sort of counter to maybe a lot of traditional businesses that run maybe manufacturing or healthcare where it's a lot more command and control and top down. So I'm so curious about what that looks like as a lead working on something as important as account sharing. Yeah, it's very easy to focus on the keeper test because it sounds negative. It sounds scary.

[01:04:33] And in some ways it is. But you have to think about the benefits that you end up getting by applying something like the keeper test and focusing on only building superstar teams with superstar talent. The philosophy was that if you can keep people that are dependable, that are great at their job, that are creative, then you don't have to put a lot of processes around them. You don't have to be the one that tells everybody what to do.

[01:05:00] So Reed had a little line inside of that culture deck, the original one that said that if you wanted to sail the sea and needed to build a boat and needed people to build a boat, don't make plans of what that boat's going to look like and how to be built and then go and tell people what exactly they need to do.

[01:05:20] But instead, go out, find other people that are super passionate about sailing the sea, get them to yearn for the sea, and then have everybody work together to figure out how to build that boat and how to get out there.

[01:05:35] And so it's a lot of empowerment for everybody that's within the company and being able to put a lot of trust in them and allow them to make the decisions that they need to make without them having to worry about getting approvals or a lot of check-ins with higher up in order to make sure that they're doing the right thing.

[01:06:01] We're going to go deeper here and a lot more specific about hiring and training product managers. Jim Simpson joins us and he talks about what tends to make the best product managers. Jim is now the CEO of Blue Myra and used to head product at the cybersecurity giant Duo Security that Cisco acquired. Jim tells us about what backgrounds and attributes he thinks the best product managers tend to have.

[01:06:30] Jim Simpson I'm curious to know, you know, given that PMs come from different backgrounds and we're usually making some level of judgment call like Doug did with you if they haven't worked as a PM before. Do you have any biases or weaknesses for any sort of adjacent traits around folks who might be good at PMs? Jim Simpson There's sort of like my idealistic view of the world and then the practical things that I've seen.

[01:06:57] What I would say is like the best product managers I've seen come from the technical side of the house. Typically, they are either former engineers who have, you know, an ability and a desire to connect and communicate with other people. Jim Simpson So I think all engineers are smart, but it's like if you want to be a good product manager, you have to actually want to go and talk to people. And in my experience, many engineers are like, I really don't want to be in meetings. Like meetings are terrible.

[01:07:24] It's like if you are kind of anti-meeting, you probably should not be a product manager ever. And then there's also solution engineers, which are typically the folks who are bridging the gap on the sales side between the product and a prospective customer. Jim Simpson And, you know, I see a lot more inbound from that. And the first question I typically ask is like, why do you want to be the product manager?

[01:07:46] And a really good answer is when they are interested in solving customer problems and, you know, want to learn more about how to do that. Jim Simpson The more common thing I hear is like, if I'm the product manager, then we will make the right decisions in the company. And for me, I'm like, okay, great. So you think this is all about like you deciding something versus how we're actually doing it here and you don't seem to recognize that.

[01:08:10] So we're also seeing success are folks who have a background in storytelling because as a product manager, one of the things you have to do is pull together a lot of different threads to then create a narrative that drives an outcome. I also think that one has to have tenacity and, you know, a little bit of fearlessness because you're going to be saying no to a lot of people and you're going to be going into ambiguity and the unknown and trying to create that.

[01:08:40] Ben Foster is back and he tells us about his hiring process for product managers and how he trains product managers that come from a technical background on business acumen. Ben Foster I know your path there to getting into product. I'm sure along the way you've had to hire, manage, maybe manage out a number of product folks. When you look at a resume and when someone tells you about an experience, is there anything that maybe stands out to you

[01:09:10] that you might more likely take a chance on someone? Ben Foster Sure. You know, it's really hard to get through a resume. It's easy to tell a story about the kinds of things that you've done previously. I certainly, one thing I look for in a resume is do they talk about the outcomes that they delivered? Do they talk about the customer value that they created? And if they can talk about those things, then usually it's a very good sign. And if they say, you know, my job was I managed this thing and I told 20 engineers what to do at a time. It's like, you're just thinking about, you know, your role in very much the wrong way.

[01:09:37] So I'll pass on those people and I'll kind of, you know, have the other ones come in for an interview. To me, the key is actually during the interview. And my thing that I like to do is I want to see how they make decisions because product management is all about judgment. You're making decisions all day long. This design or that design, this customer or that customer, this priority or that priority, right? Like just all day long, it's decisions. And it requires good judgment to be good at doing product.

[01:10:05] And what I don't like are those questions like, you know, where you give them like a textbook question. You're just going to get a textbook answer where you say, tell me about a time when you blah, blah, blah, blah, blah. And it's good to ask that. I want to know that they have experience with it. But a lot of times they're working as a team. And so it's really hard to know what their individual personal contribution to that would have been or what would have happened had it been a different product manager in their seat instead of them. So what I like to do is have them put their money where their mouth is.

[01:10:31] You know, somebody might say, oh, I always make data-driven decisions or, you know, whatever. You're like, okay, like, well, here's a case that we have. Here's the thing that we're running into at this company right now. How would you think about this? You know, what, how would you make a call on, you know, here's what we're faced with. Like, how would you do it? And it's funny how many times people say, oh, I always make data-driven decisions. And you throw something in front of them and they don't ask a single question about data, you know.

[01:10:58] Or you ask them like, okay, what experiment would you run in order to get the data that would allow you to make a good decision? It's like, oh, they make good data-driven decisions when somebody hands them the data. But I want to know at a startup, you know, are they going to be able to figure this stuff out on their own, not sort of be reliant on some other party to go make this happen? So I try to see how they actually think. And a lot of times what I'll do is I'll question their judgment on things and see whether they can stand when they need to and whether they can also back down when they need to.

[01:11:27] So, you know, if I give them some sort of like a quick assignment or whatever and have them, you know, share with me what their thoughts are, I don't care whether they got the right answer. Of course, they're not going to get the right answer. But if I say, hey, I'm not really sure that I agree with this part. Like, what do you, you know, here's some very good rationale why I think this might not be a good thing. Are they just like totally stuck with their own thing because they came up with it? Well, guess what? That's how they're going to act when they're on the job as well, right?

[01:11:54] And if I give them some sort of pressure or some sort of, you know, feedback saying, I'm not really sure about this, but it actually is a really good idea, I think. I'll sometimes challenge them on that and I want to see like, can they convince me that they're right? And do they know that in this case, they should convince me that they're right? And in this case, they should sort of like change their minds. And if they can do those things right, then it's an indication that they have good judgment. But it also shows me how they work with other people, with their peers, how they work with people who are superiors to them in the organization, et cetera. And I want to see if they can be effective in that way.

[01:12:22] And if they can, you know, to kind of back to your original point about communication, that's what I'm able to assess is their judgment and their communication. Staying on this topic, say you've hired this person, they're maybe post-technical, but they seem to do the problem solving and everything in the interview pretty well. In a product role, they've got to think like a business person, integrate into the technology teams.

[01:12:46] And like in my case, I would bias a lot towards the technology and it was not quite second nature to think about the business. How, if you've encountered this, what do you send folks off to, to help get their business acumen up to speed or it's hard? Yeah. You know, I actually decided to build my own on that. So when I was at, when I was at Whoop and I've done this at other companies as well, I created a, it's called a mini MBA for product managers.

[01:13:15] And, and I go through here, the metrics that you need to understand. Here's how this business actually like really works from a financial standpoint. I'll take the, the models that the CFO has and I'll put them up on a screen and be like, look, we're going to walk through this. And I want you to understand the difference between all these different types of revenue. What's the difference between, you know, you know, revenue looking back, what's the difference between that and ARR? What's the difference between ARR and MRR partway through the year?

[01:13:40] And what's the difference between, you know, this and that, like, I kind of go through those things and make sure that they really understand the differences because I want to make sure that we have a shared language with which we can talk about these things. I can give them that context and say, Hey, look, we're doing great when it comes to the unit economics, but you know, Hey, let's take the, you know, the subscription business with hardware. We actually in the short term lose money with every customer that we acquire. So, you know, we could do that, but if we actually grew too fast, it would be a problem financially for us, right?

[01:14:09] Like we need to do this. So you're saying like, why don't we do more with marketing or whatever right now? Like maybe that actually isn't really the right answer. And what we should do is something in building this, you know, kind of better product over here. That's going to have more lasting effect. Or, you know, if I can get more cash up front because I can get more people to pay for an upfront annual subscription as opposed to paying month to month. Then they've paid for themselves right now. And that allows us to recycle cash really swiftly to then reinvest it in marketing spend to then go find more of those people. So why does the percentage matter in these regards?

[01:14:39] This is why, let me explain it to you. And I think it's important that you do that for the individual business. It's not like general MBA kind of stuff. Like if it's a subscription business, talk about the subscription metrics. If it's B2B SaaS model, talk about those things, right? But make sure that every single product manager who's on the team really has a good appreciation of this. And one thing I've also done is try to invite the engineering leads and the UX leads into those conversations as well. So that everyone is talking about the same kinds of things.

[01:15:06] And it's amazing to see their eyes light up and be like, oh, I finally like get it for the first time. Okay. And it completely shifts their ideas of the things that they need to focus on. And it unlocks all these ideas that have been sort of like, you know, sitting there that they didn't think were important. Because they didn't really understand the business context in which they were operating. I love that. And I think a lot of business leaders are hesitant to share that level of detail with the team. And most of those reasons are us negotiating with ourselves.

[01:15:33] Every single time I've done it or I've convinced a client to do it, the number of ideas that the amount of creativity that you unlock in your team, once you give them a combination of creativity and confidence is amazing. And there's something we're always hesitant about with respect to finances that we don't want to share too much. But we want folks to be business people alongside us. And that's the core scorecard at the end of the day, regardless of what we're building, right?

[01:16:02] You cannot have empowerment without transparency, period. All right. I'm going to be following up with you to find out more about this mini MBA. Nice. I might be able to learn something too. So I got the flip of that question. So we got some PMs that come in from non-technical backgrounds. And not all of them have to learn how to code in order to be really effective working with engineers.

[01:16:24] But at the same time, it's good to know enough so that you can be collaborative where that you're not putting a lot of that onto the engineering lead or whoever. So what's the thing that you would have that non-technical PM learn to know enough? You know, it's really hard to point to a specific course or, you know, a particular kind of presentation. I wish it was as simple as it was on the other end, to be totally honest.

[01:16:49] In my own experience, I never learned to code. I can't read anybody else's code. I don't know what it means if I check it out. But over the years, I've learned pretty well what kinds of things are easy, what kinds of things are hard, what kinds of things are possible, what kind of, you know, what a memory leak means, you know, any of that kind of stuff, right? That helps me to do my job best. And I think it's essential that you have an understanding of those things because otherwise you can't participate in the conversation.

[01:17:18] You know, engineering is saying, hey, this thing is falling behind. Here's why this thing is more complicated than we thought. What we've got this tradeoff that I need you to help make. Well, how are you going to participate in that if you don't really understand the details? You're just going to have to take it at face value. And that means you're not really in control of the decisions getting made. What kind of quality judgment, you know, so what we just talked about, can you really make if you don't really understand the context? And so I think you need to have some of those kinds of things. Honestly, in my case, it was picked up just on the job through experience, having conversations.

[01:17:46] But I think that the thing that I look for is people who are really curious. Because the curious people will start to learn those kinds of things more and more and much more quickly than somebody else who doesn't necessarily have it. So it is important that it's there. But I don't think you need to learn how to code either. You know, I think that some companies will say, I'm never going to hire a product manager who doesn't know how to code or something like that. And, you know, if I'm a case in point, like, I don't think that it's actually necessary.

[01:18:12] But the way I would think about it is it's very similar to, like, let's say building a house, right? You have somebody who's, like, designing a house. And that's, like, the product manager. And then you have, like, you know, the architect and the builders. And those are really the engineers.

[01:18:31] But you're going to be a really crappy house designer if you don't know what materials can support what weight and how, you know, the physics of building a house actually works and what the nature of the foundation needs to be. And even other things like legal requirements for building in that area and things like that. Like, you have to have an appreciation of these things because that's the medium in which you're going to be operating. And it'll be like a sculptor not knowing anything about stone.

[01:19:02] Like, you know, you might have a vision for this three-dimensional object. But, like, you kind of need to understand where it chips and how it doesn't and, you know, things like that. And that doesn't mean that you have to be great with a chisel. But it does mean you have to be around it a lot. And I wish I had a great answer for how people could really accelerate getting there other than just straight-up experience and exposure to it. But that's honestly the best answer that I can think of. Yeah, fair enough. One of the things we've done or I've done is I'll pair with someone on building a spreadsheet together.

[01:19:30] And it's like one of the more, like, I'm one of those folks that in another life I might have competed on, like, competitive Microsoft Excel kind of stuff. Like, I get dopamine out of it for whatever reason. So I'll pair with them and I'll say, hey, I need to build this dashboard. And this is the data. So we got to get from this data set here. And this is what it's going to look like because this is what I need to show the board or whatever. Like, what's the steps along the way that we're going to take?

[01:19:57] And then, you know, how do we make that an interactive dashboard where the data gets manipulated? And then the next thing you know, they understand kind of like all the steps along the way of the architecture. So even if you don't know how to write code, you're at least able to talk to an engineer about, like, hey, at what layer of this are we trying to solve this problem? Where does it cut through? Where should it be isolated? And so forth. And so, you know, that was something we could try out sometime. I am pretty good with Excel as well.

[01:20:29] Deepika is back and she talks about specific types of product manager archetypes that she hires and allocates and three core competencies that she looks for in hiring product folks. I'd like to switch gears here. And we've gotten to hear a lot about your insights and expertise as a product expert. And I want to hear a little bit about as a product leader and a manager of people.

[01:20:56] You and I have had similar backgrounds in terms of how we arrived into product by starting out in engineering. And I've hired a ton of folks who haven't written code before. And I'm curious to know what are some things that you tend to look for in product managers when you're hiring them? Like product management and different companies, again, different things, right? So my thinking is the general idea for most engineers, right?

[01:21:25] Engineers can build anything, right? You can write a bunch of code and you can start building things without needing anything. Similar designers, right? Designers also can design a bunch of things without actually truly like waiting for somebody to tell them what to do. The role that product managers play is in prioritization. Why are you building what you're building and how fast can you build it and how cheaply can you build it, right?

[01:21:54] That's the thinking that somebody needs to keep an eye on and is able to connect all the dots to come out with a big picture. Now, there are two types of product managers, right? One is somebody who's very good at the tactical stuff, very good at execution, and you're able to build rapidly, work with engineers, put the Jira stories together, put a Jira board together, and keep executing. The other type of product manager is a strategic thinker, right? More visionary, more big picture.

[01:22:24] And if you can get both these qualities in one human being, absolutely wonderful, right? But if you cannot, then you have to think about how your team is structured and optimized for the best that you can help. Certain products, I think, that require core business insights and expertise, right? So supply chain, for example, is a great example, right?

[01:22:47] It's, I don't know anything in supply chain, but that was also somewhat of my strength because I didn't know. As I learned, I would ask some core questions. Why is this done this way, right? And that became like an impetus. Oh, we did it because we always did it this way. We didn't know any better. And then I would bring in a perspective. But what I needed was for somebody to have worked in supply chain for a number of years and having some unique insights that I couldn't have.

[01:23:16] So optimizing for core business knowledge and then saying product management can be taught to this person is, I think, one way of hiring, right? But fundamentally, I think three qualities that I look for is, are you curious, right? Is there a core curiosity that you have that you're not just taking everything for granted and just putting your head down and doing it? Two is, are you an active listener?

[01:23:44] Meaning you're asking a question, but the answer is not about the question. It's being about what am I not saying, right? And playing the detective in that conversation and going after those little things mean always keeping in the back of your mind. What's the business goal I'm trying to achieve? Oh, wait, why am I building auto management software when I should be building something else, right? Like having that conversation with yourself constantly.

[01:24:11] And three is this absolute ruthless ability to prioritize, right? The prioritization thing is that means that you're taking everything into consideration, right? You're thinking about your business value. Think about customer value. Think about what engineers can do. What can you build quickly? What can you not do something? What are your data constraints? These pipelines are going to fail. Why am I building this?

[01:24:35] And being on that track and being able to, you know, voice that and communicate that over and over and over again is, I think, are three like just immutable qualities that I look for. The rest is, you know, a bonus, right? It's like, do you have knowledge about the industry? Are you reading constantly? Are you paying attention to what's happening in the market? Are you borrowing ideas?

[01:24:59] Innovation and that X thinking, as I call it, are all factors that, you know, if you get it, great. If you don't get it, then at least you have these core qualities you can pull down. It's also kind of domain specific where you might change that up a little bit depending on what organization you're hiring a team for. Folks, thanks a lot for listening to our best of 2024 clips about leadership and culture.

[01:25:27] This wraps up our first season of The Convergence Podcast. Stay tuned for season two, where we're going to continue deconstructing the practices, principles and philosophies behind the most delightful products and the highly engaged teams who ship them. Hit the subscribe button so you're notified when the first episode of season two launches when we return after a short break. Thanks again for listening along and supporting the show this season.

[01:25:57] It was a ton of fun for me to meet these extremely influential and accomplished guests and to collaborate with them as well as my team to put this show on for you. If you found the show helpful or even entertaining, please give us a five star rating wherever you're listening or watching. It helps the show out a lot and it helps other curious enthusiasts like you to find us.

[01:26:30] Thank you for joining me on The Convergence Podcast today. Subscribe to The Convergence Podcast on Apple Podcast, Spotify, YouTube or wherever you get your content. If you're listening and found this helpful, please give us a five star review. And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today.