Show Notes
This is the second in a multi-part series that will explore the various stages of scaling a company using a hypothetical startup scenario inspired by ride-sharing services.
Andy and Mon-Chaio continue the discussion on scaling engineering teams, focusing on the transition from a small, scrappy startup to preparing for a Series-A funding round. They examine how to prioritize KPIs, organize teams for efficiency, and manage the growing complexities of a successful product. Along the way, they explore the balance between maintaining a small, nimble team and scaling up responsibly. Listeners will learn strategies for effective team formation, leadership, and how to navigate the challenges of expansion without sacrificing agility.
References
- Episode: Scaling Up: From Garage to Global (Part 1 of 5) – https://thettlpodcast.com/2024/11/19/s2e46-scaling-up-from-garage-to-global-part-1-of-5/
- Episode: The Why and How of Delegation – https://open.spotify.com/episode/7pVt7h9Bma046j3VhmXPo0
Transcript
Mon-Chaio: Hello, TTL listeners. Today, we’re going to be talking about part two of the scenario that we started last episode. For those of you that are newly joining and haven’t listened to the last episode, we are doing a five part series at the end of the year to talk about how to scale an engineering team.
Starting from three people in their garage and moving all the way through having a team that is perhaps global, multinational. With maybe, Andy, thousands of employees.
Andy: Mm hmm.
Mon-Chaio: And we’re talking through this scenario using a hypothetical team or hypothetical company modeled after a real company that is Uber.
Um,
Andy: was gonna say, no, no one’s gonna be able to guess who we’re modeling this on.
Mon-Chaio: exactly, exactly. And so where we ended last week’s episode is we had a small scrappy group of three people in a garage. I think at the end it was four. And they had done a good job of doing experiments. A lot of manual experiments. A lot of paper architecture diagrams. A lot of customer interviews.
And then a lot of building. Scrappy point in time solutions that may not be anywhere near their final solution. For example, we talked about building a webpage just for concerts, where people could book a driver to take them to specific parts of a large concert venue. And using that, they have proved, or they have high confidence that there is demand in an application to move people from one place to another through a car service, like a taxi. And so at the end of our last episode, they were a four person team starting to run a scrum, because what we had said is now that they have some confidence, some pretty high confidence, they can actually start putting out a little bit of a roadmap, maybe three weeks or a month in advance type of roadmap.
And then they can be able to execute it. They’re now in this execution mode, where they’re starting to execute. There’s still these commandos that are still trying to lay the groundwork, but the groundwork is starting to be laid and people are starting to come in to be able to shore it up a little bit.
And so where we’re going to jump in today is we’re going to jump into this team, again this hypothetical team, approximately six months or a year later. So they haven’t really grown by much. They’re still about five to ten engineers, and their process really hasn’t changed much. They’re still running these scrum processes.
They still have these roadmaps. Perhaps the roadmaps are slightly longer, maybe they’re on the order of a month or a month and a half now, but not too much longer. They’re still very much worried about execution. But now after about a year a lot of the commando work has been done and so a lot now they’ve done a lot of work kind of starting to shore up those little pieces that the commandos have put in place.
Um, they’re not perfect solutions by any means, but they have to because in our hypothetical scenario, this team has become very successful or this product has become very successful. This product is now used in almost all of the top 50 cities in the U. S. With quite a bit of usage. So they found a footing and people are paying them for this usage.
And so they found money,
Andy: Nice.
Mon-Chaio: Which is great, but like all companies, once you get to this stage, you run into a bunch of scaling issues. And so this group drawing on what we know from Uber is hypothetically starting to run into scaling issues. So some examples of this, um, they’re currently using a FIFO dispatch algorithm.
So. They have drivers waiting in a queue and they have riders or passengers waiting in a queue and they take the passenger that’s been waiting the longest and they match it to the driver that’s been waiting the longest and they match them up. But at scale this is becoming pretty problematic especially in large cities.
Sometimes drivers have to drive 45 minutes to meet that passenger just to pick them up and take them three minutes down the road.
Andy: Geometry, geometry strikes.
Mon-Chaio: Exactly. Another scaling issue they’re running into is when there’s a surge in demand, like the Taylor Swift concert gets out in one of their big cities, their service sucks. Um, it’s slow. They can’t find drivers to take their passengers anywhere. Their passengers don’t know where to go because the mapping technology isn’t quite right.
So, um, you know, and then their drivers hardly make any money because they’re waiting for so long just to pick up a passenger to take them one place. And they don’t feel like they’re making any money. So unexpected demand, or when a thunderstorm happens and everyone wants to get in and out of the rain, they’re finding their dispatch algorithms aren’t really working.
Their matching algorithms aren’t really working.
And there’s three or four competitors springing up. How are you going to stay competitive? How can you, you’re larger now, but how do you scale and remain nimble at the same time? And then the last scaling issue perhaps you’re running into is you’re seeing some safety issues cropping up.
Um, you’re seeing some people get into accidents and then when you look into them, they’re actually not the people that signed up to drive for you. One of the driver’s brothers actually has a DUI and can’t drive, but he wanted to make some money so he borrowed his brother’s account to pick up people to drive and then he got in another accident.
That’s not great. A newspaper article in a small newspaper was written up about it and you’re like, ooh, I need to get ahead of this. So. These are some of the scaling issues you’re running into. And I think Andy, part of this means you probably need more engineers because you can’t tackle with a five to person, 10 person team, all of these issues, but maybe you don’t.
Maybe what we’re saying is no, no, no. Stay small and let the competitors kind of eat the edges while you focus on the core. Maybe that’s it. What do we think? Mm hmm. Mm
Andy: Well, so I, I think let’s first start talking about how is the team probably working at this stage? Then we can start thinking about like, how might they change in order to address these, these issues? And some of it will be hiring, some of it might be working a little differently, is what I’m thinking. So if they’re five to ten engineers at this point, that’s probably working as one team.
They’re probably considering themselves a single group. They are working on it. They probably have like a single backlog. But also, what, as you said, they’re starting to act, uh, we, we were talking about they were commandos before. Now they’re starting to act a bit more like infantry. So some of the new engineers you hired are probably a bit more infantry like.
They, they have specialties and they like being in those specialties. I expect what might be happening at a team at this stage is that those specialties start kind of hiving themselves off. And they, they start operating as like, well, I’m, we’re the, the back end group that works in this area of the application.
We’re the web group. And maybe, maybe one of your most recent hires, and maybe this is what’s happened. One of their most recent hires was an iOS engineer or a mobile developer who does iOS and Android. And that person has hived themselves off to start addressing this whole issue. They’re like, I’m going to investigate and start building out a, a proof of concept and all that.
And so what you might think is one team has started to turn itself into two, three, or four different teams without you quite planning it. Mm hmm. Mm
Mon-Chaio: That’s right. I see this a lot. I absolutely see this a lot. And what we talked about last episode was focusing on a single KPI. And the KPI for this hypothetical company we said was how do you get your passengers to their location as quickly as possible through a car service like a taxi. And I imagine that even until now that’s the primary KPI that the team has been working on. And that’s why a lot of these issues have cropped up, right? There’s no KPI on drivers or safety, so you haven’t really focused on that. There’s no KPIs on surge or different dispatch algorithms. You haven’t really focused on that. You’re just trying to get your passengers where they need to go. And so, as an engineering leader, you might say, Well, why would the team splinter like that?
They’re still focused on a single KPI, aren’t they?
Andy: Well, they are and they aren’t. Because that KPI, in some ways you can almost say that they’re a victim of their own success on the KPI. They’ve, they’ve found a way and evidenced by that they’re in 50 cities and they’re starting to get all sorts of riders. They’ve found a way to get that going. And now, as the specialties start coming in, they start focusing on different things that, rationalized, are part of that KPI.
They’ve rationalized why this particular thing they should be working on.
Mon-Chaio: Mm hmm.
Andy: doesn’t mean that it’s wrong. I’m just, it’s, it’s that they’ve come up with a story and we’re often talking about you need a story of how this contributes to, to your goals and how it all fits together and they are creating those stories.
And, and so the team though, will start going through, I believe we’ve talked about this in the past, goal displacement, they’ll start saying that our goal, that KPI is covered by me rebuilding, uh, and creating an iOS app. Because, because you start grabbing what’s near you.
Mon-Chaio: Mm
Andy: because as a leader you were starting in this scrappy startup and you’re like, the way we operate is everyone chooses the right thing to do.
But as the group starts to grow, everyone choosing the right thing to do without lots of guardrails around and lots of coaching on how to do that, they will start to splinter off onto other things.
Mon-Chaio: In my mind, there’s two solutions to that and they can both work. I, and I’m really, really not saying one is better than the other. I think depending on the situation, you want to use one or the other or both. One is to simply say, look, the splintering is happening because people aren’t working closely together, right? It’s fine for you to choose, but it’s not fine maybe for you to choose and then squirrel yourself away in a corner and work on something by yourself. Or maybe it’s not fine for you to choose.
Maybe every decision has to be, you know, you’re a 10 person team. Let’s say maybe every decision has to be approved by, approved by at least six people and worked on by at least two or three or, or something like that. Right. That might be one solution. Um,
Andy: Uh, so, that, that splintering in the past, I have addressed it through either pair programming or actually what I’m doing right now, and it’s really effective, uh, is the mob programming. So, doing mob programming, asking people to actually work together. It starts to break down the silos that form through that splintering.
What I was working with on a team actually is about 10 engineers, was that they were splintering into those specialties, and that caused all sorts of, of process problems that caused all sorts of knowledge silo problems. And it caused all sorts of issues where they were trying to fix various things that weren’t necessarily what we were trying to do at that time. But the mob programming brought them all back together and actually got people much more focused on what are we working on right now? and the other key part of that is they’re also, they’re also participants in the decision about what is the list of priorities? Because you’re also at this point at a stage where if you’re not careful the product group can take an overpowering role in in deciding what to work on. And so you, you need the engineering team also to have a voice in what to work on, but not an overpowering voice. That’s also when you get into trouble. It’s, it’s a negotiation and have having the team involved in that negotiation, I find also helps quite a bit. It’s not just the tech lead. Who’s like, we’re doing this.
Mon-Chaio: And then, yeah, and then pushing it down and say, I had a conversation and now we’re doing this. So definitely the pair programming or mob programming, that’s one of getting people back together because you talked about splintering causing problems. I don’t think we have the time in this episode to talk about all the types of problems that splintering can cause.
But another way to solve it instead of getting people to work more closely together is to start to split people off.
And to say look there are different concerns. Perhaps there’s a different concern around safety that requires a group to really focus on that not focus on this core kpi of getting passengers as fast as possible. Maybe these two kpis are in conflict even Um, and so you need another group to really focus on that as their primary in either case I think Andy this starts to get into no matter whether your group is getting together to work, and then especially a mob which has to work on one thing at a time, they need to know what to work on.
Or you’re splintering into different groups. Those groups need to be formed based on priority because you could say I’m going to put a safety group together and if your CEO is like, well, I don’t care about safety that much right now. I mean, I do care. But right now what we need to do is there’s a competitor that’s really eating our lunch in the concert scene.
That’s where we need to spend our focus. So
Andy: The, the, the safety, the safety is a big risk, but six months of not addressing this will cause us to disappear.
Mon-Chaio: right. And so you need somebody to bring these priorities together. Now we have this relationship with product management, that we need to address. Yes.
Andy: Yes. Yes. So, this is the point at which, yeah, you need to start having this relationship with product management, because the dirty little secret of product management most of those decisions determine your architecture, because most of those decisions determine the team structure that you’re going to need to execute on it.
And that’s your architecture by Conway’s Law.
Mon-Chaio: Yes.
Andy: So you need to operate with the product management group to start understanding what are the current problems, what are KPIs for that, which of those kind of connect together, and which of them are very separate. As you mentioned Mon Chaio, it might be that there’s this, uh, this primary KPI, but then there’s a secondary problem that actually is in conflict with it.
And if you tried to mix those together into one team, you might end up with a group that is kind of schizophrenic in nature. They, they don’t really kind of know what it is that they’re trying to achieve because they’re trying to achieve two opposing, uh, aims. Now, however, you might also decide that you want that, uh, conflict on the team so that they encounter it and they work with it.
But this all comes down to what are the underlying problems and, uh, issues you’re trying to resolve? And then also what’s the architecture that you’re trying to come up with?
Mon-Chaio: And this is tricky, right? Because just as we would not advocate that your architecture change all the time, that your architecture change every three months or every six months. Because architecture is tied to team, if you’re starting to think about splintering off and building teams, you do need to put some longer term thought into this.
So the CEO might come in and say, look, they’re eating us for lunch at this concert thing. If we don’t solve this, we’re not going to be alive in six months. That doesn’t mean that automatically you’re like, okay. Concert team comes into existence who focuses only on a concert KPI, because the problem is they will build architecture that will be really difficult to untangle.
Now that may not be the wrong decision, but it needs to be made deliberately with an eye towards the future to say, look, we know we’re making a a commando decision here perhaps where it’s going to cost us a ton to fix up but it’s worth it because it’s life or death but often it’s a little more nuanced than that and it’s like look if we just think a little bit more we can make a commando like decision that’s not so bad to clean up in the future.
Andy: Part of it is finding those structures that let you work better with the people you have. Because if your competitor is finding, is spending all of their time hiring and hiring and hiring, and they are doing this, well, if you can stay smaller than they are, but higher productivity, you’ll do better. Because you don’t have as much expense going out. You don’t have as much coordination to do. And if that means that you spend three months training someone rather than three months trying to hire another person, I, I, I, I’m not going to say it’s a black and white decision. But I’m going to say there, there are things to consider.
Mon-Chaio: I 100 percent agree. And I think this is where I’ve seen junior leaders make this mistake. I’ve seen very senior leaders make this mistake. And sometimes I think that maybe they’re going into what I call abdication of leadership responsibility. But I always try to bring myself back and say, no, I’m going to look at it in the best light.
Perhaps they’ve thought about it in a different way. But hiring is the easy thing to do because it doesn’t require leadership thought,
Andy: Yeah.
Mon-Chaio: Is simply say well just bring on 10 more people now I can spend my brain cycles thinking about other things But actually thinking about what are the structures that are preventing me from being more effective With am I putting people in the right place?
Have I structured the org so that the kpis align so that they naturally the strategy and kpis i’ve created have naturally allowed my team to outperform and they are more than the sum of their parts? Versus saying, well, whatever I put in place, it’s just up to the people to execute. And if they’re not executing it, that must be their skill.
So I must hire and fire, I think is a thing that I don’t think leaders weigh enough.
Andy: I, I’m going to actually bring up one thing here, which is the, if the solution to your problems is hiring. I, I think that can be, that can be true. But most of the time when I’ve seen it, it’s a, a, a not completely analyzed problem.
Mon-Chaio: Yes.
Andy: That, I, I’ve seen teams where they, they grow to 60 people in the technology department, and they’ve got almost no revenue.
Because the solution to the problem was always hiring. It’s like, oh, we have this issue, Product is asking to build this thing. Let’s just hire five more people. And you get to a point where if you, if you approach it that way, that it seems like the only solution to anything is to hire more people because basically you’re, you’re not in, you’re not going through the difficult decisions of which of these things is more important. Because that’s really what all of this comes down to is focus on the things that are important. Put your efforts into that, and only once you’ve got all of the stuff that’s really important completely covered, can you think about the thing that’s next down your importance list.
Mon-Chaio: I think the other way around is kind of brash and egotistical. Because what you’re saying is, sometimes what you’re saying is I have so much belief in my idea that I don’t even have to be revenue positive for a long time because I believe in it and so will investors and so investors will cover my losses.
I just have to get as many people on board to do as many things as possible to create as big a product as possible, which will gain more customers, as many customers as possible.
Andy: I think right there we’ve gotten to the readiness for your series A round, which Mon Chao you and I have a bit of experience looking into.
Mon-Chaio: Yes, all I’ll say on that previous point, Andy, is that we hear a lot about the success stories of that working out. Our hypothetical scenario is based on Uber. I think Uber is a success story of, well, they didn’t really grow that much I don’t believe at the beginning anyway, but, um, you, we hear a lot about the success stories of people hiring their way to success, right?
They, they hire a team and more teams and more teams, and because their product was good and really did fit the market, investors invested in them, and eventually they become successful. What you don’t hear as much about is the people that try that and fail. And I think, Andy, we see a lot more of that in our due diligence investigations. And so, um, I think the, uh, what do they call it? The confirmation bias of success. Is that, uh, or is there a survivorship bias?
Andy: There’s the survivorship bias. Yeah, it would be the survivorship bias in this case, from what you’re talking about. Yeah.
Mon-Chaio: And so I think a lot of startups look to that survivorship bias and say, how, well, how can it not look all these successful companies? That’s the way that they did it without understanding that perhaps there’s a better way to do it. And a lot of people fail doing that. So, um, yes. So preparing for your series a, so how do we want to start talking about this?
Andy: I, I think I brought it up now because I think it actually follows fairly cleanly from what we’ve just talked about, which is having that clarity of purpose, having that purposeful separation or purposeful structure of your teams, having that plan for what does growth look like for you, having an architectural idea, even if you haven’t executed on all of it. The, the reason I kind of brought up the Series A round at this point was because I think in a lot of cases when I’ve gone in to do, uh, due diligence, People hear the, the, the name technical due diligence and they think that we’re going to spend all of our time looking at their code
Mon-Chaio: Oh, yes.
Andy: and that we’re going to, we’re going to have this like in depth understanding of their architecture and all of these things. And the, the, the fact of the matter is we look at that. We make sure it’s there. We make sure that you’re building it in a, in a meaningful way. But we also understand that you are, hopefully, coming from kind of like you’ve just gone through this whole commando stage where things were thrown at the wall and you you had all these ideas and you you tried out this and you tried out that and you’ve now probably just spent A year, maybe, in the infantry stage, where you’re trying to now bed that in and keep that down. That’s actually more of what I’m looking for than, like, that your code is completely clean. Is there evidence that that’s really going on, that you are starting to bed this in, that you have a structure, that it’s not just, like, things thrown at the wall to see what sticks? But then the other major thing that we actually look at is, is there a team?
Are they actually a team? Does the management have a way of operating this team? Do you work with product management? Do people know what they’re trying to do? It’s not that there’s a road map with all sorts of details. It’s that they have some idea of what they’re working towards. So these conversations we’re talking about of like, uh, product team has actually priorities, and they, they have this clear idea of these are the issues we need to solve, and technology is working with them on those, and there’s, there’s this back and forth, and, and everyone has a sense of why we’re here, what we’re working on, and why we’re doing that.
That’s actually more of what I look for. And so to me, being ready for Series A, you’re about to get a huge injection of cash, or a big shot of sugar into the system. And if you don’t know what you’re doing, everything’s going to fall apart. Mm hmm. Mm
Mon-Chaio: We talk about our due diligence because we work a lot with investors who are trying to see if these companies are ready for their money, for their Series A, right? And what these investors ask is that question, are they ready to scale? If they get this money, are they ready to scale? And Andy, you talked about the tech, you talked about the relationships with product management.
The one thing I think that I want to put a little more focus on is just like you talked about how there were commandos laying, and you want to see evidence that infantry are bedding in these areas that the commandos have staked out. We want to see evidence of that from an organizational perspective too.
We want to see, look your teams aren’t going to be perfect, but have you actually put thought into who leads who and why, and how big are your teams and why, and what does that mean for the future of you beginning to scale? I mean, how many times have we written, this team makes no sense. It’s not going to make sense in the future.
Why is this a team?
Andy: hmm.
Mon-Chaio: Why is there two managers on this team? Why are there no managers on this team? There’s so many times when that’s kind of been the concerns that we’ve written into our reports.
Andy: Yeah. Yeah. Very common. Uh, the concerns I have are there is no, it usually gets framed as, um, management structure. What it really means is there’s no leadership structure. There’s, there’s really just a CTO. The danger is often the CTO started as just, uh, one of their first developers. Sometimes that’s not true.
Sometimes they’ve brought in someone who’s more of like a head of engineering or a CTO. Uh, but quite often what we find is that there’s just a group of developers kind of wandering around in the fields, grazing on the grass. the CTO is trying to figure out what they’re working on and trying to get them all moving in the same direction.
And basically that’s the indication of a team that they’re missing the leadership that they need To actually execute when they get the money. Cause the thing is, the Series A round is not about you trying to find an idea. It’s, you found an idea, now go.
Mon-Chaio: I think we’ve seen a lot of CTOs that know they’re going into the Series A round and want to stop developers from grazing on the grass, in your example, or in your terminology, in your metaphor. And so they put these draconian processes in place that make no sense.
Where now everything has to be a JIRA ticket, or they have these release processes, which you look at and you say, uh, why do you need all of this process around release? And why are these procedures in place? Um, when, and why aren’t those procedures in
place? yeah,
Andy: listening, this is the point where we would want to see you start automating, start automating. Like. And not, not so much. Like I, I’ve seen teams that they’ve spent so much time automating the spin up of ethereal environments so that they can do testing, but they have no automated tests.
Mon-Chaio: right.
Andy: The automated tests are what we look for.
Mon-Chaio: Oh, I just did a due diligence on this last month where they had all these different environments and they had a specific environment for every customer. Uh, and so, because they had a specific build for every customer and they said, well, we have these containers that we can deploy to all these environments and whatnot, and they did manual testing with no automated tests.
So the question I asked them was, how do you know they’re working on every single environment? Because now, you know, you’re, you’re about to scale, right? These people want to come in to give you money, to allow you to scale. Now you’re going to have 40, 50, 80 thousands of customers. What are you going to do with manual tests, no automated tests and individual environments?
Well, we have these environments that allow us to deliver to customers. All right. Anyway, um, slight tangent. Okay. So here’s our hypothetical company. They are ready to scale. They are ready for their Series A round. They found their product market fit. They have all of these scaling issues. need to be able to figure out, I mean, they might not be able to address them right now, but they need to start addressing them right now so that when the investor comes in and says, are you ready?
They’re saying yes, this is how we’re addressing it. So how should this team, you’re the leader of this team, so what do you do with this team? How do you go about this?
Andy: So the first thing, so the way I would think about this is, I, so, I would probably, I’m a very collaborative person most of the time, I would probably actually get the team together and get the product group together and say, let’s start mapping out what our issues are. What are the things that we need to be working on and what might a future look like that would address this?
And this might be like a two day, three day conference. And I’d probably actually want to do that on a regular basis, but let’s just say we’re starting here. There’s some, some, they, they listened to our podcast and they said, Hey, maybe we should do something like this.
Mon-Chaio: Sure.
Andy: Or I listened to our podcast. And so I would, I
would go through that.
And then what I’d start looking for is if we’re looking at this, like there’s about 10 engineers and we maybe we’re thinking we’re going to start growing because we know we need to resolve some of these issues. I would first ask the question of assuming we didn’t grow our team at all, how would we approach these issues? And then I’d ask the next question, which is assuming we could grow our team by 50%, how would we address these issues? I’d start kind of thinking through some hypotheticals. Because one is, where we are right now, what could we do with what we have right now? And the next one is, what could we do if we could get a few more, uh, a bit more help?
And at that point, then it’s basically, let them self organize. After having had all these discussions, let them start self organizing into what do the groups look like? What, what, how do we want to structure this? Now, I’d want to think about it in terms of a few criteria. I’d want to think about it in terms of, alright, does each of the teams that ends up forming out of this have an absolutely clear goal? Is that goal, uh, ongoing, or is it short term project? Is it like, you solve the problem, and then you’re done, and we don’t need to exist anymore? Because those are different kinds of teams, and they offer a different way of the department operating. Then, what is the measure of success? This is the KPIs.
Like, is it, are there specific KPIs that we’re working on? That kind of thing. And then And then, do we have all of the skills necessary to do that work with who we’ve got right now? And that really starts answering the question of that, that kind of like, if we had more people, that really starts answering the question of, should we get more people?
Should we find those new skills? Because at this point, what I’ve got, what I’ve got now is not necessarily exactly what we’re going to do, but I’ve got a whole bunch of thinking about how can we use what we’ve got right now, and how can we grow for, uh, the next few months if we needed to, if we could. And, and just that thinking right there, going back to the due diligence, if someone presented me with the outputs of something like that, I would be ecstatic, because I could tell that they’ve actually thought about this, that they’ve got as much information as possible, given, uh, everything known in the company.
Like, that would be amazing to find if someone told me, Yeah, that’s how we came up with what we’re doing. Mm
Mon-Chaio: like a lot of what you said. I think my guidance would differ just slightly around the edges and maybe in terms of order.
Andy: hmm.
Mon-Chaio: I also am a big believer in sort of the leader having a, uh, a coherent strategy. And so I think that’s something which I, I’ll also talk about, but I like what you said first, which is you gather everyone together. Um, and unfortunately this is the only time that you’re doing it or, or it’s the first time or what I, but you’re gathering everyone together and I think the biggest thing there is what you were talking about, which is priorities. And you mentioned. Thinking about priorities with respect to if we didn’t grow, if we grew by 50%, if we grew by 100 percent I think that’s a reasonable way to frame that discussion because then I think it really starts to get into hey if we didn’t grow Are we really just doing one percent of each of these little things?
Or are we saying no we’re going to spend 90 percent of our effort here because that’s what’s really important
Andy: Yeah.
Mon-Chaio: so I think that really starts to get into the weeds and say because when you put constraints on things you end up Chuck it like getting out the fluff right chopping off the fluff. So I like that I think from that discussion, the next discussion is really more of a leadership discussion than it is a team discussion.
I think it’s like a CEO, CTO, head of product type of discussion. And I think it really is a little bit more of that forward looking thing. And here’s where I want to do the KPIs. I don’t want to do the KPIs after organic team formation. I want to do KPIs at the beginning at the leadership level to say for this company, if we’re judging our success in three months nine months, you know, uh, 18 months 24 months what are going to be sort of the What we think are the unchanging KPIs because I think a company at this point isn’t so fluid like they were at the beginning where they don’t really know what they’re doing and they could shift on a dime especially when you’re getting series a funding.
You’re not getting series a funding to say tomorrow I’m tackling airplane dispatch or airliner dispatch, right? You know what you’re doing and so I think leadership has to have some conviction here to be able to say hey Here’s some of the KPIs that I think are gonna structure us Going out like I was saying three months nine months or whatever.
Andy: No, I like that. I think that’s a big gap in what I said, and so I’m glad you brought that up. That once you have this idea of what these things are, you need that executive strategic level discussion about it. Now that we have these ideas about what we could and couldn’t do, let’s now look at strategy.
How do we put that to use?
Mon-Chaio: Mm hmm And then from there, then I think is the team formation part and whether it’s organic or whether it’s assigned, I think you can make arguments for one or the other and probably also depends on who you’ve hired and their personalities.
Andy: Yep. Yeah.
Mon-Chaio: But I think the important thing on that, and you mentioned this as well, is to attach KPIs.
So we’ve got the high level KPIs, now we start attaching building teams off of those KPIs. And for leadership, we say, okay, these two KPIs exist together. That’s one team. And now we can name that team. And then these three KPIs exist together. And that’s a team where we can name that team, right? And then people can start to move into it.
And maybe as people move into that team, we say, actually, that team is only a team of three. That’s small. Now here’s where you start to get into hiring because hopefully as you’ve done these KPIs, you’re saying, look, this is kind of my hiring plan and here’s how many engineers we need over time. But the important thing about that team for me is that those teams start to become what we call or what I call AAA teams.
They have authority, autonomy, and accountability over their KPIs so that they can run more, if not fairly independently. From the other team. That doesn’t mean don’t collaborate. That doesn’t mean don’t talk. But what it means is that gives you, even though you split up your structure, that still gives you fluidity and flexibility and speed. Because when those teams make decisions on their KPIs, they don’t have to be like, Oh, well, now there’s a platform team that’s got to build all the platform stuff. And like, can I get on their calendar? And they have to build platforms for this other team too. And that’s more important. They’re allowed to make decisions such as, well, we’re just going to write our own platform because our goal is our KPI. And I think that is what I think is the next step in terms of scaling this organization.
Andy: And I agree. I think, I think also we should talk a little bit about, okay, so We’ve many times in the past said, well, the way you scale is don’t try to scale. And I think what we’re saying here might seem a little contradictory to it, which is we’re saying, well, now you start planning on how you’re going to start hiring all these people.
Mon-Chaio: Mm
Andy: But I think the nuance is, is that starting, is that starting your thinking on, if you, if you didn’t grow, where are your priorities actually? You could grow, if you could get a few more, what more would that actually get you? And then the strategic thinking on, is that worth it?
Mon-Chaio: Mm hmm.
Andy: Now it’s easy to uh, to, to, to set up a story and say it’s always worth it.
Of course we can. We’re gonna, we’re gonna be massive. We’re gonna be huge. We,
Mon-Chaio: Mm
Andy: um, but the worth it is, is also about, uh, that coordination that can you truly get what you need done. with, only with the larger team. Or can you find those much more, uh, much more surgical incisions that will really get you the big wins and move on from there.
Because the longer you can say small, The, the, the less overhead you’re going to have, the less of these big problems. You’re going to grow probably. If your product does pick off, pick up like Uber does, you’re going to start encountering so many issues that there’s no way that, uh, these, this number of individuals can keep all of that in their heads.
And so you’re going to have to grow because you’re going to say like, yeah, it’s just too much information to keep in your head to cover all of these different things.
Mon-Chaio: Right at the end of last episode, we said, well, how should they be working? And that’s when we talked about, well, as a CTO, what you’re responsible for here is execution.
So, you have to stand up things like sprints or whatever and have regular meetings and you’re in those scrums every day figuring out what’s going on. You’re talking with the product all the time. You’re probably making Gantt charts, hopefully not, but you’re probably making Gantt charts and that sort of stuff.
Andy: I’m making Gantt charts for my current client. It is not fun. I don’t want to be doing it.
Mon-Chaio: So now this company is a year later and what we’ve said is they have now started to move into different KPIs. So perhaps they’re getting passengers to their location as fast as possible. Perhaps that’s the new KPI that, or that’s the KPI that beds in for their new dispatch team, who only focuses on dispatch algorithms and different scenarios.
And now, whoever’s written their web thing, they’ve now changed that. Now they’re developing a React Native application. So not exactly iOS native and Android native, but you know, one native thing that they can write for both, uh, both platforms. And so they have their KPIs around maybe app responsiveness, app downloads, app ratings, that sort of a thing, perhaps.
And perhaps there’s a team focused on drivers and driver onboarding and safety, maybe. So we can think, uh, high level. Maybe those are the three teams that we’ve decided at the leadership level with their KPIs, their AAA. So you’re the CTO now. You’ve decided to do this. You have these three AAA teams. What are you doing?
Are you attending their scrums every day? Every once a week? Are you, are they creating PowerPoints every week that go up to say, what did I do last week? What did this team do this week? What’s in, you know, what’s in store? What are our challenges? What are our blockers? What, um, are you scaling up scrums? So you have these scrum of scrums and you’re attending these, like, what are you doing, Andy?
Andy: So my thinking is, uh, the, the, the major thing to think about is now that I’ve got multiple teams, I have to work on now two levels. One is I need to make sure that internal to the teams that the, the, the leads and the managers or whoever is kind of running that. That they have my faith and my trust, and so I need to understand what they’re doing, that they’re running those teams well.
And I need to make sure that those teams are talking to each other, because as much as they, like, they’re autonomous and they’re making decisions on these different things, we’re still making a product that needs to work together. So they need to talk to each other, and they need to do that on a regular basis.
So I would say that my big focus at the moment is on that. Not so much on the day to day engineering, but on the day to day communication and leadership.
Mon-Chaio: I agree with you.
.And I think that there’s a number of ways of doing that. One is to say, well, I’m going to dive in and I’m going to do spot checks and I’m going to, you know, attend your scrums and I’m going to look at every prioritization you make.
And every, every scrum is going to have to be approved by me before it gets . Actioned as the next scrum that you’re going to do or whatever the case may be. But I think, Andy, we probably both think that that’s wrong. I think we’ve talked in the past in our delegation episode about gemba walks briefing, back briefing.
And we’ve talked specifically about using KPIs to do briefing, back briefing, right? So, uh, each of these AAA teams has their KPIs. And so can you do briefing, back briefing based on those KPIs? But remember what we talked about there is also the Gemba walks are really important.
Go down to where the work is being done. So this is not have manager surface dashboards up where I read all of the stuff. It is though maybe attending one Scrum meeting a week.
Andy: Yeah.
Mon-Chaio: Right? It is maybe sitting with an engineer asking your manager, Hey, you know, one of my top priorities, as I mentioned, was I really want concert dispatch algorithms.
Where’s work happening on that this week? And then going and sitting with an engineer for two hours to watch the work happening on that or the team for two hours or whatever, right? Um, but it’s, it’s nuanced because you can’t do that for everything.
Doing this stuff around looking at the connective tissue between the teams and seeing, Oh, actually our code base has grown really bloated because these teams are starting to use, um, this auto code generation stuff. Uh, I should bring that up as a, to my leads, to my managers, to see whether this is something that they’re worried about, right?
Um, oh, I’ve noticed there’s a lot less slack communication between the groups. I wonder if this is a problem. Are they getting too insular? Things like that, I think, are the things that the CTO should worry about.
I’ll use an example for people that play, uh, what are termed German board games, but I don’t think are German anymore. I think that style has become very prevalent throughout the world. Often in those games, there are what we would call like tactical actions that you can take.
You know, take one gold and you have one gold or whatever and then there are investments that you can make So don’t take one gold but but put one point into something that allows you to eventually have a bank that gives you five gold a turn without you having to take an action. Right and one of the big things in that game is always about balancing When do you stop being tactical in order to build up your engine?
Because your engine is always for the long term going to produce more than your individual actions. Now, I think what a lot of companies do, and what a lot of leaders do say is to say, I know that that engine produces more. What I’m going to do is I’m going to work harder or put longer hours in or whatever.
So that, for example, instead of being able to do one action a turn, I get to do two actions a turn, right? And so I take two gold a turn. And then they never build up that engine. And I think that is very problematic because I think in terms of scale like it never works, right? You could take three actions or four actions a term, but the engine is always going to be what drives you long term And so yes, if it’s really and you were talking to me about this once Andy about some company you were consulting for if the company is going to die in a month Without having perfectly executed something.
Yes, the leader is going to go in and they’re going to look at every single detail, highly, highly support this. That’s what they need to do. That’s the most important thing to do because you won’t be alive. But I think there’s a lot of hyperbole about, Oh, we won’t be alive in three months or, Oh, we won’t be alive in six months if we don’t do X, Y, or Z.
And so they have to be involved in the details and they never build that engine. And so they never become and grow as fast as they possibly can.
Andy: Exactly. Yeah. Yeah. No, I agree with that completely. As much as I’m like, oh yeah, you need these study groups, you need to get people on board, you need to have them thinking in the same lines. Not if you’re about to fall apart. But it has to be truly, you’re about to fall apart. Not, we’re afraid and we’re stuck in our scrappy startup mode.
Mon-Chaio: Right. Absolutely.
Okay, I think we talked to a lot in this episode. In the next episode, we’re going to talk through this hypothetical company, Expanding due to external complexity.
So in this episode, they’ve had challenges come in because of their scaling issues. They’re trying to prepare for Series A. In the next episode, they’re going to start to figure out that Customers and regulators and all of these other things aren’t what they thought. They built these AAA teams that are pristine, but all of a sudden, there’s this work coming in that needs to be done tomorrow that doesn’t fit across a single AAA team.
And some of this work is existential. If they don’t do it, they’re going to be kicked out of markets or certain things are going to fall apart. So we’re going to talk about how we think about scaling a company. Do you take engineers and put them into a tiger team? Do you split out your AAA teams? Do you stick rigorously to your AAA team model and put all of this work in a backlog and do prioritization with this work?
What do we do? How, what does that look like? How do you go about building processes and how do you yourself participate in managing these complexities? So that’s what we’re going to talk about.
Thanks everyone for joining us in this episode. As always, we love to talk to people. We love to talk to individuals and companies, especially those that need our help. Especially those that want to have conversations around what they agreed with and what they didn’t agree with. You can reach Andy and I at hosts with at the TTL podcast.
com. That’s hosts with an S, but until next time be kind and stay curious.
Leave a Reply