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.
In this episode, Mon-Chaio and Andy pick up from where they left off in part two, exploring the transition of a company post-Series B funding, now boasting around 100 engineers. The conversation covers the importance of structuring technical teams into key functional groups, facing new challenges such as competitors introducing new features and dealing with regulatory pressures. Our hosts discuss strategies for maintaining effective leadership and organizational structure during rapid growth, while navigating internal and external challenges.
References
Transcript
Mon-Chaio: Mon-Chaio and Andy here. This will be part three of our series Scaling Up: From Garage to Global. So to catch everyone up, if you haven’t been listening, why haven’t you been listening before? Why is this the first episode? But also welcome! To catch everyone up, previously we started talking about how to scale an engineering organization starting from three people in a garage. And where we hope to get to by part five is you are now a global organization with perhaps thousands or tens of thousands of employees, maybe a little smaller than that, I don’t know.
And we’re looking at it through the lens of an engineering leader that grows through these stages and how might they change the way they think about interacting with their team and structuring their team. And, of course, there’s a lot of conversation about how do you find product market fit, all of that sort of stuff that naturally creeps into it, because I think we have to set those types of foundations before we can really talk about the engineering side.
Where we left off last time at the end of part two – our hypothetical company here exists per-Uber, we were saying this exists 10 or 15 years ago – they are building a ride sharing business. They have gotten to the point where they were just getting set, I believe, Andy, to get Series A funding.
Yes?
Andy: Yes. One of the things we talked about was what’s important in getting yourself ready for that process. What are the things that people like us, when we do our due diligences for the investors, what are the things that we’re looking for? What are the signs that you’re on the right path? And so we’re now at the point where you’ve gone through that whole process. You got the money, you started taking all the steps that you said you were going to do, and now let’s find out where this company is.
Mon-Chaio: Right. So we’re rejoining this company about a year or two later. At this point, they’ve closed their Series B round. They’re a fairly large company now, and they’re about, about maybe 75 to 100 engineers at this point. They have actually expanded even further. So this is a company that’s now the recognized leader in ride sharing in the U.S., is basically available in all major cities and minor cities in the U.S. and now has started to establish some international footholds.
The product also has improved. When we last left the company, they were very, very much focused on the passenger as their primary KPI, the satisfaction of the passenger. But as they’ve expanded and as they’ve gotten money coming in, they’ve really started to take what we talked about last time, the commando situation, and really built it back up. So now they do have an iOS and an Android app separate. Now, they have features such as share your trip. They have the ability to do pricing promotions. They have the ability to do navigation in the app instead of outsourcing that to Google Maps or Apple Maps. They have integrated payments. They have an adaptive dispatch algorithm for different situations. They have rider and driver ratings, that sort of a thing, right? So you’re seeing this thing become a very full featured product.
And as you were mentioning, Andy, this is really them moving from the explore stage to the expand stage. And maybe they’re even in the latter half of the expand stage …
Andy: Yeah.
Mon-Chaio: … moving towards extract.
Andy: Yeah, it could be that they’re in the extract phase in several of the cities that they’re in in the U.S. where they understand exactly the way it works there. They’ve set their presence. They’ve crushed the competition. And now they’re just letting it run and they’re trying to figure out like, okay, how can we get that at the highest margins possible and use those margins to expand elsewhere?
Mon-Chaio: Absolutely. And so in terms of structure, our technical organization has structured themselves into three broad pillars. So what they’ve decided is they’ve decided they have a rider group, which handles the passenger side of the business. Things like rider ratings, app responsiveness and crashes, ease of rider sign up metrics, that sort of a thing. So they’re responsible for all the features for a passenger trying to get a ride somewhere. They’ve also now, for the first time, now have a driver group. Driver signup is no longer just the janky website or Google Form, which says, do you want to drive? Here, fill in some forms. It’s a much more smooth experience, which they’ve needed since now they needed to sign up thousands and tens of thousands of drivers a day. Right? And so, KPIs for the driver group might be stuff like time to onboard a driver or driver retention metrics. How often do you drive? Do you just drive once and then quit? That sort of a thing.
They’ve also now created a platform group. We’ve talked for the last two episodes about not doing specialization, the evilness of specialization, and we’ll talk about how this platform group is specialization but it is also not. That’ll be an interesting conversation. But this platform group includes sub teams like app framework, so the shell of an iOS app, which may be used for both the driver app and the rider app, something that’s shared. Dispatch and routing, so they handle the algorithms to determine who to dispatch where, and what path to take to that location. And perhaps pricing. So, when do you set what price? Are Sundays cheaper than Thursdays? And, if it’s raining, raise the prices or whatever the case may be. So they have a group that does that. Those are the types of things that are in the platform group. There may be other things as well.
They are large. They have formalized their teams. They move more slowly because to communicate across 100 people is simply slower than communicating across three or four or ten people. And now they’re running into problems of smaller, more focused competitors coming up and launching features and eating their lunch, right? And these are features that perhaps they haven’t even thought about, so their competitors launch them, and perhaps they even said, eh, I don’t know about this. And then they saw the growth of the features and like stealing customers. And they said, no, no, no, wait, we got to do something about this. So some examples of the features, perhaps a competitor has created a shared rides feature, which allows multiple riders to share a single car for substantial discount, and this company says, hey, why didn’t we think of that? Oh my goodness. Now our ridership is down because they want cheaper rides and they can get shared rides. Perhaps another business has created a B2B focused ride sharing … or not B2B focused, but for businesses. So like a car repair shop can say, oh, you dropped off your car. Now you need a ride to work. Instead of running my own shuttle, I run it through this business. And they’re saying, hey, wait a minute. That’s a huge business. Why did we allow a startup to capture that? We want some of that money. And so they’re running into these smaller, more nimble startups, starting to eat into their lunch.
On the other side of it, they’re also really attracting regulator attention because they’re so large now. And if you all have ever worked with regulators, regulators do not care about your product roadmap. They don’t care to be interviewed. They don’t care to be shown mock ups or, hey, sit down. And here’s the beta version of what we’re thinking about releasing, and what do you think? How can we improve it? That’s not how they work, right? They go off into legislative sessions and work with lobbyist groups and a law gets passed. And sometimes you know that this law is coming. Many times you actually don’t, or it’s different than what you thought was coming. You thought the shape of it was one thing, and now it’s not. And then they give you 60 days to comply with it, or six months to comply with it. Otherwise they kick you out of the country or the city.
Andy: Mmm hmm.
Mon-Chaio: So now you have to deal with that. So an example of that may be one country requiring that all drivers are registered with a central hub or garage, and that has to be a physical location on a map. And every time a driver drops off a passenger, they need to actually return to that physical location before you can dispatch them out to another location. Or another regulation might be, they require trips to be scheduled 24 hours in advance. Any trip not scheduled 24 hours in advance is not allowed to be dispatched. And these are things that they’re saying, hey, you have 90 days to comply. Otherwise you’re gonna face fines or your operating license is going to be revoked or something like that,
So that’s this episode. How, as a CTO, are you going to manage these challenges? And how do you interact with the group of this size and how does that change from how you were interacting before. So Andy, what’s a good place to start, do you think?
Andy: Ooh, I don’t know. I mean, this is a lot, Mon-Chaio, if you think about it, from where we came from, it’s all become much more complicated. You’re not just running like, oh, I’ve got a few teams. I can know exactly what they’re doing. I can go and pair program with them every once in a while. And so you’re in a completely different world than you were before. For a company of this size, I have my experience at a couple different places about kind of the way they structured it. In many of those cases, I would say I wasn’t happy with the way they structured it. So maybe we can do a little bit better. And you, having worked in Uber, have a little bit more of a basis of where this might have gone. And so Mon-Chaio, where would you start?
Mon-Chaio: Yeah, I think, actually, I want to start with a conversation around what is the CTO doing now that’s different than what they were doing before? Because I think once we talk about that then as we go into the challenges we can talk about, is that still the right way for the CTO to behave in order to confront these new challenges?
Andy: Right. So are you think like what’s in their calendar? What are they doing every day? What kinds of things would we expect to see them looking at and thinking about and talking about?
Mon-Chaio: Right! Because if you set the challenges aside, you can almost think about this as a smooth running engine. Uh, we talked last episode andy about setting up your engine so that you get multiplicative effects, yes? And so the way that we can talk about a CTO operating at first is to talk about how would they operate with this smooth running engine, what are the types of things they can do? After we get a good sense of that, then we can talk about well, there’s stressors to this engine. Now what do they do, right?
Andy: Right. So, thinking about this, one of the things I would expect a CTO who’s got this well running engine to be doing. is on a probably weekly, maybe fortnightly basis to be emceeing a session where all of these teams get together and show off what they’ve made, what they’ve done, so demoing. The reason I say that is because one of the things that I think can start happening as your team grows is that you kind of lose track of all of the things that are coming out and the group also stops noticing that there’s all of these things going on. They kind of like don’t know everything that’s happening. And I think demos, just like we do in most of our agile ceremonies, like you demo every week making those like a big thing for the whole group, I think is important. And I think that’s one of the things that would keep this engine running is that expectation that we are still producing things on a regular basis, that it’s something that we can demo, and there’s actually, to your customer KPIs, I think that’s an excellent thing to keep in mind is that these aren’t internal kPIs. And these demos also shouldn’t be like an internal, highly techy type thing where only the people who are directly working on it have any clue about why this is valuable or what’s going on. The demos should actually be along the lines of almost the sales pitch.
Why should everyone care about this for our customers? For the drivers as our customers or for the passengers as our customers. Or, as we’re talking about here, for the regulators as our customers.
Mon-Chaio: Mmm hmm.
Andy: Why should people care about this? And one of the things I would think for a well running engine is that the developers, maybe not all of them, but at least the leads, can give that presentation, can give that level of thinking about why they’re doing this and why it’s important and how it helps people.
Mon-Chaio: Mm hmm. I like that. And I really like demos, I’m a big fan of demos. And I think, as you were mentioning, Andy, demos serve a number of different purposes. One, for example, might be that they force you to be able to release software regularly. So that’s one. Visibility between groups: as groups get larger, it’s more difficult for them to communicate, especially AAA groups. You have to watch out for that, where they can become too insular. And so I think demos, especially ones that are focused on customer KPIs instead of internal KPIs, help groups understand what’s going on. The place I want to focus on with demos, Andy, is the third thing which is helpful, is as the CTO, it’s now very difficult for you to get a sense of everything that’s happening within your engineering organization with a team of this size.
It’s simply impossible, right, your brain space can only hold so much. And so the demo is a way for them to get exposure to parts of the business and the product. Now, my question is as a CTO, you care about things like how are things going right? And then you care about things like problems, which is, what are the challenges that are preventing a team or a person from executing. So with a team of this size, is the demo the only mechanism by which a CTO gets status and hears about problems? Or what else is there?
Andy: Oh, no, it’s not the only mechanism. You’ve got the standard things, like the staff meetings, where you get together and you hear about status. I have never been happy with those.
Mon-Chaio: Agreed!
Andy: So it may be happening, but I think we should talk about it a little bit of how can this company be doing it, but a bit better? Something where it doesn’t fall into all the traps that I’ve seen in these kind of staff meetings where it’s turn taking and one person after another saying something. You’re all basically speaking to the CTO and everyone’s hiding bad news, because they don’t want the difficult questions.
Mon-Chaio: Yep.
Andy: And so those status meetings start turning into places where … I knew someone, he called it the watermelon rag. You know, red, amber, green, as a status. And, so the watermelon rag is that everything is green on the outside, but if you ask anyone on the inside, they’re like, no, it’s all terrible, it’s all red.
Mon-Chaio: I’ve never heard that, that’s good!
Andy: And so you want to avoid that. And how do you do that in a way that actually builds the organization rather than kind of hollows it out and causes these watermelon rags and all of that.
Mon-Chaio: So the first thing is I don’t think the typical staff meeting does a great job of that. I think one of the challenges is regardless of how collaborative you want these groups to be, at this size, your groups are generally going to be inward focused. And I feel like you have to lean into that. That’s where I feel like those AAA teams are so important because you have to give them authority, autonomy, and accountability to be inward focused.
But what that means also is that if you’re sitting in a platform team working on dispatch and routing algorithms, the leaders of the driver organization coming in and saying we have some trouble signing up drivers because it takes too long to process their background checks, do you really care? Even if you wanted to care, it’s difficult to really care.
Andy: Yeah.
Mon-Chaio: And so the first thing I would say is status meetings need to be one on one with the CTO and the AAA group.
Andy: Right. So a staff meeting per AAA group, the umbrella of the area, that should care about each other.
Mon-Chaio: Exactly, exactly. And it may not be every AAA team has a staff meeting with a CTO at this size because you might imagine that three teams come up and they’re one AAA team and then three AAA teams again roll up and they’re another AAA team together. And so the CTO may want to just care about like that high level.
Andy: Yeah.
Mon-Chaio: And I would say that that’s probably right, and I think the cadence of that has to end up being a lot like one-on-ones where, at your base level, um, you are meeting with those folks regularly, probably weekly, but then I would say at regular intervals, you also want to go down a layer. And how many layers you go down depends on you, but you want to go down a layer and kind of at least observe.
Now at that base level they’re reporting to you, right? So your questions are pretty pointed and you’re really digging in. At the lower levels what you’re trying to do is you’re just trying to get a sense. It’s more like a Gemba walk. You may ask some questions, but remember, at that point, you really want to work through the managers. And also, often, those level of details are details that are going to be sifted out. And so if you get too into those level of details you end up disrupting the rhythm of that group.
Andy: Are you saying get rid of that entire, like, across this group interaction or what do we do there?
Mon-Chaio: No, no, no, you absolutely have that. And so in this case, we talked about there’s broadly the rider group, the driver group, the platform group. And maybe because the platform group is so diverse, you have two or three leads of the platform group instead of just one, but maybe not. But I would say at that level you bring those folks in.
And that is not a status meeting. Importantly, importantly, it’s not a status meeting because that’s where we get into the turn taking stuff. So what do we do there? To me, there’s a lot of ways that you can run this. One of the things that they could do is run a study group. So some sort of manager self-improvement session. Now this doesn’t really get into the status-versus-problems area, this is more a growth thing, but I wanted to kind of lead off on that because I think it’s an easy thing to understand.
Andy: Actually, I think you can use it pretty well for this kind of thing. So what I was thinking was a cross-group staff meeting. I think you’d still want it focused on how can you grow and how can you help each other. And in many cases they can’t help each other. That’s the whole point of the AAA. If they’re well separated, it’s like, well, there’s not much that we can do. But maybe there is, and if it ever comes up, you want it to show up at some point.
So, I would structure a study group around a discussion of what are our current goals, what are we trying out right now, what are the obstacles in our way? And then the study group part of it is focused on, let’s come up with ideas about how to understand those obstacles, how to understand the last thing that happened and what we can learn from it. And so you use the study group as a way of expanding your philosophy and expanding your vocabulary for discussing the kinds of things that can come up.
And the thing that this brings to mind for me is the book The Art of Action. Something that was critical to the briefing/back-briefing working for the Prussian military, was that the general of the whole military had spent years working and training his generals and his subordinates to all think in a common manner. And it would have been done through war games and through study. And that’s what I’m thinking that this staff meeting would be.
Mon-Chaio: I like that. I think another important thing for the CTO to do in this cross pillar staff meeting, is not to look down, it’s to look across. And so the goal here is to find out challenges that are unique to what the CTO sees, possibly from the individual group staff meetings, possibly from Gemba walks, or maybe it’s just looking out into the marketplace and saying, wow, generative AI could be something that’s really interesting here, or whatever the case may be. But to bring that back and then to action with that group – I would probably call them things like projects – that they then work collaboratively on.
So a simple one might be, we don’t know the status of our unit tests. That might be a simple one. Because we have these three groups, they all build in different ways, one uses Jenkins, one uses GitLab Actions, and our tests are all built in different ways, we can’t actually get a good sense of how our overall product is building and what the test status is. I think that’s one where the CTO can say, okay, I’m really curious about this. How would we as a group go about solving this problem? And it really is now thinking about it as the CTO is almost a peer to each of these leads. And so as the group goes about solving this problem, the CTO has their work to do that the group assigns them. Well, can you go out and see if we can get a better license for X, or this specific engineer refuses to even do this, like, can you go to him, right? So the CTO has stuff and then everybody else says, okay, well, for my team, I think we’re good here, but like, we’re gonna have to work on this, and now they’re really working together. And that’s also in time to really build that trust and to feel like you’re in the trenches together solving the same problem. And I think that’s a really important thing for the CTO to do as well.
Andy: Yeah. I think that working across, because that uncovers much more information. It’s not so much about the execution, it’s about the responsiveness to things that are happening.
Mon-Chaio: Mmm hmm.
Andy: And I think maybe that’s the underlying theme across, what is the CTO? What is the leader doing at this point? And I think that even fits with the kind of framing that we put on it, and I don’t know if this was intentional, which is that in your leadership position at this point, you’re there to uncover information to help the group respond in an appropriate way to what needs to happen. And so it’s getting those demos to understand kind of what’s the current situation. It’s getting those staff meetings with the various AAA groups to work out what is the next thing that they’re doing and what are they learning along the way? What are the obstacles that they’re getting? And then it’s the staff meeting across the organization to uncover the cross group issues and look at the larger organizational objectives. And learn how to work together as a group to get a common philosophy, a common vocabulary, a common way of thinking.
And, when all of that starts coming together, then what you have is an organization that can function on what it needs to do right now, can pay attention to what is the current objective and the obstacles, and work towards that, because it’s a thing that they can think about. As well as when something comes out of left field, it’s not a complete mystery about how this organization can respond because it’s just another thing that comes up for them.
Mon-Chaio: I agree. And I think we’ve touched a lot on sort of this cross-pillar staff meeting portion. There are real challenges around how a CTO interacts with one individual AAA organization as well. Because with a smooth running engine, one challenge is that it is running smoothly and so you have fewer and fewer touch points and less impactful touch points. But because we don’t want this episode to run two hours, I don’teally we can dig into that now. I will just say that there is a challenge between how you allow that group to solve and surface problems versus how deeply you dig. And this might be for another episode further on down the line, or if people are interested, reach out to us, we’re happy to discuss it offline.
I think now though is a good time to say we have this engine that’s running and the CTO that’s thinking about execution and also thinking about cross group strategy and whatnot, but now there’s these stresses to the engine that are coming up, right? Let’s use for example the regulation one first. Or maybe only, I don’t know. Let’s see how this goes. A regulator in a country that you’re operating in has said you can no longer dispatch drivers unless they are located in a specific location.
Andy: Hmm.
Mon-Chaio: Because no matter where they drop people off, now they have to return to this location in order to get new dispatches. And you need to do that in, let’s say, 30 days, or they will start to revoke your license and fine you until you do that. So what do you do here? Now, I think this seems to belong to the driver group, right?
Andy: Sure seems like it, yeah. But I could say it might also connect to the platform with their dispatch and routing.
Mon-Chaio: Yeah! And it might connect a rider because now the app on the rider’s side might show cars that are driving around their neighborhood.
Andy: Oh yeah. And now those don’t matter.
Mon-Chaio: Right, now those don’t matter. So it kind of crosses all lines and it needs to be done really quickly. And there’s no AAA team that’s the AAA team for regulations or the AAA team for whichever this country is.
Andy: Mm hmm.
Mon-Chaio: So what do you do? Do you takethree engineers from each team and form a tiger team? Do you get your leads together and say, how can I get this on the roadmap immediately? What do you do, Andy?
Andy: Well, I mean, this is why I love these kinds of structures and having this kind of an engine in place. We were just talking about this objective based kind of problem solving and learning meeting across all of the pillars. I would bring it up there. Now, it might be that you have to convene a special session of it because you got 30 days, you just learned about it, your next session is maybe in two weeks. So, nope, we’re gonna have one right now. But, it’s not an unusual thing that this whole group is talking to each other and talking about, we’ve got this challenge. So, what do you do? To me, I as the CTO, I convene them into this, and I say, hey look, group, here’s our current objectives. Here’s the status, as we all know it, this is what’s going on. This new thing just came in. And this is the consequence of it. Let’s start talking about what are the obstacles to getting that done.
And we’d start getting the thing of like, oh, well, that’s across all three of these teams, and we’ve got these backlogs that we need to be working on, and we’ve got this other thing that actually needs to be done in 27 days. And out of that meeting, out of that thinking about it and thinking about the obstacles and having that common language now as a group, what I would say is what would come out of that is an answer to your question. So I have kind of like a meta answer. The answer is run the system, run the engine, because what we’re saying is you need to set up an engine that can handle these kinds of things. And in this case, this engine, you would bring it to this meeting, you’d discuss it, and you’d come up with what are the things we’re doing? And it might be that they say, you know what, let’s just get these four people together. They’ve worked across all of those things. And we’ll get them together and we’ll get from them, what to do about this. You know, like, cool, let’s try that. And then the group splits up and does it. Or it could be that they say, you know what, we’ve all got slack. We’ll just throw it in and put it as the next thing that we do. And you’re like, cool, handled.
But to me, that’s the idea. It’s the extraordinary things are handled by ordinary methods.
Mon-Chaio: I like it. And in this model, Andy, in this specific situation, would the CTO then own that emergency KPI?
Andy: Given something like what you described of like regulatory change, 30 days, I would say probably, yeah. And so you might even set up a special session of keeping on top of what’s going on, a thing out of cadence for demos and that kind of stuff.
Now, you want to be careful about that though, because if you do that too much, you tear your engine apart. now everything’s special.
Mon-Chaio: Right, and I agree with you. I think in these emergency cases, this is where – we have these conversations about wartime peacetime CEOs and whatnot. I think this is the right time for the CTO to dig in and say, okay, here, we have had this conversation, we agree it’s a small working group. Or maybe even if it’s not a small working group, it’s part of each team’s roadmap or each pillar’s roadmap, I think this is a time when it’s okay for a CTO to be like, I’m attending that part of the daily standup every day to listen to the specific work being done on this, because I now am responsible for that as an emergency KPI, I need to drive this part of the engine until it ships.
Andy: Yeah, because I know that our operations team is not going to be shutting down that city. Which means that if we continue without being shut down, we may get a little bit of grace. But we’re opening ourselves up to major fines and lawsuits and all of that, and so I’m going to stay on top of this.
Mon-Chaio: Right. And it’s okay for the CTO to say, I’m suspending some of these cross group initiatives for two or three weeks or a month, because this is the emergency thing that requires all of our attention.
Andy: Mm hmm.
Mon-Chaio: And so we’re going to suspend, we’re going to focus on this as an emergency thing. I’m going to dig into the details. I’m going to be intimately involved. But the important thing is then they got to get back out. Because to your point, if everything’s special, you rip apart your engine.
So how do we make it, in this regulatory world, not have everything be special?
Andy: Hmm. I’m not sure I have an answer in particular. I think I would have to experience the problem a few times to come up with a specific answer to it. I can give a general answer. But do you have something more concrete than what I might have?
Mon-Chaio: I think what I have is the explicit acknowledgement that these things will continue to happen.
Andy: Mm hmm. I think that would be key.
Mon-Chaio: And then to work with the group to say, since these things are going to continue to happen, how are we as a group going to address them in order to not make it special?
Andy: Yeah.
Mon-Chaio: And there’s a lot of different shapes this could take, right? One might be we are going to hire or promote somebody to be PM of emergency regulatory situations. Maybe you convene, I don’t think this is right, but maybe as a group you decide you want to convene a SWAT team of people to just sit there and work on these things. And know other people in other groups and are able to dive into the code. I generally don’t like that. What do you do with this team after it’s over? How do you know when it’s over? How do you not just give them work to give them work because you have this team?
Andy: Yep.
Mon-Chaio: So those are challenges, but that is also another possibility. But I would say that that explicit acknowledgement to say “no, this is not special, this is business as usual, so how do we build an engine for this that can accommodate this?” Is important.
Andy: Exactly. That was really what I was thinking as well, so I’m glad that you came up same thing. The thing that I would say is, I wouldn’t do it on the first case. I wouldn’t do it on the second case. I would probably wait until the third or fourth case. to start seeing what is the pattern here. Is there a pattern? Or is it special every time? And it might be a little bit special each time, but only in the details. In the broad strokes, it probably all starts looking fairly similar.
The other thing I would say is that you’re going to have to struggle with the concept of you never interrupt the interrupt. This was a saying that a friend of mine had about how you manage a team that can get interrupted onto different things. And you had to work by the rule that you’ve got your normal flow of work, and then you’ve got your interrupt, like you get interrupted and you have to go do this other thing. In order to work sanely, you can’t let something interrupt the interrupt.
Mon-Chaio: Okay.
Andy: Once you have gotten into the interrupt and you’re working on that, until you’re out of it, the next thing that comes in has to wait. it’s just the world, because if you interrupt your interrupt, then that thing that you just interrupted never should have been an interrupt in the first place, if you’re saying that that’s possible.
Mon-Chaio: Interesting.
Andy: So I think that would be one of the things as well, is when you’re doing this stuff, when it starts coming in, you’d probably want to think about it as, well, we just interrupted work, and it interrupted our normal flow to handle this. Great! That was actually wonderful flexibility and wonderful reacting to the situation as it changed. But what we don’t do is then when the next one comes in, stop what we’re doing on this and start working on that. We analyze it as a separate thing and say, what’s happening here? And at that point now you’re starting to come up with, what’s the new engine? What’s the new engine that just handles these things where they’re not just interrupts all the time?
Mon-Chaio: And when we’re talking about engines, that also means that. the average case is not going to be the case all the time. And so as an example, one way you might handle something like this is you say “I want to reserve 20 percent of my engineering capacity to handle these interrupts.”
Andy: Yeah
Mon-Chaio: So that is not an excuse to say, I don’t see an interrupt coming up in the next sprint. I’m going to schedule this 20 percent and then those people will be taken off if something comes in and then you have all this sort of interrupted work that’s just sitting there, which probably shouldn’t have been worked on in the first place or whatnot, right?
Like you have to build a sustainable engine there, and that may mean that overall you’re less efficient, then you’re more effective because you’ve built this engine.
Andy: Yep, and these kinds of ideas, these kinds of thoughts, these are all things that in the normal times I would expect to be happening at that staff meeting that we were talking about, that cross-pillar staff meeting. That you’re talking about what it means to have slack in our system. How do we protect the slack? What does decision making look like when we’re talking about an extraordinary circumstance? And you do the research into that so that when these do come up, someone can say immediately, “all right, well, we don’t interrupt the interrupt.” And that phrase means something to everyone. And so right then you immediately know what you’re talking about, and everyone knows kind of how to react based on that.
Mon-Chaio: Right. That phrase has meaning, has cultural meaning that you’ve built in. And I think this is probably the way that we would handle these competitor features as well, even though the competitor features are a little bit bigger. But I would say the same standard, in my mind, holds where you’re having your group come together and say, how are we going to handle this in a sustainable way?
Because we know scrappy competitors are never going to go out of style. And so this has to be built into the engine instead of every time it comes up, it’s an emergency and the CTO can never do the cross group work of tending the engine because they always have to focus on the next emergency that’s coming up.
Andy: Yep.
Mon-Chaio: And I think importantly, in my mind at least, is you’ve built a very successful, smooth running engine. Unless it’s impossible to accommodate, perhaps because these threats are so existential that you’ll go out of business in six months or three months, that you need to completely scrap your engine in order to tackle this. And I’ve seen that before, right? Or it’s like, no, you’re being too complacent. I get you have AAA teams and stuff, but man, this is not the time, right? The time is all people on deck to solve this one problem.
But I think, again, most groups and most leaders feel like that too often and they end up scrapping their engine too early. And so they never get that smooth running engine. So I think it’s really important to think, okay, we do want to have AAA teams, we do want to have autonomous organizations, because that’s eventually how we scale. That is the scale mechanism. And so how do we have that as our base, but then build on top of that in order to be able to handle these extraneous circumstances that are cropping up?
So we’ve covered a lot, Andy. Any other last words to say, about our company and its structure and how the CTO operates at this stage?
Andy: I think I’d just reiterate that your role at this point is not to be going down and working with the individual engineers. Other than Gemba walks, we still want you doing that. Your purpose at this point is to make sure that that whole engine is working and that the engine doesn’t fall apart when the world changes a bit. And so finding your techniques, and we’ve talked about several here: we talked about doing the demos so that you know what’s happening in your engine; we talked about having the staff meetings of different forms so that you can guide what’s happening. And then what we didn’t talk about, which we’ll probably leave and maybe get into in some later episodes is, you’re not looking just inward at your tech team, but you’re also spending a lot of time looking outward. You’re really the face of the technology department and Promoting how it should be working and how the rest of the company around you should be working.
If you really are like this, the core of what you’re doing is based on this tech stuff working, well, you should be having a lot of influence in other areas of the business and working with them to make sure that you’re supporting them in the way they need to be supported and they’re supporting you in the way you need to be supported.
We didn’t get to that, but that’s another thing that we would probably expect to be taking up quite a bit of the attention of a CTO at this stage.
Mon-Chaio: I like it, Andy. In fact, I don’t think we talk enough about that. The role of a CTO outside the team versus within the team. And so maybe we’ll cue that up for the new year.
All right. We’ve left our company here. They are super successful, but running into a lot of stressors. And we’ve talked about as the eng leader, how did you scale your team? How do you interact with that scaled team? And what happens when these stressors come in and do you change your scaling techniques and change your structure? How do you go about accounting for that?
In our next episode, this company will grow even more, and it will find that since they have drivers driving around picking up passengers, why can’t they pick up other things, like packages? Or food delivery, perhaps? And we’ll start to explore, as the eng leader here, how do you think about your organization and structure your organization? You have a platform that has dispatch and routing. Are you saying now you have a shared platform, but now they have KPIs around food delivery drivers, or are you saying you’re going to completely segment them off, or you’re going to have people come in and build in the platform code, but not be in the platform team? So those are going to be the types of discussions we have as this company starts to expand into. adjacent markets that are outside of their core business, but that they also want to be dominant in because they have market share, they have the driver employees, and they have synergy around that. That’s what we’ll be diving into next.
If you’ve enjoyed this episode, please rate, please subscribe, and also reach out to us at hosts@thettlpodcast.com. That’s hosts with an ‘s’. We always love to hear from you, hear about your thoughts, hear about your disagreements. We love conversation. That’s why we do the podcast. We also do a lot of consulting with individuals and companies to help them through these scaling challenges that they might have. And so if you’re interested in that, reach out to us as well.
Well, I think this is the end of this episode. Until next time, be kind and stay curious.
Leave a Reply