Episode 26 | Consensus Driven Cultures, Dev Influencers & Capacity Planning

Jason: [00:00:00] My least favorite type of projects and you see them all the time are green, green, green, green, green, red two weeks before it's supposed to ship. And that's everybody's least favorite projects in the world, but it's actually unfortunately common.

Intro/Outro: Welcome to Developing Leadership, The Podcast for Engineering Leaders, where Eiso Kant and Jason Warner share their lessons on the ins and outs of managing software teams. On today's episode, Jason and Eiso talk about the issues with consensus-driven decision making and the problematic outcomes of mimetic desire and celebrity developer endorsements. Jason also shared his recommendations on capacity planning and the practices he's seen in the best engineering orgs. As always this episode comes with accompanying show notes, with a deep dive into the main topics, mental models and key moments from this episode. You can find them at developingleadership.co and linked in the episode description.

[singing]

Eiso: Hey [00:01:00] everyone, we're back again with another episode of Developing Leadership. Jason and I are gonna be talking today about a topic that we're quite opinionated on, and we've probably touched base on a few times in our private discussions and I like to label it, and probably not everyone's gonna like me for labeling it this way, as "the kids are running to school." what I mean by that is, you know, early on in an engineering organization when we're building the company and we're still small, we really want to, you know, lead from almost like, probably more biasing towards a consensus-driven approach, right?

And we see this, like we're in a small place where, you know, three, four or five people in the room and, and we try to maintain, you know, unanimity and harmony. Because often all of us are quite junior at that stage in the early stage startup, there isn't a senior leader everyone's looking at, but in some organizations that culture remains as you start scaling.

And, and I have to admit that I quite often come across organizations with a 100, 150, 200 engineers where senior leadership, you [00:02:00] know, strongly believes there are certain changes they need to be making to improve the org, but are absolutely unwilling to do so because they are very terrified of getting the consensus of everyone in the org and trying to get the consensus of everyone in the org. 

And so, Jason, let me kind of hear, hear your opinion first on this and we'll, we'll riff from there.

Jason: I mean, where to start on this one, I mean, I've seen it a bunch. I've seen it all the time. In various companies, I've been a part of it a couple of times where I've seen this approach and I've seen it, at all the companies that people know me for. And what I will say is this, I- I think that there's an expectation mismatch that happens with people and what they believe that they should and can have input into inside organizations based upon where they are in the org and seniority and tenure and blah, blah, [00:03:00] blah, all that sort of stuff.

As well as what's, what's, what's right and true and, and, and real for them to have opinions into. Lemme give you a story too. And, and how I can see this go incredibly wrong I was part of an org and senior leadership, and there were 13 people in the room. We're trying to figure out what we're gonna go do. We're doing a review of the quarter, gonna go ahead. And literally the person who was running the meetings more senior than myself said, we're gonna vote on this topic, literal vote on this topic. And any single negative, you know, it was a thumbs up, thumbs down, would kill the initiative going forward. So 13 people- including the person, 12 ups and one down are actually what happened, therefore the entire thing got killed. I could not believe what just happened. And I remember thinking to myself, what the shit was this, like, this was liter- I just, I couldn't believe it. And I've seen it in all-

Eiso: What was the initiative by the way?

Jason: ... in various different forms. Yep I- I don't even remember, but at this point it was more [00:04:00] like, you forget- you forget what someone said, but you remember, I don't even know. And it- it wasn't something life changing. It wasn't something, it was, should we something, something with the HR systems or something, something like, you know, that type of deal, like one, why are we spending that time in this? Two, why did this go to a consensus vote? but you know, I think like what that exhibits too is just that there's, there's, there's a bunch of pervasive things in our industry that happen and this is an example of it, which are: fear, fear of leading is one. Fear of, you know, disappointing others or being, you know, want to be liked and a couple of others.

But this, this whole thing about this consensus-driven culture is just something that popped up in Silicon Valley 10 years ago, 15 years ago, and kind of started its way through. And I- I think, you know, we're mostly of the way through this in, you know, San Francisco based, silicon valley, but the rest of the world is now hitting the tail maybe in the middle of the curve or tow- maybe hopefully the tail end of their own version of cargo culting Silicon valley.

Eiso: Where do we think [00:05:00] it comes from? Right, because it's, it's, I mean, we have, we had a guest recently who said, you know, we have, a hundred years of leadership behind us of studies of research of, you know, and, pretty early on, everybody figured out that consensus-driven, decision making, does not work at scale, or actually doesn't even work in even smaller skills I would say as well. 

