Show Notes
This is the fourth 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.
Mon-Chaio and Andy advance into the next phase of scaling up a hypothetical ride-sharing company, exploring how it might transition to food delivery. They discuss the difference between Explore and Extract phases, emphasizing the need for continuous experimentation. The episode outlines structural changes, such as forming new, separate teams to drive innovation, while leveraging existing platforms. With practical insights for CTOs on managing KPIs and sustaining agile environments, listeners will discover the pitfalls of excessive funding and the importance of maintaining an experimental mindset. Tune in to learn how to balance execution with innovation and prepare for the final part on scaling through acquisitions.
References
- Lean Enterprise – https://www.oreilly.com/library/view/lean-enterprise/9781491946527/
- Episode: Analysing a Situation Using BART – https://spotifycreators-web.app.link/e/tTJ5eUTl3Ob
Transcript
Mon-Chaio: Thank you listeners for joining us today, where we’re going to be talking about part four of scaling up from garage to global those who haven’t been following along. We are following a hypothetical company from three people in a garage with an idea, all the way through a global organization with many thousands of people, I’m talking about as an engineering org how you might scale that.
How your processes are different, how your teams are different, how your thought processes are different as you grow. Where we left off last time was a company that was expanding internationally and finding that they were having to placate a whole new set of customers, maybe placate’s the wrong word. They were having to satisfy a whole new set of customers that weren’t the customers that use their product. In this case, regulators who had different demands, different timelines, different understanding about technology.
And we talked about how they might structure themselves, how they might think about those challenges, as well as having to. tamp down or compete against these upstart competitors that are much smaller or much more nimble, much more focused than they are. And so we talked about how they might be nimble and be able to redirect themselves in order to meet these challenges without completely destroying the engine that they had built, that revenue engine, that build engine that allowed them to be successful in the first place.
Andy: What are we going to do today, Mon Chao? Where else can we take this?
Mon-Chaio: I think the next step here is to follow this company as they explore new ventures. And so we now have this company, which is large enough. They have essentially dominated. They’re vertical. They are the recognized world leader in ride sharing, as I didn’t mention on this episode yet, but, um, that’s the hypothetical company we’re talking about.
Somebody building a ride sharing company. So they have dominated the ride sharing company. They’re the worldwide leader in ride sharing, and they have built a bunch of different teams and platforms to support that. And now they’re thinking, wait a minute, these teams, this technology, these platforms that we’ve built. could possibly support other businesses, couldn’t it? And so shouldn’t we go out and stake a claim in other verticals, uh, such as courier or food delivery. And I think food delivery is the one that we’re going to be focused on today.
Andy: Food delivery, not parcel delivery. Food.
Mon-Chaio: Right, I think, uh, food delivery has a few more challenges to it, so I think it will be a little more interesting of a conversation. Uh, but parcel delivery, certainly, any type of delivery, right? I think this company thinks that they have a network of drivers, they have technology on routing, they have technology on dispatch.
And so why can’t they go into any other business that requires these technologies that they’ve built and spent a large amount of money perfecting and making world class?
Andy: All right. Yeah. Why can’t they like, what, what’s, what’s holding them back? What would, what would be in the way of them? Why can’t they just, uh, hand someone. Their, their phone and say, you’ve got a car. Now, uh, go to McDonald’s and, and pick up a burger and take it to this address.
Mon-Chaio: Well, I think, I don’t know that there’s a ton preventing them from doing that. I think, um, at least in their mind, in this hypothetical company’s mind, right. And we, we tried to say, Hey, you are you Andy, or you Mon Chiao, or you listener are the CTO of this company. Who’s grown along with this company. That must be what you’re thinking, right?
I have this app that my drivers already have. It shows me picking up passengers. Why can’t I just replace the logo of a passenger with like a logo of a hamburger? And that’s what I pick up. And then, you know, when I picked it up, I hit picked up and then I drive it to wherever it needs to go. And I
Andy: drop it off
Mon-Chaio: and I drop it off. And I think you can, but I think the nuances and the details about how you go about starting that business. So, Andy, maybe we can lay out, um, what this company might look like at this stage. Um, and what they might be tempted to do and how we think that might work.
Andy: All right. All right. Let’s, let’s, let’s play the mind games.
Mon-Chaio: All right. The mind games. I like it. This hypothetical company, at this point, might be structured in the same three pillars that we talked about in the last episode. Namely a rider group, a driver group, and a platform group. But I think the difference here is now they’ve gone through the regulatory bit.
They’re obviously still in it, but they’ve done a bunch of regulatory work and they learned a lot about it. They’ve now expanded international and learned a lot about what it takes to operate in other countries, that sort of a thing. And what they’ve realized is in order to keep up with their upstart competitors, they need to be a little bit more agile in how they deal with these types of things.
So for example, what the rider group has done at this point, uh, again, hypothetically, right? This is our hypothetical company, is they’ve split the group internally into a platform group and an experiences group. So the platform group builds sort of the building blocks of the rider app. Here’s how you request a ride, what shows up on the screen when the cars are coming toward you, things like that, right?
And then the experience group Can then move quickly in each jurisdiction. So perhaps there is a Cambodia jurisdiction or Southeast Asia or whatever makes sense for common experiences. And they can say, Oh, well, for a writer to require to write here, they have to do payment first. Um, Before I let them see anything, or they have to have met certain requirements, or I want them to see two maps for two different regions, or whatever the case may be, right?
But we, they have segmented themselves into an experience group that’s very focused on the customer and allows them to move fast, supported by a platform group that builds pieces that they can kind of Lego rearrange or, or configure that sort of a thing. And, uh,
Andy: And, and, and also it’s starting to take on a bit of a fractal nature that you see in organizations a lot, where the outer structure starts to get mirrored on the inner structure.
Mon-Chaio: Absolutely. For the driver group, they’ve learned that regulation is actually a very big key part of their business. And so, um, while they also have a platform sub team and an experience sub team, just like the rider group does. They also now have a compliance sub team that handles jurisdictional standards, regulatory standards, making sure that drivers who sign up are regulatorily good, as well as existing drivers don’t fall out with new regulations coming in. And so, there, that’s kind of a, Check to the other part, right?
Because driver experience, their idea is how do we bring in more drivers? How do we retain drivers? And the compliance side is how do we make sure only good drivers exist in the platform? And so they, they keep a check on each other, but they’re within the same group.
And then lastly, we talked about the platform pillar. Uh, it’s remained mostly unchanged. Um, but of course, uh, as the driver and rider teams have matured, they’ve put more features into the platform team. All right. And they said, well, we’ve proven these features to production eyes, but now this isn’t our key focus, we actually want to be able to focus more clearly on the customer and so,
Andy: special widgets and now we don’t want to maintain them. Please put them into the platform.
Mon-Chaio: right, exactly, exactly. Uh, and you know, maybe you have more technical expertise on a specific thing, like, um, network routing or something, right, a rider experience team, while in the smaller stages. They would have to worry about that now. They say, look, um, we want to hire some experts to worry about this type of thing.
And we want to worry about things that are customer facing.
Andy: Yeah.
Mon-Chaio: And I think that’s exactly what this company has decided to do. They said they decided that the key for whether a team fits within the rider driver verticals or in the platform verticals actually comes down to who’s the primary customer of their KPI.
So. If the primary customer of the KPI is a customer that fits in those verticals, whereas if the primary KPI is, for example, in a routing algorithm, the primary KPI might be time to target compared to Google, Apple navigation or smoothness of the path, right? Fewer stoplights, fewer turns, that sort of a thing.
So that’s how we’re structured. So now we have the Eats business, Andy, and as you were mentioning, why it’s just a lot of different parts of this business, right? So, um, you have a rider app where you’re allowed to request stuff. So. So would you just go to that rider app team and say, Hey, we want a new front end to your app where riders are replaced by burgers or whatever, or cars are replaced by burgers, or it now shows restaurants as points of interest instead of stadiums as points of interest.
And then you go to the routing team and you say, Hey, I need a new feature in the routing algos to do this. And then you go to the driver team and you say, Hey, I need, um, Y’all to build a new onboarding platform for restaurants as well since you built driver onboarding now restaurants need to come on board. Right? So we need you to build a new onboarding platform.
Then y’all have platform code. So can you do that? Can you just put it on the roadmaps? Um, do you just say, oh, can you dedicate 20 percent of your organization to this new road, uh, parallel roadmap that I’m building and all of you are now building this and 20 percent of your org is building that and I want to see that on your KPIs as you, you know, do your debriefing, back briefing, status reports.
Do you form a new team and say, hey, well, let’s get a hundred new engineers. And those engineers will then ask for features from all of these platform teams, um, in order to build. What, what do you do, Andy?
Andy: I mean, you can do anything you want. You could do all, you could do any of those. I don’t think, I don’t think that they’re all going to end up with the effect that you’re looking for. Because we have to, we have to think about what is the mentality of this business now.
Mon-Chaio: Hmm. Okay.
Andy: The mentality of this business now is in the, I mean it’s probably still expanding a bit,
Mon-Chaio: Mm hmm.
Andy: in a lot of cases, and you can see it with the evolution of having a platform team, Uh, in each one of these, in, in the rider and in the driver departments.
Which is that they’re starting to extract, they’re starting to optimize. They’re starting to come up with, how do we, how do we get this all optimized completely? And in that model, they’re thinking about things very differently. They’re, they’re thinking about how can they do these things low cost, little maintenance.
And all of that. But what you’re going to now be asking them to do is something very different. Well, possibly something very different. Let’s talk about hubris for a little bit,
Mon-Chaio: I love talking about hubris. Let’s.
Andy: which is the, the certainty in what it is you’re asking them to do, because these teams will now have very much a mentality of we’re a machine, you give us stuff and we grind through it and we optimize it. So if you, if you go into this with this belief that it is just a small change to the rider app, and it is just a small change to the driver app, all of the routing algorithms stay the same, all of the UI stays the same other than some icon changes and a little bit of search of what are the points of interest.
If, if you go into that and you just say, now build it, they will build it, and they’ll build it, and they’ll, they’ll build it bulletproof, and they’ll make it great and amazing. And then you’ll get it out into the market and you’ll probably find out that it’s not quite right. And so you’ll come back and you’ll be like, okay, that, that, that didn’t work.
And now it’s six months later and you think, okay, let’s do our second try. And then six months after that, let’s do our third try.
Mon-Chaio: Mm hmm.
Andy: And all through this, you’ve got your teams complaining. You keep telling us to work on this thing and work on that thing. And now we’re confused about what we’re doing. So I would, I would say you could do it, but I don’t think you’re going to get great results.
Because you’ll, if you did it that way, you would think, I know what I’m doing, and you’re working with a group that, uh, is not set up to doubt itself.
Mon-Chaio: I think that’s exactly right. So I think what you mentioned, Andy, was around this concept of. Explore, Expand, Extract that we’ve talked a lot on this podcast about. That there are distinct stages in not just a company’s evolution, but a product’s evolution and even each individual build’s evolution, where you have to behave differently.
And to go to a somewhat tangential topic for just one second, we talk about this a lot not just in product build. One area where we talk about it is in leadership styles, right? We say, look, situations that are different require different leadership styles. Sometimes you have to be autocratic, sometimes you have to be democratic.
It’s the same thing with companies and builds. When you’re in the explore stage, you work and you think and you operate differently than when you’re in the expand stage. And I think, or sorry, than when you’re in the extract stage. And I think what I heard you say, Andy, is you have these large teams that are in the end of the expand and through the extract stage.
And this new project is actually an explore project. And you’re putting it on these teams and now you’re asking them also be able to think in an explore way. And it sounds like what you’re saying is that’s probably not going to work too
Andy: Yeah. I, I don’t think I would recommend that. What about the idea, Mon Chiao, of, we take a few product people, And they start testing hypotheses. They go out to potential customers and they, they talk to other delivery groups that possibly already exist. And then they come back after having tested some ideas that way,
Mon-Chaio: hmm.
Andy: and then they come back and they get a couple engineers and those engineers, they don’t build anything, but they start designing, uh, an MVP using all of the platform and then they’re told like they, they don’t.
They don’t get to rewrite anything. They need to use what’s there in the platform. They start designing it and then they hand that as a small project to those groups and they’re like here one week get us something Work on that. What do you think of that one?
Mon-Chaio: I think that can work better. Mm hmm. I’m not sure it works great in practice though, Andy, and I’ll give you an example. I think it’s great. I like where your head is at in terms of let’s use these platforms as is. We don’t want to randomize these teams in Explore, Extract. They have important KPIs that they’re trying to meet.
Yes.
Andy: Mm hmm
Mon-Chaio: So we don’t want to randomize them and say, Hey, completely rebuild your platform for our needs, or make this branch and do this other thing that we really need. But on the other hand, it doesn’t quite feel right to say, okay, well, the platform has these little cars moving along the road. Let’s just change them to sandwich icons. Can we even change them to sandwich icons? Maybe not. Maybe that’s not a feature in the platform. So you were
Andy: and should we add it to the platform? Why would we add that to the platform?
Mon-Chaio: Right. Or, I mean, it may be just changing some wording and the wording might not even be right or the flow might not even be right.
So, you know, maybe your rideshare flow is I put a POI down and then I get a list of options for who can deliver. What, what about the menu part of it? I don’t have a menu thing in the platform.
And
Andy: just types of cars.
Mon-Chaio: right. There’s just types, okay. There’s just types of cars, right? Um, McDonald’s is like, one is like, uh, you know, the, the, uh, the cheap service, right, and then the limo service is like the steakhouse and you just get a list of cars. So I think that is, if we could do that, that would be great. And I think that there are a lot of things, a lot of explore type expansions where that is probably possible for many companies.
I think in our specific food delivery example, I don’t think it would work so well to just have to use off the shelf platform pieces.
Andy: Yeah, I, I, I agree. Um, as we went through it, no, actually before I even said it, I was, I was putting it out there as a, as a, as a talking point. I, yeah, I agree. I don’t, I don’t think it would work too well either because it’s kind of, as we were getting to, we’re tying ourselves to the current model of what our business does right now.
And, and this goes back to the hubris. We shouldn’t. We shouldn’t assume upfront that the new business is just our old business with a few changes. It might turn out that it is, but if we start out assuming that, we’ve got like a straitjacket on before we’ve even explored how could this possibly work.
Mon-Chaio: I love it. Yeah. I think that straitjacket imagery really resonates to me because it kind of constrains you in a way where you can only go in one direction. On the other hand, we do need to understand that we are not a new company here. This group, this company, did not get into food delivery because they did all this market research that said food delivery was the next up and coming business and it was a trillion dollar business.
I mean, they obviously did that. But a big reason they got into it was because they thought that they could outperform any competitor since they have probably Built, already built 60 to 80 percent of the technology needed to support this.
Andy: And that is a hypothesis that they should work on proving.
Mon-Chaio: I agree. I agree.
Andy: So, uh, so I, I would suggest absolutely. Um, I think the way that I would suggest that they work on it, And I think we might disagree on this a little bit given our pre show conversation. I would say the way to approach this is treat it like a little internal startup.
Mon-Chaio: Hmm. Mm
Andy: say, we have this idea, we’re going to get a group of people, we’re going to say, what’s our minimal set of people that could figure this out? And it might be, you need someone with a good product mindset. You need someone with a bit of tech understanding. You need someone who’s a bit of a businessman.
Business person who, who can, who can go out and, and sell it and, and figure out what, what are people willing to pay? And all of them work together to start, just like we talked about at the very beginning of the first episode, sitting in that, in that garage, working out, okay, how could we do this? How could we do that?
Let’s test this idea. Let’s try out something here. Let’s try out something there. And just like we did then, it’s not that we’re talking years of that,
Mon-Chaio: Mm
Andy: The, the company made it through that in a few months. They kind of started getting this idea. They tested out those ideas. And you start with that, but even then, you don’t then flood them with money. So I’m going, I’m going from, suggestions of the book Lean Enterprise. One of the things that they, they pointed out was, if you flood them with money, you get rid of that imperative to learn. They’ll kick into execution mode before they’ve actually fully fleshed out what it is that they need to do.
Now, you can support them, absolutely. Because, if part of the hypothesis is, our existing platform will make this all much easier, our existing reach, our name, will make this all just kind of work, test out that idea. Product people, uh, business person, go out and check, will the name, we should have given this company a name.
Laughter.
Mon-Chaio: difficult
Andy: Yeah.
Mon-Chaio: one, right?
Andy: Will this name catch on? Will, if you saw that you could order food or order drinks or whatever through this, would you trust it more? Or would it need to be under a different name because it’s just a cognitive dissonance for people?
Mon-Chaio: Mm hmm.
Andy: Does it help or hinder? Tech person, as they start figuring out what this kind of flow would look like, go and dig through the guts of the platform and the driver app and the rider app and figure out are there things in there that you could scavenge that would be hard for you to build? Pull it out. Duplicate it. Like copy and paste it if you need to at the beginning to prove the idea. If, if it turns out that like the mapping system, it does 99 percent of what you want, But you’d need to do this massive internal refactor and add in a new parameter. Don’t bother them with that. Copy it out, make your change, prove that this works, and then work on plumbing it back into the original system. But it’s, it’s, it’s this idea. Don’t give them, don’t give this group a ton of money because then they’ll start trying to rebuild everything.
Mon-Chaio: Like where you’re coming from, Andy. I think the mechanics of how this would go about, I do completely agree with. I think even though we have these groups that are established with these sets of technologies, I agree that the most likely, the most successful path is likely going to be fork that code, copy it, put it in a new. Put it in a new repository and release it as something different. Do not try to put it back into the main line of code. And that’s, you said that right at the end. I don’t know if you gave it a ton of thought, but I don’t think at this stage I would ever start to think, “Hey, I made a change in the mapping algorithm.
I’m going to like push it back into the main line” at all. I would say that. You know, these two groups, I don’t think their code would talk to each other for the most part, um, unless they were reusing something immediate,
like
Andy: in, in my mind, one of the things that you always need to keep in is this business may pivot radically, it may fail, it may turn out that this is just a complete dead end, no matter how excited we were about it. And you want this company now, it’s, it’s, it’s big enough that it needs to start finding new things it wants to do. I would expect that they’ve got several of these going on at once, and the majority of those aren’t going to make it anywhere.
Mon-Chaio: Uh huh. Okay.
Andy: And so if all of them are just like shoving things into the main platform, that’s a recipe for the main platform never being able to change at some point. And, and so yeah, keep it out until it’s proven its worth.
Mon-Chaio: I like that imagery too, because you can see a bunch of these different companies just like piling stuff in and say, Hey, please integrate. Please put this in your main build platform in CI and please allow, uh, put, hook this up to your monitoring system or whatnot.
Andy: Yeah.
And five years later, some engineer’s going through the code and going like, what does this flag called, if is Chicago pizzeria, Even mean.
Mon-Chaio: Um, and we’ve all seen those flags in code before, possibly not for large companies that are doing this, but, uh, We’ve all seen that. So I agree, Andy. I think fork this code, start to work on it on your own. Don’t try and put it back into the mainline. But because we do have a head start, we are not quite starting at the beginning like we were when we started this hypothetical company, right?
For example, we, clearly in episodes, I believe one and maybe even episode two said, no, no, no, there is no iOS and Android app here. You are writing a simple web app that people can use on a mobile browser on their phone to prove something.
Yes?
Andy: Now, now here we have a first ability to test one of our hypotheses that we’ve got the technology to do this better. So we’ve got this platform team with a whole app setup that should let us easily publish an Android app and an iOS app.
Mon-Chaio: Mm hmm. And if that’s true, right, and if that’s true, then do it, right? The difference between that, as you were saying, Andy, is previously you needed to hire an iOS developer, you needed to hire an Android developer, they both needed to figure out how do we share code, what parts don’t we share? That part has already been solved in your company.
And so, it’s not that we’re saying when you start you should always start with a web app. No, it’s around speed of proving or disproving your hypothesis. And since you have these platform teams that make it quick, fast, maybe even faster than proving your hypothesis with a little website, at the very least not very much slower.
You can go ahead and head on out there, right? Same thing. You probably have designers that can design you cool logos and animations. Utilize them. We’re not saying that you can’t utilize them. You have them. Utilize them.
And I think the part that we don’t quite see eye to eye on is how small should this team be or must it be small?
Andy: mmmm.
Mon-Chaio: So I will give you a couple things for us to think about. One is our hypothetical company started as three people in a garage with no money. Yes, so they kind of scrappily made their way up and of course now have, um, in our example, built this great global company. There are also other founders who have had three or four successful exits and can pitch to VCs with slide decks. We’ve seen this in the world, yes? So you get a few founders together that VCs see as superstar founders. They build a PowerPoint deck, they put it in front of the VCs, and the VCs say, Hey, here’s 50 million. Our eats exam, our food delivery example is more akin to that example now, because not only do we think that our brand and our platform can accelerate ourselves into this space, we also think that our size and our revenue can help accelerate ourselves into the space right now. So. This company, I feel like, should be able to say here is 10 million, 20 million as a way to accelerate our exploration into the space.
Now, we can talk about whether that’s right or wrong, but if we can give them 20 million and the team only needs to, should, in your example, only be six or seven people, what do we do with the rest of this money? And are you just saying that this money can’t accelerate and that money itself is not an accelerator.
Is that what you’re saying, Andy?
Andy: view on this is that the money will accelerate you to execution.
Mon-Chaio: Mm hmm.
Andy: And groups are very good at finding ways to spend money.
Mon-Chaio: Mm hmm.
Andy: And so until you have really good evidence Because one of the things is, yeah, you’ve got these investor pitch cycles. One of the difficult parts of the whole process venture capital backed startup ecosystem is having to explain and, and pro, promote and, and get that.
But one thing it does do is it creates a back pressure on, on, uh, uh, ideas that don’t seem to have anywhere to go, uh, get their losses cut before they’ve got, like, a hundred million behind them.
Mon-Chaio: Hmm.
Andy: And there’s lots of examples of companies that did suddenly get a hundred million behind them, and then wasted all of it.
Mon-Chaio: Sure.
Andy: And so, it’s not to say that you wouldn’t over time, uh, fund them to that level. Uh, but my, my view on it is that you would keep them tight.
Mon-Chaio: But can’t you keep them tight but still keep them, like, still grow them large? Like, does everything have to start with three developers in a garage for it to be successful with no money? Like, I
Andy: I don’t, I don’t it
Mon-Chaio: that that’s the case.
Andy: I don’t think it has to, but I think there is a big difference between three developers in a garage and no money and uh,
uh, suddenly being given, uh, from nothing to. Ten million dollars and go start spending it. I think my biggest fear is that you stop, you, you feel that you have to spend the money, and so you stop testing your ideas, because testing your ideas doesn’t give a lot of parallelization, and so you, you, you, you start very quickly saying, well, we can parallelize by building these ideas, and you start building a whole bunch, and maybe you, maybe you’re lucky, And maybe you built it out.
But that, that, uh, 10 million that you were just holding onto and doing that with could have also been split between you and three other projects that were all going to try out ideas. And as an organization, as an enterprise, you’ve now said, I don’t believe those other two ideas.
Mon-Chaio: I can see where you’re coming from
Andy: So, so yeah, so that, that’s, that’s my, my, my way of thinking about it is this is all about opportunities and you have opportunities for other things. Now, if you’ve got 10 million. And you don’t have a ton of other ideas, and you’re willing to just lose it, then I’d say go for it. I think you’d still struggle because you’d start tripping over yourself.
So, I, I, I,
Mon-Chaio: Yeah,
Andy: for it.
Mon-Chaio: I think setting aside whether it’s a good idea for the company to spend this money could because that’s a difficult conversation, right? For a company who’s, you know, in the 50 million ARR range. Spending 10 million on one idea to the exclusion of other ideas probably isn’t great But if you’re a public company and you’re bringing in a hundred billion dollars a year
Andy: Mm
Mon-Chaio: You know even spending a hundred million dollars.
on an idea might be fine it’s it’s a drop in the hat, right?
Especially if you don’t have somewhere else to spend it now We could talk about like should you return it to the shareholder, you know, all of that sort of stuff We’re not gonna get to that. I’m not a finance guy either. So I’m not going to A positive opinion there but I do like what you’ve said which is that oftentimes money leads to build and build leads to the stopping of testing hypotheses and I think for a product in the explore stage It is critical.
We both believe it’s critical hypotheses to be quickly tested and checked So that I think is the barometer that a company needs to use when it thinks about funding So
Andy: Now, I, I have, I have an even worse sin for you than just giving them more money than I think that they should get immediately. And that is holding them to Like a complete cost estimate and development timeline and all of that to get that money.
Mon-Chaio: Mm hmm, mm hmm.
Andy: you probably don’t see this too much in Silicon Valley tech companies.
And maybe you do, I haven’t worked in them.
Mon-Chaio: Hehehehehehehehe. Mm
Andy: Uh,
Mon-Chaio: Mm
Andy: see it very much, I would, I hypothesize that it’s because they have so much money to burn. But the companies that don’t have quite as much money to burn, uh, that feel their, their costs a little bit tighter, they start going down the path of, well, in order to just put any money behind this, we need a timeline, uh, a proposal, uh, what your deliverables are going to be, when we’re going to get those, what we’re going to get out of them.
And that’s it. Well, that actually sets you up even worse because then what it’s setting up is the only thing you can do when you’ve got this money is now execute fast as possible in order to try to make those things become a reality because that’s probably what you’re going to get measured on.
Mon-Chaio: Right.
Andy: But that’s also a very common way that in a, in a financial controlling system, uh, that, that, that’s the, like, the way that you make sure that you’re not wasting your money. Strangely enough, it causes the most waste of money.
Mon-Chaio: Mm hmm.
Andy: Because you have to have all that time upfront doing that planning, doing those estimations, doing the investigation to figure out exactly what it is you’re going to build and, and all of that to then get it signed off and then usually not be able to deliver to what you just planned because you probably put together a two year, a three year plan.
Mon-Chaio: Or, even worse, you did deliver to the plan,
Andy: Yeah.
Mon-Chaio: but it didn’t
work.
Andy: it was completely useless
Mon-Chaio: And very likely, if you hadn’t put together this plan and you allowed for more experimentation, you would have found something there to salvage, right? That’s that hubris part. You will build this. I’m giving you money because you will build this that we think is the right thing to build Without having any idea that like maybe it’s not maybe it’s something completely different that after we build for a month we’ll know.
Andy: What, what do we leave people with? What, what, what should they be looking for?
Is it, like, entirely on just up to what they’re comfortable with, or is there some clear guidance that we can give them about how to do this? Mmm.
Mon-Chaio: In my opinion, if I were to summarize it, I would, I would summarize it as give as much money as you’re willing, able, what your gut feel is right, but understand that often with more money comes a lack of experimentation. And, If you agree that you’re in the explore phase and Andy we haven’t actually talked about this I think maybe a lot of companies believe that they’re in the expand phase on these new projects that they’ve Somehow skipped the explore phase altogether or the explore phase has been done in a document that was written by pm or something, but Not
Andy: Oh, we’ve explored this. I’ve talked to three people and I’ve written up this huge document.
Mon-Chaio: I’ve up a white paper that I published and You know Gartner has taken this white paper and said it’s the future or whatever that’s explore right? So now we’re gonna expand If you’re in the explore stage experimentation is crucial. And so if you can experiment quickly easily with a lot of money then then do it but if your money is stopping you from experimenting then don’t and i’ll just offer this one thing which is just like in the app example If we had these three guys in a garage in, you know, in our part one, Andy, but instead they had been given 20 million dollars to start off, honestly, I might have suggested that they start off with the iOS and Android apps.
Maybe. I don’t know. I think sometimes money can do that. It can help you accelerate those types of things into saying, well, we think there’s a very high likelihood Of needing an android and ios app, but in our example, that’s you know Two engineers you need to hire and they’re different you need to manage them and you need to build them and whatnot But if you have the money we say we have the platform now you can build it But if you have the money sometimes money can help accelerate that too. And so that’s my guidance is to say Yeah, accelerate where you can with money But keep a close eye that it’s not just moving to execution that whatever you’re executing with that money is for quick experimentation
Andy: and I I was gonna say that I think the key to it is though to keep your eye on the quick experimentation. A company of this size Will inherent within it have things that start pulling you away from that quick experimentation.
We’ve talked about a few of them already. One of them is like the essentially the funding process. You need to come up with plans and give a good pitch and all of that. There’s another one which is the the KPIs that might start getting applied either to individuals or to the projects or teams themselves. Especially if all of the company has kind of as one moved from, uh, explore to expand and into extract, which this company has. This company is in really big danger of misapplying their measures of success because this is probably what, 10 years later at this point. They’ve been now expanding slash extracting for a good three or four years now, probably, and their high level metrics almost certainly are very much about revenue and sales and, and the kind of like that cash coming in. And if they take that same mentality and apply it to this new venture, they’re going to look at that other thing. And they’re going to be like, okay. Q1, what’s your revenue going to be? And the only answer that the new venture can give that’s real is probably zero. But that’s not going to be an answer that’s going to work for this measurement system. And so they’re going to need to come up with ways of creating that. And then it starts short circuiting the ability to actually experiment. So the, the Three Horizons model says that there’s three kind of stages. Uh, one being a few years into the future, where you’re trying to create a new business.
And your measures around that should be more about word of mouth, uh, popularity, name brand recognition, those kinds of things. Like, are people even recognizing that you’re doing something out there? You’re, you’re next is a couple years away, uh, maybe a year or more. And those are the ones that are just starting to catch hold.
They’re kind of like, today’s growth and tomorrow’s cashflow. You’re not really getting much from them yet, but you’re starting to see like, oh, it’s growing, it’s going. And there, your primary measure is going to be along the lines of sales that you’re making. And are you getting those targets that you’re looking for in terms of, like, particular kinds of customers or particular buyers?
And then your, your final horizon is the stuff right now. And so in this company, this current ride hailing app, is in that horizon. And there, your primary measures are going to be around revenues, and market share, and profitability. And so, and that’s, that’s another reason why if it was just taking people from these teams, and saying like, Hey, you, do what you have been doing, but now start working on this new exploration idea.
Their measures of success are completely different. antithetical to trying out a new idea. In fact, if they tried a new idea, it would harm all of their measures and it would, it would probably end up with those teams sabotaging the new idea because their measures tell them that working on that idea is bad for their career.
Mon-Chaio: hmm. Or bad for their company. Um, we gave an example, I think, in our very, very first episode analyzing a situation using BART where we talked about a company that said they were building a business product and a consumer product And the consumer product looked at the business product and said, I mean, you have no users, why would I give you any time of day to help you build these? I have my KPIs that I need to hit. And so leadership said, well, here’s a new explore KPIs for you to And they’re like, okay, but these KPIs don’t really move. So, um,
Andy: I can do
Mon-Chaio: to do my expand extract work. Right. Um, so. So, yes, that’s a very apt example, Andy, and I think it happens all the time.
And so, yes, I really, really do believe, and it might be weird to hear, well, it’s just a person. Like, why can’t they expand one time and explore, you know, two hours later? Or why can’t they extract for four hours a day and then explore for two hours a day? Just in practice, and I don’t have the psychology papers here because we haven’t researched this.
But in practice, I have very rarely, if ever, seen that work.
Andy: yeah. Just the mental gymnastics to shift from one mode of thinking to another. from one second to the next, uh, can be difficult. It’s, it’s hard enough at more of like the executive level, the management level, to kind of go from, uh, thinking of, uh, hearing about the progress on one to hearing about the progress from another and having, having even like the metrics in front of you and trying to think about like, is this going well?
Or is this not? Am I hearing the, the, the responses that make sense? Cause it has to be so contextual. Mm
Mon-Chaio: Right? You have to remember, oh, if it’s an extract phase thing, I need to harp on them about this detail that I see that’s not meeting the revenue goal. Whereas if I’m in the explore phase, I need to help them generate creative ideas and make sure, and that’s a very difficult change to make, even as an executive, I agree. And I think, Andy, that is actually why I mean, we, we were starting this series to talk mostly about how do you structure and scale engineering organizations? Now, this episode has delved a lot into kind of how you think about a company and exploration versus extract, but I think that was super necessary because basically, Andy, I think our tactic is for this hypothetical company starting food delivery, start a new group, which is almost completely separate than the old group.
Put a new leader into place. Make them copy technology. Yeah, ask them, say, hey, uh, I copied your code, but I couldn’t understand this part. Or, did you think about doing this? Yeah, those are great conversations to have. But day to day, those groups should be almost separate. Uh, because one exists in Expand, Extract, and the other exists in Explore.
I think that’s the structural thing that we think about, right? And then I when we, and you touched on then as a leader, as a CTO, then how do you judge success of that organization? How do you manage them? And we talked about, well, you need to change the way you think about your KPIs. They’re not revenue based anymore. They’re explored, they’re exploration based and you have to shift your mindset and allow them to be able to do that exploration.
So, we are almost at the end of our five part series here. Next time we’ll be talking about the last part about company scaling, where a lot of these companies luckily or unluckily get to, as they have a little longevity, which is they scale by acquisition. And Andy, I think you and I have both been in companies that have acquired other companies or been part of companies that have been acquired by larger companies.
Andy: I’ve been in both. I’ve, I’ve been in a company that acquired other companies and I’ve been in a company that’s both been acquired by another company.
Mon-Chaio: Yeah, I have not, I have not been in the latter. I’ve only been in companies that have acquired smaller companies.
Andy: Right.
Mon-Chaio: So the topic for next time will be our hypothetical company acquiring one or more smaller companies that don’t quite behave like them and don’t quite have the same technology stack.
And what do we do with that? How do we think about how we structure our organization, how we shift and grow our organization as these sorts of things happen? So please join us next time as we finish up with part five of scaling up from garage to global. If you enjoyed this podcast, please recommend it to your friends. And whether you enjoyed it or not, hopefully you have some thoughts about what we’ve talked about today. Please reach out to us at hosts at the TTL podcast dot com. That’s hosts with an S at the TTL podcast dot com. We also like to point out at this time that we help individuals and companies go through their scaling pains.
And as you may have heard, we don’t really do it through LESS or SAFE or through Scaled Agile or anything like that. We like to start from the principles that we’ve talked about in these episodes that you’ve heard. So if you or your company needs help with that, please also reach out to us. Until next time, be kind and stay curious.
Leave a Reply