Show Notes
This is the last episode 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 the final installment of ‘Scaling Up: From Garage to Global,’ Mon-Chaio and Andy dive deep into the complexities of integrating a newly acquired company into a well-established global brand. They discuss the challenges of balancing autonomy with necessary integration, especially when it comes to maintaining core cultural and strategic values. They also explore how to tackle hierarchical changes without disrupting existing processes and morale. Whether it’s ensuring safety protocols or managing cross-cutting concerns, this episode offers valuable insights on scalable methods to blend new entities while preserving essential operational integrity. Tune in for a nuanced conversation on managing growth and organizational cohesion.
References
Transcript
Mon-Chaio: Hello, listeners. We have finally come to part five of Scaling Up: From Garage to Global, where we follow a hypothetical ride-sharing company that started in a garage with three folks and has grown along the way. In the previous episodes, we’ve talked about the various levels of growth that they’ve gone through and how that changes how they might structure their organization, and especially how it changes as a senior leader, as the CTO of the organization, how that senior person has grown along with them and how their management style, the way they interact with their team, their processes, their rituals, their culture has changed as this organization has grown. And really we’ve been focused on what does it mean and how do you scale an organization? Because Andy, we talk a lot about don’t scale, right? Scaling is broken. And so, what do we mean by scaling is broken? What are the alternatives? So we hope to be able to illustrate it with this hypothetical example.
This company is now a global leader. They are in the United States. They are out there in the rest of the world, in international markets. They are a verb now, like Googling or Xeroxing. That is how entrenched in people’s lives that they are at this point, and entrenched in the cultural consciousness.
Is that the right word?
Andy: I think so.
Mon-Chaio: Yeah, the, I …
Andy: The zeitgeist.
Mon-Chaio: Yeah, the zeitgeist!
So they’re very successful. And we’ve talked in the past about, well, how do they handle scrappy startup competitors and compete with them when they’re less nimble than those folks? We’ve talked about how do they handle regulations. We’ve talked about how they scale internally. Today, what we’re going to focus on is how do they scale through acquisition?
So a lot of these types of companies, as they run into scrappy competitors, instead of competing with them, they will simply say “let’s go ahead and buy them.” And so we’ll talk about what does that mean as a senior leader, as the CTO, when you purchase a company, how do you integrate them? How do you change your structure? Do you change your structure? Do you change your culture? Do you interact with them differently than you interact with your homegrown folks?
But I think Andy, probably where we want to start is, there are actually a lot of different reasons to acquire a company, and that actually changes how we think about bringing them in and integrating, right?
Andy: Absolutely! So in the example that we’re going to go through, we have to think about the reason that we’re buying them. Are we buying them for their market share? Are we buying them for their product? Are we buying them for their customers? Are we buying them for an investment? Each one of those would cause us to do something fairly different.
If we were buying them as an investment, where it was like, we as a company, we just have some free cash, we might be acting a little bit like a private equity firm, where we go in and we say, we’re going to buy you out because we think we can cause you to do better, and then we’ll get a good return on this by selling you on later. Another reason, and this is actually an acquisition that I went through once, was buying them for their customers. And when you do that, you might just scrap the company.
Mon-Chaio: Mm-Hmm.
Andy: Because you really just want to make sure that this competing product doesn’t continue and you get their customers instead. And so you buy out the company and you migrate everyone onto your platform and you shut down the other company.
There is no real integration.
Mon-Chaio: Right.
Andy: You probably even set it up where you’re like, in one year, that other thing’s going to be shut down. We’re not going to do any maintenance. We’re not going to do any releases. We release just enough to migrate and that’s it.
Mon-Chaio: Mm-Hmm.
Andy: Um, you can acquire for their talent. Maybe you’re like, you know what? This other company is the place that has this interesting talent that we actually want to get. Essentially we want to hire the team, but we’re going to do it by buying the company that they work for. In which case, once again, you might not care about the product that they put together and you might just throw it away and say, go and work on our new product because that’s what we actually want you for.
Mon-Chaio: Right!
Andy: Uh, you can buy them for their market share. And this one is, you do actually have an interest in their product. You are specifically interested in the market that it’s serving. And you probably want to keep it going. And you might want to start over time integrating it into your other products, or maybe it’s a good addition to your other products.
So that’s where you’re more buying their market share. You’re not quite buying their customers, because maybe you don’t have a like-for-like replacement, or you don’t have anything that really got into that market . And now this, I think, is the case that we’re going to go down, which actually has probably the most nuance to what you do once you’ve done that acquisition. Now, what do you do with this group?
Mon-Chaio: Yeah. Because in some of these other examples, it’s really less nuanced as you were mentioning, Andy. You simply shut them down. But this last piece that you mentioned is really where we want to go with this example because there’s a number of interesting things I think we can talk about.
And so I think the example for us is this ride-sharing company has found it difficult to get into a specific jurisdiction. Perhaps that jurisdiction has really difficult regulations, or maybe the regulations are really based off of regulator relationships , and the startup that started there speaks the language, has the connections, and so they’ve built up those relationships to allow for smooth operation. Maybe it’s as simple as the culture is so different that it’s very difficult for an outsider to go in and understand what the consumers actually want in that jurisdiction. There are places where perhaps surveys don’t do well, perhaps in person panels aren’t the right way to go, and so if you don’t know how to market or how to do market research there, maybe it’s easier to buy somebody that’s already done the market research there.
In order to set this up to have an interesting conversation, let’s say that this competitor uses technology that’s completely different than what you’ve built your platform on. So perhaps you’ve built your platform on AWS. Maybe they’ve built their platform in house. So they’re using RabbitMQ for their queuing technology. They’re using Temporal for their workflow technology. They’re not on any sort of modern cloud-based platform. So they have a huge IT team that supports their data centers there.
Andy: And they have several data centers that are running all of their systems. And that’s the way that they think about the world.
Mon-Chaio: Exactly. And maybe they’re on a completely different metrics gathering technology. Maybe that’s also homegrown. Maybe they have their own Hadoop cluster that does all of their stats calculation. They have their own dashboards that they run.
So that’s the company you’ve acquired and you’ve acquired them because you want to get into the space. And as often happens Andy, the acquisition happens from the business side, right? The tech side is brought in to say, take a look. Do they have the right technology? Can it scale? And often the tech side says, yeah, I mean it’s there …
Andy: Yeah, it’ll work.
Mon-Chaio: Especially when they’re a scrappy startup. “It’s kind of a little janky, but it will work.” And so the business side says “great, thank you tech for your input.” they’ve acquired it. And now the CEO says, hey, we’ve acquired this, and in our quarterly board meetings, I want to be able to see the same sort of metrics that I see on my main company. Cause I want to be able to compare them and have them integrated. Yeah?
Andy: Of course. Yep. They’re like, well, we need to report on them the same way we report on our own stuff. Otherwise, how are we supposed to steer this ship?
Mon-Chaio: Right, absolutely! Perhaps your key metric here is riders per hour. And so you want to know how many riders per hour are we getting from this? It seems reasonable, right?
So, as the CTO, Andy, this new company has come in, it’s day one. They’re now part of this hypothetical company that we’ve invented. What do you do? Is this a huge migration thing where you have to spin up an internal team called the migration team to help them out? Is this a thing where you put migration tasks on the acquired company’s roadmap? Do you scrap all of their PMs and put your PMs in place so that you can speed that up? And they’re also perhaps not in your time zone either.
So how do you deal with all of this? What do you do as the CTO here?
Andy: So the way I’d think about this, and this I think gets to the scaling question that we’ve had. This is to me, the core of the scaling question. It’s the, do we combine or do we keep separate, and how do we interact? And to my mind, the way of running this is, at least for a while, you keep separate. You let them keep running, but you start working as you’re another stakeholder in this whole thing. Because you could say, oh no, we’re going to start a whole rewrite, get them onto the platform we’ve got and do all of that. But if we start combining, I would say you start hitting all of the scaling problems. So if we start trying to say, like, they’re now doing the same stuff as us, I think we start getting into that, like the team is bigger and bigger and bigger, and now we’re harder and harder to coordinate.
So actually what I’d go through here is I would think about, well, what’s the architecture? What’s the architecture of a federated company?
Mon-Chaio: Hmm.
Andy: And the architecture of a federated company is one where you’ve got these autonomous units, but you could kind of say that there’s an API, an interface contract, that they need to adhere to. And one of those, one of the big ones is the one that we’ve hit first is the CEO saying, hey, look, we need to report on something that’s consistent across all of these. Which means that they need to report on this kind of a measure, and we need to have some way of them doing that.
Now your very first pass, just like we were doing with the kind of like startup, your very first pass is go out and just do it manually. Every month go and grab the numbers. But over time, what you’d say is there’s kind of like a data API here. And so I would say each one of these divisions, each one of these groups, and we’d probably have wanted something like this internally already, there’s a data API of, look, you’re producing these kinds of measures, and those go into this data team, data group, and that group can help you in producing them, can help you in integrating into the data API so that we have the information we need. And I would kind of keep it like that and say like, okay, what’s the interface that we have here between these teams? At this point, it’s reporting on some information.
Mon-Chaio: Mm hmm.
Andy: What do you think? Would you go a different path , or how would you approach this?
Mon-Chaio: No, I think given the constraints that we have, at first blush, this seems like the best possible solution. The two of us talk a lot about platformizing too early. We talk about efficiency too early. Uh, you can’t see my hands, but I’m doing the classic quote unquote thing around efficiency. And I think it’s the same thing about acquiring companies.
There’s that hubris behind it – I’ll use that word that you used last episode – where the acquirer and the non-tech folks think it’s obvious that there’s so many commonalities. Why wouldn’t they just be common from an efficiency standpoint? But we have to learn and the only way to learn whether they’re truly common or not is to work through them. So I do agree. Treating this as kind of another company and saying, well, let’s interact with it through APIs is probably the right thing to do.
And I think, Andy, that means in this metrics reporting example, you would ask their PMs, well, we need to be able to report on these metrics or put these metrics in this sort of data store in the next two weeks, five weeks. And you would let them sort of run independently and prioritize and interact with them that way. Yes?
Andy: Yeah. You’d say, hey, look, we need to report on your number of riders per hour. And maybe they say, “hey, you know what, we’ve got a graphite metric on that already. Let’s just write a little app, how often do you need it updated?” “Oh, we only need it once a day.” “Okay. How do you want it measured across the day?”
Oh, now we’re getting interesting. And we’ll have that conversation and then it turns out that, oh, it’s just a simple little service that they write that runs on a cron job and loads the data in once a day. And we’re like, cool. But yes, it would be like, let’s tell them what we need and let them work on how to get it.
Mon-Chaio: Okay. I think that makes a lot of sense. It may not sound like that’s great since you bought this company. Why didn’t you just enter into a service agreement? But I think this is small steps, right? We’re not saying you live here for any length of time. We’re saying but this is where you start.
Andy: Yeah.
Mon-Chaio: As you start to learn more about what it means to operate together.
Now Andy, in the last episode we talked about the structure of this organization and broadly what we decided was the tech organization is split into three pillars: a rider pillar, a driver pillar, a platform pillar We’ve now acquired this new company. Is this new company a pillar? Do we integrate them into the pillars? It sounds like no, not at this stage. And remember, we talked about the types of check-ins and meetings that the CTO would have, these stakeholder check-ins across his leads, these deep dives. So would this new company start attending those meetings? Are you rolling them into these things? Like how should we think about that?
Andy: I think that’s where this gets a bit more tricky. I think still, my guidance, my way of thinking about it would be how can we keep them fairly separate? And the primary thing that I have in my head is like the Dunbar’s Number stuff. How do we keep our operating units – and I think that’s the key – how do we keep our operating units small, so that they can be nimble and do that stuff, and still understand what’s going on and be able to give guidance and steering and all of that.
So, I think, kind of like we just did with the reporting of this metric, the next thing would be, okay, we need to start working out what was our structure that we had, and maybe our structure breaks. Maybe this is our first acquisition of a company like this. And our structure hasn’t already been put in place for how do you handle these kinds of different groups? Because once a company starts growing globally, acquisitions almost become the norm rather than exception. So you’re going to be in a constant state of some other group is kind of part of it.
And I think a lot of companies I’ve seen, a lot of them that I’ve worked with, they take that almost as like an antibody effect. They’re like, we need to do something to get rid of these foreign entities inside our system.
Mon-Chaio: Mmm hmm.
Andy: And that never sat well with me. I can understand the reasoning behind it. It’s like, well, no, we are effective. We bought you because we’re more effective. But I also think it’s kind of ignoring reality, which is, even in the companies I’ve been in that had that mindset of we need to integrate here – they wanted to be like the Borg – it never looked integrated.
Mon-Chaio: Mm hmm.
Andy: And so my take is just accept that they are going to stay separate for a long time. And so think about how do you do that steering? And I think it would be, it’s going to sound strange, but it would be something along the lines of a Scrum of Scrums, where the purpose is not directly telling the individual groups what to do, but in sharing that information about what are the goals to then help each one of those groups have more information to make a better decision about what to be doing.
Mon-Chaio: Hmm, okay.
Andy: That’s my thinking about it is, you would start bringing them together, but not in a very directive manner.
Mon-Chaio: Hmm, interesting. I tend to agree with you, I think, the way that you interact with this team would be different. And so, I don’t think that the CTO would go in on day one and say, okay, I’m gonna treat you as a AAA unit. And remember all of our AAA units have these metrics that they have to meet that are their KPIs. And so what are your KPIs going to be? All right. So since you have these KPIs, we’re going to do these every-three-week meetings and brief and backbrief on these KPIs. I think it’s a little too early for that.
Andy: Mm hmm.
Mon-Chaio: Remember that at your company those things were brought up over time through a culture of working that made it natural for you to have those conversations. And where it was unnatural, we grew along with everybody else. This new company can often have their own culture. Where they say, KPIs, um, we just do the next thing on our roadmap. Like, that’s how we became successful is, customers ask for a thing, we do a thing. I don’t understand what you mean about KPIs. It could be that this company has scaled and grown through a bunch of remote workers in various parts of the world. And so this concept of teams owning KPIs is unnatural to them. You know, they have the app owner who sits in Bulgaria maybe. And then they have the routing algorithm owner who sits in China perhaps, and they don’t really talk to each other for weeks on end. And that’s how they operate.
And you say, well, that’s very foreign. That’s not how we operate. But they look at you and they say you’re foreign. I …
Andy: They look at these highly interacting teams and they’re like, people don’t have time to just sit with the problem. And we look at their system and we’re like, you guys aren’t talking to each other. How are you actually solving any problems?
Mon-Chaio: Exactly. So I think that the important thing to try to integrate as quickly as possible is the culture side. And in my view, when you start to try to integrate both the culture side, as well as the process side, as well as the technology side, you end up with this overload where the acquired company feels like everything is changing and nothing is the way we thought it was.
And then you start losing people, you have morale issues. And so I think the “keeping them separate” thing is important in order to allow them to function and produce at the rate they were producing before. That’s the reason why you bought them, right? That at least has to be the floor …
Andy: Mm.
Mon-Chaio: … of their effectiveness, is what they were doing when you purchased them and you’re hoping you can get to a ceiling without lowering the floor too much. And so I would say that , in my opinion, you want to keep these companies separate, but you want to find cultural touch points so that they can assimilate into the culture as quickly as possible.
Andy: Yeah.
Mon-Chaio: So the CTO, while they’re not doing these briefing/backbriefing things, I still do think that at their direct level, where we had talked about having a meeting where they come together to solve problems together – hey, what is the biggest problem you’re running into, what is the biggest problem I’m running into – I think bringing the leader or leaders of that new company into that, I think is very important because it’s not a tactical thing about what are we doing next and how do we do it – oftentimes it turns into that, but it should be steered away – but it’s more about, hey, let’s figure out how we think. What is your background? Where are you strong? Where are you weak? Where can we start to bring people together and people’s strengths together
And I think similarly, lower on down the chain, I think we should now start to, if we haven’t already, start to invent these touch points to allow, again, it’s not knowledge exchange, that’s not the important part, it’s cultural exchange. And that may be disguised through knowledge or mediated through knowledge, to use a research term, but the intent is cultural exchange. And so I think the old Spotify model had this concept of tribes or guilds, guilds, right? And so maybe you already have guilds, but maybe you don’t. So maybe you say, okay, well, this is the web technology guild, or this is the deployment guild, and then you start to bring those people together to talk about deployment practices and, slightly technology agnostic, right? But the intention is for them to start to interact, get a sense of how people think.
So I think that’s at least how I would think about the structure and the interaction. You’ll notice here I haven’t said anything about rolling them into your release train, into making sure that they’re doing Scrums the same way that you’re doing. I’ve explicitly said that the senior-level meetings are going to be completely different.
Andy: Mmm hmm.
Mon-Chaio: At least to start and I am a firm believer that that’s the right way to start to bring folks in.
Andy: Yeah. And I think I would actually anticipate that after time of people simply interacting for more of that cultural exchange, some of the tech choices, some of those other choices, would start to align. And some of them won’t. Some of them, people will make the assessment that these are just too disparate for us to try to align at all.
Mostly on some practices. I imagine tech, they wouldn’t do as much on. On practices they might start picking up things. I’ve seen the management practices change when the managers of the company I worked for and the managers of the company that acquired us actually started having regular sessions just to catch up, like every other week. The management practices of the other company started to change through that cultural exchange, through this thing about like … part of it came from, you guys actually need to learn the theory of management.
Mon-Chaio: Oh, and I think that’s super important. Way back in season one, we talked about: what is culture. We talked for almost three hours about it, right? Because we think it’s so important, and one of the things we mentioned was your cultural tenants should be a very, very small set, the core tenants, two, maybe three. And I think whatever those tenants are, that’s something that you need to really quickly find out in this organization you acquired, who’s in and who’s out.
Andy: Yeah.
Mon-Chaio: One of those things might be, if your tenant is something around learning all the time, then saying, hey, I’m gonna bring senior leaders from that org into my weekly management reading group immediately. And they’re either in or they’re out because if they don’t want to do this, we’re gonna work on moving on. That’s important, as long as your cultural group is small. Right, because if you have two cultural, three cultural nuggets, that’s great. If you have 10, then all of a sudden you’re getting rid of that entire organization because there’s no way everybody’s gonna fit into every piece.
Andy: Yeah. I think another thing to think about in this dynamic, there are kind of, I would call it a reverse takeover, that can happen. You can acquire another company and their culture is in some ways more powerful, more alluring than the one that your company has. And when you start doing these interactions, you’ll get so much more strongly influenced by them, even though they’re technically the less powerful party, that the memes, the thinking patterns from them will start taking over the way in which you operate.
And it’s something to be aware of. Because I think sometimes you can go into these things and you’re like, but we bought them. Why are we suddenly thinking like the way that they do? And that can have good consequences. It can have bad consequences. It has consequences. And it’s something to pay attention to, to notice, to evaluate, and to react to, to figure out what it is you want to do with that as you watch it play out.
I bring this up because it’s one of the analyses of what happened to Boeing, was that they had bought another company and their leadership structure was essentially taken over by the other company, which was a very different kind of managerial way of thinking about engineering, whereas the Boeing approach had been very much an engineering approach for how they ran things. And some people trace that to where Boeing’s problems now originate.
Mon-Chaio: That’s a good point. Culture can work both ways. And I really like that you pointed out that it’s not positive or negative. It is simply a consequence that can be both positive and negative and you have to figure out how to balance it So that, I think, is an easy answer, to basically keep them separate, but let’s throw a wrench in the works, shall we?
Andy: All right!
Mon-Chaio: So the CEO has said, hey, I want to know about these riders per hour metrics, and that seems pretty easy. And we’ve created all these processes to keep them separate. Perhaps a month later, the CEO comes and he says, okay, well now we’ve done even more market analysis. And remember the last two years when we started to form this vision of our company being safety first, like that’s our differentiator. We’re saying that we’re going to reduce the number of incidents on the road. We’re going to reduce the number of incidents between drivers and riders, assaults and other types of things, because we want to be seen as the most trusted, as the safest platform on the road.
Now this acquired company was a scrappy startup, and perhaps they didn’t care about safety at all because they were just in market acquisition. And so the CEO says, well, they’re actually viewed very unfavorably on the safety meter. And that’s causing our regulators to look at us and say well, we’ve done some work … Right, right! You’ve done some good work for two years on this safety thing. But what … what’s with this? Like this is one of the most unsafe platforms in the world and they now belong to you. What are you going to do about it?,
And so the CEO says we got to do something real quickly about it. And the first thing we have to do is, in all of our jurisdictions, we have this concept of ” share a ride” so a loved one or a trusted person can follow you along in your ride and know that you’re being safely carried somewhere and not being driven off somewhere else. And so, he says, we have to have that ASAP in this new platform. And, not only do we have to have it ASAP, there’s a lot of things that we’ve thought about with “share your ride”. Perhaps it’s around how often we ping. Perhaps it’s around how you bring your contacts in and who’s a trusted contact. And maybe there’s auto sharing because, you know, you put a contact in as your trusted contact and every ride gets shared with them. Or only rides after 9 p.m. or when the system thinks it’s unsafe. And all of that has to go in. It can’t be seen by the regulators as a one off thing that’s just there to placate them. It has to be real.
How does that happen? I mean, you’ve written all of this shared ride code in another code base that uses other technology and you’ve explicitly decided not to integrate these two companies. So what do you do here?
Andy: We now have these cross-cutting concerns, as we talk about in software. Do you remember the time of, what is it? Aspect-oriented programming?
Mon-Chaio: I do. Yes.
Andy: It was an attempt to address this kind of a concern going across your code base, which is how do you handle that across things that are all going to be different, you have these common concerns that you want to have some sort of central control over. The classic example in AOP was authentication: how do you make sure that authentication is handled correctly at all the places that it’s going to need to be handled?
And, if we think through that as a framework, I’m wondering does this get us to something about what we could do here? In thinking that we’ve got this kind of federated system, does AOP give us a way of dealing with this? I think AOP might, because AOP kind of says there’s this thing that gets injected into all the points that matter, that then has kind of an overriding control when needed.
So it can intercept the flow and change what’s happening. And what we’re saying is that we have this cross-cutting concern of rider safety. It might need to be done a little differently all over the place, but we want to pull it together somehow.
Mon-Chaio: Mm hmm.
Andy: And so we might have our first case of having to pull the people out of their independent shell a little bit.
Mon-Chaio: Mmm hmm.
Andy: And we need to think about how to do that in a way that preserves their autonomy in all other aspects except this one. So I would say that you would have a group that is about this cross cutting concern, and they would then be working with kind of the group in the other team, in the other company. But the key part is that group can’t really be part of either group,
Mon-Chaio: Mm hmm.
Andy: Because they’re this cross-cutting concern group.
So I would say that it has to be combined as well with how do you, to take the analogy even further, how do you then inject them into the system? AOP was full of these whole, like, languages for how do you select points in the system at which you’re going to intercept.
Mon-Chaio: Right.
Andy: And I would say that , to me, that would take us back to the briefing/backbriefing. If we’ve already got these cultural touch points in place, we’ve already got these discussions about what are we doing and all of these things, you’ve already put in place a structure where you can … maybe it wasn’t used for that yet, but now you can start using it for that, of the briefing/backbriefing. And you can start with the briefing of we’ve got this safety mandate, we have concerns that will cause us major issues if they’re not addressed. We have this cross-cutting team that we’re gonna set up, and our brief to you is that we need this thing in place working to the level that this team guides us toward in the next two months or whatever.
Mon-Chaio: Mm hmm.
Andy: How are you going to do it? And you kind of set up that constraint. You set up that structure and you say, you’re fairly independent, but we’ve got this cross-cutting concern. We’ve got this group to coordinate it. How are you going to deal with this?
Mon-Chaio: I think I disagree with you Andy.
Andy: You disagree with me? Okay.
Mon-Chaio: I like that you brought up aspect oriented programming. I hadn’t thought about it that way before. It would certainly be nice if people were as injectable as code, and organizations were as modifiable as simply, here’s a API endpoint to do aspect injection. So, in this hypothetical example, the types of behaviors I’ve seen are the briefing that the safety concern is really important. And then this AAA team saying, I hear you. I hear you and we’re going to put it on our roadmap, but one, you don’t get to tell us when you want it done because our roadmap is ours to prioritize. And two, we’ve been operating in this region for so long. What are you telling us about what we need to know about this region? We’ve been able to grow without it and we’re going to grow and we’re going to continue to grow. So thank you for telling us about the safety thing that we knew about and we will do it, but …
Andy: But it’s not now.
Mon-Chaio: It’s not now or maybe it’s not to the level of fit and finish that you want, that sort of a thing. And I think the reason for that is that these are two separate groups. You’re interacting with this company as if they were still a separate company. They have their own roadmap. They have their own models of thinking. They have their own way of thinking about the problem. And so here, Andy, is the first point at which I think integration has to start happening
Andy: Absolutely. Absolutely.
Mon-Chaio: Right, because, remember, the reason we said not to integrate was because you didn’t know what was the same and what was different. And that’s in terms of culture, that’s in terms of technology, that’s in terms of process. Here is something that is so central to your company, this safety mandate, this safety image, that needs to be across both companies.
And so whatever that point is, it needs to integrate. Having a group that’s not part of one or the other that handles rider safety, I think is a good step, but I think it needs to be bigger than that. And I don’t think that group can have influence just in terms of, hey, here’s the KPIs we need you to meet, figure out how to do it. I think it’s got to be stronger than that. And I think the integration has to be deeper than that
Andy: Okay. I was thinking it was beyond KPIs. I was actually thinking it was more like the actual product management of it. But yeah, I can see that. Basically, it’s indicating that there is a platform that needs to be here, that has to be mandated to be integrated everywhere and used everywhere.
Mon-Chaio: Right, and I think this is probably the first one platform and so now both sides have to figure out how to make this happen. The acquired company needs to figure out, okay, do we transition our technology onto this other tech stack so that we can consume their code? The acquirer, they have to figure out do we port this code somehow? But then how do we keep it in sync with all of our other products and how do we keep the experience the same? But that integration needs to start happening. And honestly, I think that these are the types of things that you need to be the leaders, the vanguard of how you integrate, because integration just for integration sake sounds great for efficiency and for cost and for people getting to know each other and all of that, but having real problems that are not invented and that are not small, that actually drives you to figure out where is the most important points to integrate and how you should go about it.
And maybe this one small, super important problem is the one that says they’re going to scrap their entire app and rewrite it on your app framework. It could be. But maybe it’s not. But like using that as the focal point to make those types of decisions instead of simply making them based on, oh, well, eventually we want the apps integrated and like, it’s important for our brand to look the same, it is much more powerful and I think much more effective.
Andy: Yeah, I think I agree with that, and I don’t necessarily see what we’ve both said is incompatible.
Mon-Chaio: Mmm, yeah.
Andy: The way I think about it is that you’re thinking that at this point, there’s actually many more constraints given in the briefing.
Mon-Chaio: Mm hmm.
Andy: Things like, no, you need to use the platform we’ve already put together because there’s so much embedded knowledge in that. We’re not recreating it. It’s not the direction we’re taking the system. You’re going to do an assessment about what the appropriate long-term approach is for maintaining this , but you’re not the final decision makers on what the approach is, it’s the team that maintains this common platform makes that final determination, something like that.
Mon-Chaio: Right. And this is the point where I think the leadership from the original company now has a very difficult balance to make. The leadership from the original company had it pretty easy at the beginning because they were separate. They were basically doing the things that they already did, and did well.
Andy: Mmm hmm.
Mon-Chaio: As soon as you start making these deep integrations, perhaps … like let’s say they decide that they’re not going to have the app anymore and they’re going to rewrite on your app platform., Now it probably makes sense for at least that portion of their team to roll into the Rider sphere in one of your three large pillars. The Rider/Driver/Platform pillar, right now part of the Rider pillar.
Senior leadership doesn’t really move that way. You no longer have a second VP of Rider, do you? Like, you don’t have like a VP of Rider in this particular jurisdiction. And so now I think is the time that as the CTO, you also have to realize that as you integrate, what does it mean for that sort of senior leadership on the other side?
Andy: Yeah, or senior leadership on your side. You could look at them and be like, their people are better.
Mon-Chaio: Exactly. Exactly. You’re absolutely right. It could be either or. The challenge on the other side is you actually have to manage them more directly because they’re your touch points with the people. On your side, you have touch points with your people too, and they have relationships all around your existing company.
On the other side, your touch points to those people are through senior leadership. And so if you start to deliver bad news, then morale could tank and people could leave. And I think that’s also part of the reason why keeping them separate is so effective at the beginning. But when and if you have to integrate, that’s something to watch out for as well.
Andy: I think that’s gone through and I can’t think of anything else. Where else do we take this?
Mon-Chaio: I don’t know. I think this is pretty good.
Andy: I think that might be it.
Mon-Chaio: Okay. We’ve taken this hypothetical company now from three people in a garage all the way through this global company that’s doing acquisitions of smaller startups. Hopefully this has given all of you listeners a flavor of what we think about and how we think about scaling. And as unfair as it is to say with these named scaling frameworks, Andy, which I will not name here, I named them all the time, the nuances around how to do this goes way beyond simply taking what you have and creating a scrum of scrums or deciding which parts of your roadmap fit where, it is much more nuanced than that.
And it depends on the stage of your company, the problems that you’re facing, the people that you have, the industry that you’re in. And so that’s why we say most scaling ends up failing, is because it’s so rigid and it doesn’t take these nuances into account.
Anything else you want to add? Our last word about scaling or our last word in this set of episodes?
Andy: I think you summarized it pretty well right there. The issues of scaling are so much more than just what is your software development process and how do you get 50 product managers to come up with a plan? I think one of the things that we’ve said in here is you organize so that you don’t have to do that.
Mon-Chaio: Yes!
Andy: And as much as we were saying at the end here, you’re going to start pulling this together, I think you should still be working on how do you still keep this group small and separate? I think the general principles of keep autonomous groups to about Dunbar’s Number, think about those scaling factors, that 3x factor that we talked about in the Dunbar’s Number episode. Keep all of that in mind, and you’ll do much better than if you just say, how do we work when we’re big?
Mon-Chaio: And a big one that I harp on a lot is you have these autonomous groups that are Dunbar’s Number. That means giving them autonomy. So you might ask yourself, well, doesn’t that just result in chaos? If I just give them autonomy, everybody’s working in a different methodology. They have different release trains. They have different systems on which they track their work It could if you do it wrong. But what controls that, oddly enough, is not process. It’s culture. And strategy. And if you do a good job with culture and strategy, you’re gonna be able to have autonomous groups that do different things, but are able to come together strongly as one.
Andy: And react as the context changes. Because one of the things about if you do it on process, is you struggle to change, which, hey, that isn’t agile.
Mon-Chaio: So, I think that’s a great place to end it. We started five episodes ago talking about how scaling wasn’t a one VacationCast ten-minute episode. I’ll end with saying talking about scaling isn’t five 40-minute episodes either. There’s a lot more to talk about. We ended by talking about how important culture is. I mentioned earlier, we have a three-part culture series in season one. There’s way more to talk about there as well.
If you would like to engage us in those types of conversations, we would love it. We live for these types of things. So reach out to us: hosts@thettlpodcast.com. That’s ‘hosts’ with an ‘s’. Whether you’re an individual or company, anything you need help with, let us know how we can help you; reach out to us! Also, if you enjoyed this series, if you enjoyed this episode, recommend us to a friend, rate us on your favorite podcatching platforms. We really appreciate word of mouth. We really appreciate people who like to listen to us. And even if they don’t agree with us, we still appreciate you listeners listening and helping us grow through your comments and feedback.
All right, folks! Until next time, be kind and stay curious.
Leave a Reply