How did we get there? Like what, what prompted us to get to that point? and yeah. Do you have an idea?

Jason: I have an idea of how it happens in organizations organically. I think industry wide is a different conversation. Organically, you can see it, you're three people, you need to agree on how to do something. You're 10 people, you mostly need to agree on how to do something. And then there's stages in between. And the most common case is that the senior people are junior themselves, and they don't effectively know how to lead.

And there's always a turning point, there's always change that has to happen in an organization where you basically change your way, your way of operating. And it's you go from that [00:06:00] consensus, kind of everybody has an egalitarian kind of mode, blah, blah, blah, democratic to "no we're doing this." You all don't have to agree, we're just doing this. We're going in this direction and you have to operate that way. You can't run a consensus-driven culture, a consensus-driven organization at scale, it's, it's impossible to do so somewhere between one person and several hundred people, you gotta change it. Most people don't change it. And then there's the fear that comes in. It's too hard to change it. It's too hard to do this, or that won't be liked. And then there's a lack of skill as well.

Eiso: Being liked. How important is it to you? Forget industry, forget, forget leadership. You personally, how important is it to you to be liked? 

Jason: Early in my career it was, it was important to me. It was because I was insecure in my own skills and I unfortunately leaned on being liked as a proxy for I'm good at my job. And if enough people liked me, because that meant I was doing a good job because they liked me [00:07:00] and I didn't actually hit the curve in my career until I realized that was actually very, very wrong, in fact. And once I started to adapt to a different way of working, a different way of internalizing my own, personal psychological needs in that regard, I got a lot better really quickly. But that was one of those things that wa- unfortunately held me back earlier in my career.

Eiso: So if- if I take this with the notion of, you know, fear to lead, fear to lead, you know, need to being liked, they're massively linked with each other. 

Where do you think, the turning point happens for someone who's able to kind of step away from that, and what's needed to make that happen? Like, what was it for you that, for instance, made that change all of a sudden happen? Was it good guidance? Was it just a point yourself that you came to the realization?

Jason: Going back to your earlier statement of the children running the school. It was, it's actually a realization that nobody in Silicon Valley is their Twitter persona or their, Forbes article, [00:08:00] ID, you know, whatever it is. You, you know what I'm talking about? No- no one is that, there's, people are these characters that are made up and I started to meet some of these people. And when I started to meet some of these people in Silicon Valley, 'cause remember I lived outside- I've never actually lived in San Francisco or Silicon Valley. And I worked outside of San Francisco and Silicon Valley until Heroku. And then I started to meet a lot of these very famous either founders or investors or operators. And I'm not talking about the ones I worked with, I meant everybody.

And you started to realize that, one, they're no better than you or myself at this job. And in fact, many of 'em are worse and a lot of 'em are way worse, but they had a couple of different, personality traits that I was lacking at the time. One of 'em was this over confidence in themselves, or at least this external presentation of confidence in themselves. And the other one was this, sometimes in Silicon Valley, this unabashed arrogance.

I think when I, when I internalized that for a little while, I realized that I was holding myself back more than [00:09:00] anything. And I think there's, you know, there's other narratives at play there too. There's, there's people who are, they have this unearned confidence because of the way they grew up or maybe, you know, accolades that have been given from an early age or, you know, mega rounds of funding that have been handed to them as founders.

None of those things translate to actual abilities and skills, but they're proxying that. And for whatever reason, because we're a human-based industry, we have to produce stuff, but we have to produce it via humans. That one skill alone, this unearned confidence actually translates decently well to early success. It does not translate to later success, but it actually translates to a little bit earlier success 'cause you can force a will, a certain thing, for a little while.

But then when you actually have to use skill to get things done, like get product market fit, get something to market, build an engineering team, scale all of the different, organizations or actually fix problems. None of those things will translate and then you actually have to rely on skill and then we famously see people fail.

Eiso: I think that's something, you said something really interesting, right. That the persona that people have on the outside is, is often a- a big mismatch with the persona of, of [00:10:00] who they truly are and even the moment you start interacting with them. And it's funny because for me, it was a very similar realization. After high school, I went out to, to Silicon Valley. This was somewhere around 08, right when everything started kind of coming down and, and I got to meet a lot of the people that I- I grew up admiring, and had as kind of my role models or, or, very, very quickly, it made me realize, exactly this notion of like, everyone's an imperfect human, uh- but of course they're external personas absolutely aren't so, and this brings me back to, you know, it got popularized through Peter Teal. I don't want that to shadow the, the concept in itself of us being very mimetic creatures, René Girard Mimetic Theory- we desire the desires of the, of the models that we, that we pick around us, both internal and external, the people close to us and the ones that we don't actually meet. 

And what I find interesting in, in the notion of engineering leadership is that for a very long time, we operate [00:11:00] without external models. What I mean by that is that the models that we pick, so the, the people who's, who we model towards our boss or the people that we see within our company, if, if we're so lucky to do so, quite often in many, you know, fast growing companies, you're all of a sudden head of engineering and there's no one to look up to inside the same organization. but we have very, very few external models, right? You can think of sales leaders, marketing leaders that we're modeling towards, but then engineering leaders, there's actually very few. And, and actually Jason you're, you're one of them these days now.

Jason: weird to think about by the way.

Eiso: It is weird to think about, right? Because you're also an imperfect human. but how do you think, this is, is limiting us? Or is, is it part of what's stopping people from, from overcoming of their fear to lead in others? Because honestly, the models that we have are so far and few between, and, and the few that we do have, are, are not giving us the whole picture.

Jason: It's absolutely true first of all, that, you know, we've said before on this podcast too, you go to sit in any [00:12:00] boardroom around Silicon Valley or, you know, the greater world, but Silicon Valley in particular, and you'll hear people talk about marketing and sales and, you know, finance and, in depth because that's, that tends to be what investors themselves, particularly older, more traditional investors understand really well.

And literally sometimes the head of engineering doesn't even ever enter the room, and talk about anything. It's just because most of Silicon Valley actually does not understand engineering. Traditionally speaking, you would have 95% of Silicon Valley understands everything else, but engineering and engineering is this unfortunate thing that has to exist to get the product to market and then in customer's hands. So one, I think that's definitely true. Two, I also think that engineering leaders, there, there's very few examples of people who do X, Y, Z well, and then when we do hear about it, we'll try to cargo cult those things. And we try to cargo cult them from the worst possible examples.

Google does something because of their scale. So we're gonna cargo cult what Google does, like no, you are a 10 person startup, you shouldn't do that. Or [00:13:00] you're a thousand person startup, you still can't do it. Oh, even most large Airbnbs of the world shouldn't be doing what Google is doing. And then we have the exact opposite, which is celebrity developers say something. So therefore it becomes rule. David Heinemeier Hansson says something, therefore that is now the rule. David Heinemeier runs a consulting company effectively, that's what he does. He- everything he says is through a lens of his own personal brand and this tiny little consulting company. It doesn't apply to your fast growth startup with 300 engineers who, who hit scale that, they'll never see.

We get both of those extremes. So you get the cargo cult from the culture because you think it'll make you successful. And that's actually top down pressure typically from the board or from a CEO. And then you get the celebrity endorsement ones from the celebrity engineers themselves. And that's usually internal from the engineering team saying, "this person did this or this, this, this small team that we really appreciate did this."

Eiso: I like that you're touching upon the, the celebrity developer [00:14:00] and, and often these days paid and weaponized as developer advocate, right? In, in all honesty, I think a very direct way of saying it, but it's, you know, you are a database company and you want everyone to use your database. What do you do? You look for the person with the biggest amount of Twitter followers, you offer them one hell of a compensation package to next day be saying you are the best graph database on the market, or you're the best X.

Jason: Kubernetes is a thing now. Right? We've talked about this in the past.

Eiso: Yeah. It's, it's exactly that. And, and it really is at the end of the day, if, if we look at how, how, you know these technologies and, and also practices get there, is because at the end of the day, money runs the world and people figured out very quickly that no matter if it's an influencer on Instagram for fashion, engineering doesn't operate that differently.

 It really doesn't, not at all.

 And the th- yeah. Yeah, the thing though is that I think if you ask anybody who is looking at, and I have to admit, I haven't had social media [00:15:00] outside of Twitter for, for over decade, so I'm probably making wrong analogies here, but I'm pretty sure if anybody's opening up a, you know, a profile on Instagram with someone who's holding up a bottle of water or assume or so that their branding, there's an understanding of, "hey, this person is sponsoring something, they're market- they're putting their brand behind it."

But I feel like in our field, we're not even questioning it. We're automatically assuming like, "hey, this incredible developer or this incredible person who has this like large audience is selling us the, the best thing, is selling us the thing that actually is the best to solve my needs." And I by the way, do not want to at all criticize developer advocates, because I do have an incredible role as well in bringing knowledge back to companies and to the community. But I'm, I'm just kind of trying to put a critical lens on the fact of like, are we aware of the things that we're cargo culting, often we're cargo culting because there, there's some motive behind it.

Jason: Well, I think it's, it's... So it's not about developer advocates to me. This is about that we don't tend to start with the end in mind. Half the [00:16:00] time we don't ask the right questions. We don't, we're, we're sitting there looking for solutions to problems, problems that we think we have as opposed to problems that we've deeply researched that we have. 

Let's go back to a different topic. What should every engineering organization, what should every company do when they're five people? You know well they should be using Ruby or Python or some other, you know, decently batteries included language, running on Heroku or the equivalent, stored in GitHub and deployed that way, like literally full stop, unless you're an- infrastructure company, but we don't do that because we start to analyze which programming language should I use. What's the fastest one? Let's go to hacker news and get involved in all these threads. Let's go, let's go look at the performance charts for various frameworks and languages to see which ones are, have most throughput, blah, blah, blah. Let's start analyzing every single step of the way. That gets us away from the customer and it gets away from the problems we're trying to solve. It . Gets blah, blah, blah. [00:17:00] We do that all the time.

We- we forget what problems we're trying to solve and we start to look for interesting engineering solutions. And so I don't think it's about developer advocates, but I think what happens is developer advocates or, or people who are trying to get their awareness out there, of their products do a really good job of framing it as an intellectual exercise, as opposed to a chilling motion. And on, I think on Instagram, it's more obvious you're hold- you know, Kim Kardashian or somebody equivalent is holding up a bottle. And there's a little note at the bottom saying, this is a paid endorsement.

We don't question somebody from Google, you know, comparing five different things and saying, this is how you use, whatever their kub- I, you know, blah, blah, blah spanners and blah, blah, the world. And we- we forget that, you know, and then we trust them because we see them pop up on our feed a lot or, you get it. It's, it's just a slightly different way of doing it, right?

Eiso: But I think you say something because, you know, to go away from the rant to something, you know, very actionable, I think you say something really important is we ourselves are judging things on the wrong [00:18:00] criteria. And throughput and performance is, is, is a very obvious one. When we're a small company, we- we start looking for the database that can handle, you know, 2 million transactions, the second versus, you know, are we ever going to remotely get anywhere close to that?

We as well in our industry are time and time again, not, not willing to put the asterisk that says, this is not for you, but this is if you meet all of these criteria, right? We say, this is the best performance, this is how we, you know, ScyllaDB goes against, Elasticsearch or anything against [inaudible 00:19:41]. But we're, we're not actually out there telling people like, "Hey, this should matter when you're trying to solve X, Y, and Z." at this stage, at this scale. And to be honest, it's technical, it's leadership advice. I mean, I- I like to think we try to do a semi-decent job on this podcast of telling people like, follow this advice, if you're this size, but completely ignore it if you're larger.

Jason: So I think the problem here is that there's never one size fits all advice, and there's always a time for the exception. [00:19:00] And so everyone always focuses and says, "Well, I am indeed now in need of that exception." And my favorite example here is, I always joked, I said at every company I've ever been at, at some point, an engineer will come to me and say, "Can't solve this. This is difficult. I need to write my own database." And I, 100% of the time say, "No, we're not gonna write our own database. Databases are notoriously difficult. You get 80% of the way and it's very simple. But the last 20% is just mind boggling, hard to get done, etc, etc."

But the counter examples to writing your own database are, are actually frequent. You know, LinkedIn did it, Google did it, Amazon. You know, you start to go down the list of, of people who did it, and even smaller companies than them have done it with, with success. But the problem is everyone thinks their the exception. And in reality is you could actually, y- you're very unlikely to be the exception. And if you are, it's so obvious, you've hit a certain scale, you've hit it a certain size. You know, again like Shopify up to a certain point was only running exclusively on Heroku. And if you think about that, who, [00:20:00] who out there listening to this podcast should not be doing what Shopify did in that regard, but somehow they think they're the very exception still.

And Shopify now is famous for really investing with Stripe and GitHub at one point, investing in Ruby. Well, GitHub was actually too small to be doing that, to be honest with you, too much... And, and Stripe is now large enough, and Shopify is large enough to be investing in, in the core language itself and to be doing that. But now I'm telling you these categor- are you bigger than GitHub? Are you bigger than Shopify? Are you, are you in the same ballpark for them? And even then it should be the exception, not the rule that you're gonna go reinvent all this stuff.

Eiso: So how does a good leader deal with that conversation? Because this is a very common conversation from the moment you are in any decision making power, no matter if it's as a team lead all the way up to a VP of engineering at any size, you're going to encounter the, the brilliant engineer who's coming up, who's come up [00:21:00] often with a brilliant solution, that is the exception. And you are not always self, even at the same experience level as technically so as a leader to be able to, to hold your own, how should you be handling that conversation?

Jason: So it's not about the problem that they're solving. It's about every other person who has to ever touch that code in my opinion. So it- the- the overhead for a company when somebody introduces brand new homegrown tech is high. And it's- I- I don't think that we've ever fully gone and addressed the cost inside a lot of these organizations and see what the total ramification is. But if you write your own language or DSL or blah, blah, blah, and then all of a sudden you have to maintain it, going forward it's gotta have backward and future compatibility. You've gotta train people internally. You've gotta support it on call, all that sort of stuff. Vulnerability management, all, all the life cycle management, that's what actually where the conversation happens.

So when someone comes to me and says," I can solve this problem by writing in a [00:22:00] database," that's literally step one. And then step two through nine are about maintaining it, supporting it, upgrading it, training people. And their plan always is step one. And I try to show them that you don't actually have a plan that is actionable nor backable by myself until you get, you know, two through n- t- 10 all the way, thought out as well.

Eiso: So for everybody listening, that's good advice. Ask for step one to ten first.

Jason: And, and it's not that I want people to have it, like this is not waterfall, you don't have to go and like fully bake it out. But if you have not shown me that you've thought this through and understand, this is where it comes into it. It's not like a plan. It's that you've planned it out and you've thought about this and you understand the ramifications. And I can trust that you understand the trade-offs, because you're not asking me to let you spend six months or even two people, three people spend six months writing a database or a new language or a new framework.

You're asking me to invest probably tens of millions of dollars over the course of a couple of [00:23:00] years and dozens upon dozens of people to maintain and support this thing. And so you have to understand those trade-offs and that's effectively, you know, at the end of the day, what they say about executives, is that they're doing resource management or allocation management. That's what I'm trying to do and understand that, and if you've not actually shown that you've understood that it's almost an automatic, no.

Eiso: You've mentioned you've come across exceptions that should been say yes to, how did that conversation go? Did that, did they come to you with step one to 10? Or was it go back to get step to one to 10, figure it out and, and you had to change your mind?

Jason: So there's a couple of instances where, you definitely, your first reaction is, "oh, no, no, no, no." And you're, you're, you know, you've gotta hold it in, you wanna listen, you wanna sh- you- you ask the probing questions. And I remember one of the very good answers from a very senior person said, "Here's what I would like to do. I have a whole bunch of knowns and a whole bunch of unknowns and I wanna take this amount of time to go prove the knowns, [00:24:00] yes and uncover the unknowns. From that point forward. I want to go answer X, Y, and Z question, understanding that I need to take this into consideration." Literally the best answer you could possibly give for not having a fully baked up plan in that scenario. That person was already a highly trusted person, so there's a little bit of, background and context and history with that person.

But of course I said, "Absolutely, and you can have another person or two to go do this in that timeframe." And what that person did to continue to engender that trust was to send me updates and to, to prove this out and show what the, the progress was being made. But it wasn't coming in overly confident, this will solve our problem and it's, I can get it done in a super straightforward. Remember, I always talk about confidence versus confidence before... I myself, if somebody comes in overly confident in that regard, I immediately think that they're hiding something or they don't fully understand the ramifications or they're being naïve.

Because, you know, when you do engineering long enough, things break, timelines continue to [00:25:00] push out. So you wanna, you want to, you know, press them on that. And when this person came in the exact way, you want a senior engineering person to come in talking to another senior engineering person, and that's how they laid it out.

Eiso: So I wanna segment this into a topic that actually I'm quite surprised we've never even really touched upon al- all these episodes in, which is that capacity estimation. And let me start by throwing you the question yeah, probably a reason we haven't touched it all this, all this way. And, let me throw it from, if you think back about the best person who reported to you or, or reported someone who reported to you who was really, really strong at that kind of capacity estimation and, and planning, what were they doing that other people weren't? 

Jason: So I think there's two different types of capacity planning we should, we should talk about too. One is project capacity planning, you know, what you can get done and what timeframe with X amount of people. And the other one is more infra level type of capacity planning. You know, I think the info level [00:26:00] one is a little bit more straightforward. It's still not obvious, that you have to take things into consideration. And I think the, the, the several people that I can recall that did these best all came from the infra side of the world. And the reason why I think that they were good at the people and the project side of it was because one, it was hooked to infra. So it was a little bit better, but also they had practice because they had to do infra capacity planning.

And again, early startups don't actually do capacity planning. They just basically say, "You do this, I do this. We'll figure out when it's done and we'll ship it." And, you know, if you grow up that way, you, you just never have to build muscle in that regard. But once you start doing databases and infra and discs and you know, all that sort of stuff, you get better at it and you can start to learn the skill, you start understanding it.

So I think that was one thing that they had going for them. The other thing I think that they did well is they realized that time boxing was actually a superpower in capacity planning. Now, g- gimme a second to say this, because I know a lot of engineers, or leaders listening to this, don't like to be date driven. I, [00:27:00] myself was very not date driven earlier in my career. And again, I think it was a mistake in my part.

So I think dates are actually great because they're constraints and what you're actually trying to do is you're try, always trying to constrain things to understand what you can do. And capacity planning is similar, it's like if you had unbounded features, you have unbounded time effectively. So you're trying to constrain the amount of features that you're gonna get done so you can figure out time and all that, etc, etc, you get what I'm trying to say.

Well, this person naturally did that and said, "I wanna get this and this by this date, but will flex to hit the date or will flex to get it done." So they told me what, one, which one of those things that they were gonna flex on. And it wasn't... And then they started to do that across multiple, portions of the project. So they already told me that they, they understood some portions of the- the dark corners of the project. And they were gonna flex on date on one side or a feature set on the other, because they were telling me what was important.

The people who I found that did capacity planning poorly, they one, they showed [00:28:00] overexuberance, "Yeah, we can get that done." And that was because they thought that, that's what either I wanted to hear, which is never the case or the CEO, which is actually commonly the case. and so they were, you know, effectively selling. And then the other side of that would be that, if you kinda do it poorly, you haven't actually actually done the work. If you're talking about something that is like a large bucket of features or an overall project, you say, you're gonna get it done at this amount of time. It's unlikely that you actually understand the full ramifications of, you know, the aggregate set of features inside there, or maybe one or two or three of the larger, projects that are inside that overall project.

And, you know, it's super easy, unfortunately, for people who are, junior for someone like myself to test that, which is like, all right, show me the two riskiest parts of this and how you've mitigated that risk. And then, you know, they never have an answer to that in all likelihood, if they've not thought about this. And then to say, "Okay, so what is the scariest part of this project for you or what is the first thing you're gonna learn in, in the first two weeks that it's gonna give you confidence that your project plan is on, on date?" If they don't have answers to this [00:29:00] like, questions that look like that, yeah, they're, they're not, they're not gonna, that project's already off the rails.

Eiso: I appreciate it. And, and I think our listeners appreciate 'cause it's, it's very practical advice that everyone can take, into their meetings if they're not already doing. So maybe just throw a question at you Jason, how often do you see things being on time?

Jason: I think if you let natural course of speed without using dates, almost nothing would ever be on time. So I think the re- the way you make something on time is you force a date and you say, "Come hell or high water something will shift that day." And that's the only way you make it on time. Now, the full scope of what you initially planned may not be there- but that's the way you can make it. 

So this is where, again, I- I maybe going against some of the Silicon Valley grain, but I believe that you actually have to do that because again, constraining and forcing functions isn't gonna work around here. And what it does, it just forces people to make trade offs again, and including CEOs or CTOs. But I think that for the most part, it's a natural inclination to not have things be on time.

[00:30:00] My, my least favorite type of projects and you see them all the time are green, green, green, green, green, red two weeks before it's supposed to ship. And that's everybody's least favorite projects in the world, but it's actually unfortunately common. I think it's usually pretty obvious when those are about to happen too. And I- I think that if you're a senior leader listening to this podcast, start to question the green ones, don't say, "Hey, let's only focus on the yellow and red ones." Start to ask, "How do we know this is green? What is proven that we're still on track?" just because, you say it is, and you know, a lot of people don't want to hear the, me, me say this because, you know, green is sometimes a way to not get something asked about. But the, when you have a green project, you should say, "we said we were gonna do X this week and we did X this week. We said we were gonna do Y in the last two weeks and we did Y."

Now a lot of people say it's green because they haven't hit roadblocks yet or they haven't, you know, no, no engineer has said we're off track. [00:31:00] That's not the answer. The answer is that you're actually doing what you said you were doing.

Eiso: So let me throw one final question for today at you. How do you communicate upwards and sideways, into the exec room and, and to your peers, around capacity and planning because there's, you know, that in any engineering organization, yeah, there is going to be a difference between what people expect it's going to be like and what reality is that Delta is always there.

Jason: So this is where I think I've probably hit the most friction with other senior leaders in my career as an engineering leader, which is for the most part, particularly non engineering oriented leaders, want to push prioritization to engineering and I've pushed back and said it has to be a business wide decision. And the reason why is the act of prioritization is the one that most results in [00:32:00] understanding what is about to happen.

So, you know, a couple of times to walk through, you know, more, specific is "we need to do X, we need to do Y and we need to do Z. You know, we also need to sell this. Our numbers need to go up, blah, blah, blah." That's the CEO saying it, sales gets on board, they start doing all that sort of stuff. Product says, "here's the roadmap," all that sort of stuff. And the roadmap is many pages long, or it looks like this. And I asked a simple question, I said, "one through 10 name the projects on this list that are the most important in what order." and immediately it's like record scratch. And they're like, "Well, that's your job?" I'm like, "No, no, no, no, no, no, no, no. My job is to get those done in the priority order and understand how to like allocate the people in the projects and, and all that stuff to this." that is an actual disconnect I think at times. 

The best run organizations, I've seen understand that you're setting the priority at the company level and the fractured ones, the ones that have disjoint communications and disjoint trust mechanics or the [00:33:00] ones that say, "no, engineering's gonna set the priority." Because everyone can second guess the priorities then too, sales will come in and say, "Well, that's not nearly as important for me," but marketing thinks it's number one or product thinks it's number one. Well, sales doesn't. And then there's this very big disconnect, that's why I think it's important that the company sets it.

So, you know, the- the best run I've ever seen personally is, is in fact that time at GitHub, when we didn't have a CEO and the, one of the founding CEOs was absent from the business and it was pre-acquisition, I ran product, I ran engineering, I ran design, I ran infra, I a ran data, all that sort of stuff, but also I was making all the prioritization decisions.

So I was effectively making all of those for the entire company. Sales was on board, finance was on board, marketing was on board, that was when we were executing the best. And we had the same thing at Heroku because the, there was a triumphant of, Adam Gross, Mike Powell and myself who were running sales. And Adam was a CEO and I was running, product and eng. and, we were effectively making all those prioritizations, at, in a room that looked like that and then coming out and we're all executing on it.[00:34:00] 

But when engineering was making those prioritizations on their own, post acquisition at Microsoft, as an example, then all the second guessing can start. And I had to do all this weird triage, which is like, well, sales is saying this now, and marketing's saying this. And everyone's like, "Well, go figure it out." I'm like, literally deadlocked, you can't like, if, because if I start to do this, then what's gonna happen is I have to start making all of the, the most important business decisions.

And this is why I think like many CEOs where they get it wrong is if you effectively leave that for me to make, I am the CEO, you are a figurehead and you have... Your only authority you have at this point is to fire me. And if you really, really understand what you're doing, the CEOs will take the prioritization back.

Eiso: I think that's a fantastic place today, to leave today's episode. It's, as an engineering leader, you need to be working in a team of your peers and you better, and hopefully have a CEO who can make those final prioritization decisions. Second, best of that, you make 'em as a [00:35:00] team, but if you're the only one making them, you are effectively the CEO, for good and for bad.

Jason: That's right. That's exactly right.

Eiso: Fantastic. So everyone, thank you so much for listening to today's episode, Jason and I are always looking for topics, that might be of interest to you for us to discuss, either the two of us or with guests. So please definitely do reach out to us. You can find us on Twitter, and, do, definitely send us a message there with any ideas that you might have. And, if you've enjoyed this episode, we'd love it if you shared it with another engineering leader, you think could benefit from it.[00:36:00]