Edu: Cross-Functional Squads - Critical Org Chart Mistakes To Avoid

Chris: Hey, I'm Chris.

Yaniv: And I am Yaniv. And in today's episode, we're going to talk about the misunderstood concept of squads. Ever since Spotify popularized the term nearly a decade ago, tech companies everywhere have been falling over each other to organize themselves into so-called squads. But often they have no idea of what a squad truly is.

So of course, they don't get the results that they're hoping for today. Chris and I are going to dive deep into the deeper principles underlying autonomous squads, so you can avoid falling into the trap of creating an organizational structure that you don't truly understand.

Chris: Yeah, that's right, Yaniv. And so, these are often referred to as cross functional squads, cross functional teams, Program teams, it's often referred to as the Spotify model. it's not really the Spotify model. they just popularized it a little bit with some marketing about the way their culture works. and this is the idea that you have not just one big engineering team and one big product team and one big marketing team and they kind of sit in their little silos and they work together across these silos.

But rather that you create these teams of A product manager, a group of engineers, an eng manager, a product marketer, a designer, a data scientist, and they all fit together, working on a specific mission together. we'll dig into exactly what all that means shortly. but just very quickly on why you would do this.

This is great for scale ups. It's great for companies with an evolving and growing surface area of products, initiatives, business goals, and so on. And it allows a kind of high bandwidth connection between all of the people, all of the functions required to achieve a mission within the business. And it reduces the sense of like tribes and us versus them and low bandwidth connectivity Most importantly, it reduces resource contention, where you have the product team begging for something and the biz dev team begging for something and the leadership team begging for something like a bunch of, three or four year olds running around the soccer field just chasing the ball trying to figure out which ball to kick and where. And so it gives them lot more structure and a lattice in which to organize whole company around missions and around thoughtful, resourcing thoughtful, planning.

Yaniv: I don't disagree with anything you said, Chris, but I actually think you've missed the most important reason to do squads, which is really to allow an organization, especially a growing organization, to be more adaptable and more agile in a context of uncertainty Squads and agile principles are actually quite closely aligned because the underlying environment that gave birth to both and the principles behind both are kind of the same. And they're the same as a lot of the things we talk about in this podcast, when there is a high degree of uncertainty, what you want to do is avoid the false precision of having a highly centralized, really complex, really detailed plan and pretending you're just going to be able to roll it out, right? Because the terrain is complex, there is uncertainty. And so what you wanna do is have groups of people who are able to adapt to the local conditions around them, which is like, you know, if you are.

Owning a particular part of the business. You're learning new things all the time and you're actually able to adapt and learn. And the people who understand most about their local environment are the ones who are then making the decisions about how they're going to succeed. and you know, this is actually An interesting parallel with military doctrine and how it's evolved over the 20th and 21st century. Now I'm, far from a military expert, I've read a few books, so, no, just enough to be dangerous. And I think militaries have gone, especially when moving from the battlefield set pieces that used to happen in the old days through to World War I, world War II and into the modern warfare.

The level of complexity of what's happening means that the sort of top down general just sort of moves the pieces around the board. That doesn't work anymore. Modern militaries are highly, delegating, The idea to be successful, to move quickly, they need to be able to actually dive in.

And each little group needs to know what their mission is, but how they execute the mission, well, that's gonna depend on what they encounter on the ground, and they don't know what they're going to encounter on the ground. By the way, highly recommend reading the book Team of Teams by General Stanley McChrystal, because that really talks about, a lot of this but Just to sort of wrap up, what I'm saying with a bow when would you even use squads? Why do squads exist? It is because you are operating in an environment of high uncertainty, and you need to be able to operate effectively when you actually dunno the terrain that you're going to encounter.

Chris: Yeah, that's right. But I would say, you know, in today's, business and, geopolitical environment, every company is operating in high uncertainty, I would say this is a great operating model when you have a medium to large surface area that is growing, and that business is operating in an uncertain environment.

And that is true of most medium to large companies. and scale ups. And so the squads model, I think, works very well for many medium to large companies and should really be considered. But as you said, Yaniv, at the beginning, find a lot of people really don't understand them or don't understand the deeper principles that make them work.

And so in today's episode, we really want to dig into key principles that make squads really work. without further ado, let's dive into those principles. the first one we've got here on our, run sheet is missions, not projects. a common mistake you'll find with companies trying to, adopt the squads model is to, create a squad for a project, like, let's build a proof of concept for a customer, for example. And, these squads kind of come together for a short, sharp goal, and then are disbanded once that goal is met. but that's actually not the way squads are intended to be used. The intention for squads is that they have long lived missions that would last, I would say, a minimum of 12 months, but more likely two, three, four years.

And so those missions might be something like Solve for user onboarding. Solve for billing and accounts. Solve for discovery. Solve for sharing and collaboration. And so, over the course of multiple sharing and collaboration features, you know, it might be just deep linking, inviting, multi user features, live updates, notifications, activity feeds.

this is a whole constellation of features and maneuvers. that are in the category of sharing and collaboration. And this squad would own devising, building a roadmap for and building those things and along the way, listening carefully to users, running experiments, learning, iterating, and adjusting.

And so you can see that a squad would have really just a huge roadmap of things that they would execute over a longer period of time.

Yaniv: Most importantly, Chris, you just mentioned at the end a huge roadmap of things, but where does the roadmap come from? The roadmap comes from the squad itself. I know we're gonna talk about autonomous a little bit later on, right. but when we talk about missions, not projects, your leadership style needs to change, right? the context that you need to give your team is very different. You're not saying you are responsible for building thing X. Here are the requirements.

One of the reasons that these things don't succeed is because you still don't say, oh, okay. It's my job now as a leader to explain to people what their mission is. And I think that's really important here, that the planning that happens at the leadership level has to change quite a lot from.

Let's come up with this detailed project roadmap to let's come up with a well articulated and well-defined mission for each of these squads.

Chris: Yeah, it forces you to actually really think through what your business architecture is as well. Like, what are we actually doing? What are the organs of the business? What are the initiatives of the business? And how do we think about those initiatives? And, a lot of time I spend with scale ups is actually helping them rethink their org chart from reporting lines, who reports to who, and more about a functional map of what is the business trying to achieve? What are its hearts and lungs and arms and legs? And, how do you staff and resource against those? And how do you create missions for each of those? Now, there's a few really important gotchas that I've noticed that very work of working with scale ups that are very intuitive, but are very wrong.

I'll often see, people trying to design a squad map. create one of three very bad squad types. The first is an innovation squad, the second is a catch all squad, and the third is an agency squad. The innovation squad squad where you're like, well, that team over there, they're the innovators.

They do all the innovation stuff. And that is like, just not the way you're supposed to do it. The idea is, especially in a Silicon Valley style scale up, is that every part of the business is innovating. If you define innovation as doing things faster, better, cheaper, and thinking from first principles.

Well, every part of the company should be figuring out how to do things faster, better, cheaper, And so having an innovation squad is a little bit antithetical to that. And worse, they'll tend to build some experimental stuff and throw it over the fence to someone else where there's no emotional buy in, there's no follow through, there's no commercialization and productization.

And so you want to avoid innovation squads.

Yaniv: Like to say, Chris, that the number of times the word innovation is used in an organization is inversely correlated with the amount of innovation that actually happens there.

Chris: Yes, exactly, exactly. And closely related to the second bad kind of squad. Which is the catch all squad. Which is like, those guys are the skunk work squad or the special ops squad the architecture squad, right? And their job is to solve all special projects.

That's not really a mission. That is a catch all and that squad will just get overloaded and we'll get a bunch of stuff thrown at them and they'll end up with this massive resource contention of the kind we described at the beginning of the episode. And so you really want to have... Missions that are broad enough that they would last multiple years, but specific enough that the boundary conditions are clear and their scope of inquiry, their scope of interest, is also very clear.

and then the last one, which is related again to the first two, is the agency squad, where the squad starts to act. like an agency instead of like a developer of tools and products. So it's like, again, these are the architecture squads. So all the other squads are going to rely on the architecture squad to design and help them build their architecture.

That is bad, bad, bad. And we're going to dig in little further down about the autonomy of squads and how they should have as much decoupling as possible. But squad's goal should be to not provide services to other squads. It should be to build almost self serve tools, technologies, patterns, principles, and products, product features and products that enable other squads and other users to get value without ever having to talk to them.

Yaniv: Yeah, look, I mostly agree. I feel slightly defensive because I did once create an architecture squad, but, actually I, will sort of talk about this because it illustrates the nuance and I think, you know, if you talk to Spotify, Folks, they've talked publicly about how the original Spotify model has perhaps evolved a little bit.

Not every squad has to be customer facing, has to be user facing. Some squads are there to serve and enable the rest of the organization. But let me tell you about the architecture squad that I created and why I think it was not an anti-patent. and it shows the subtlety here, right? So the architecture squad that we had at Airtasker, their job wasn't to.

Like go build things for other teams, right? They were there to look at the holistic architecture of our infrastructure, identify bottlenecks, weak spots, areas of technical debt, and basically re-architect them so that the whole rest of the organization could become more efficient. So in other words, they weren't like an agency.

Now they had a clear mission, right? Which was effectively to retire technical debt and to make our architecture more flexible and more adaptable. And they own their own roadmap. And so there is subtlety here. And, the reason I bring that up apart from to absolve myself of sin, Chris, is that, you know, it goes back to, to the initial point here, right?

Which is the difference between. Having real squads and fake squads. It's like having real agile and fake agile it's not in the names you give things, it's in the underlying principles of how you run the organization. and so you can have an architecture squad that is a total anti-patent or an architecture squad that is very much in line with the squad model, but it depends how they operate.

Chris: It really does depend on the intent and the way the squads functioning.

In the case of this kind of squad. that's building, architectural pieces for the company. The ideal world is to have what you might think of as the platform group, which is set of squads whose customers are internal teams. But they're not customers in the sense that they're agencies, they're customers in the sense those squads are building tools and principles and products that are consumed then by internal teams.

And that those squads in the platform group themselves have very clear names. For example, data persistence and message queues squad or the payment gateways and integrations squad. And so, yes, they're working on architectural pieces. They're working on pieces that are below the fold, if you will, not touching users directly, but they're working on a very particular kind of platform component or architecture, architecture in general.

Now, this really depends on your funding and your resourcing and all this kind of stuff. But that is the ideal is that you try to give them a particular mission within the platform layer of the business.

Yaniv: Yeah. The only thing I'd say, and maybe we come back to this, is having been on the receiving end of, these sorts of principles and advice as well, is it's like, yes, ideally use the word ideally. And I think what I found is I. When you try to adhere to this along the lines of ideals, you'll always find places where it just doesn't quite work.

There is an element of pragmatism. I think we're laying out the principles and perhaps yes, the ideal, but the world gets a little bit messy and I found that there are usually times when you do deviate from that ideal, in the real world.

Chris: Careful, Yaniv, you might sound like a grown up.

Squad design will help you not only make the right compromises, but also remember the compromises you made, such that when you notice some dysfunction occurring in that area of the map, you can go, well yeah, of course those guys are struggling because they're sharing a PM between two squads, or because the platform squad is a bit overloaded and we need to break it into multiple individual squads.

And so, a good squad... map or a good org design will help you understand and remember, most importantly, remember where your compromises are and why some of the dysfunction might be kind of bubbling up from that part of the org over time.

So the next, principle here is that squads are cross functional and diverse. Now this might be obvious, right, it's in the name, cross functional squads, but To be very, very clear, and we'll probably touch on this very lightly, a squad is made up of multiple functions. Product manager, engineers, designers, data science, product marketing.

You really want everybody in the squad. That the squad needs to succeed and so there is a common mix of people in the squad But depending on what the squad is doing you might change some people out or add some people in a good example of adding people in is that uber example was very ops heavy There was a huge ops org that had to touch the real world in a lot of very important ways And so uber basically invented a role called prod ops product ops where there would be a representative from the ops team who kind of got promoted to HQ, got promoted to the R& D team, who was very in tune with what the operations team needed and could be the voice of operations for a given squad.

And then when the squad was about to ship or ship to new product changes, could communicate those changes back to the ops team. And so when I say diverse, I mean you need to consider all of the functions required for that squad to be autonomous and effective without relying too much on other support functions in other departments.

Yaniv: It's interesting. Quite often the cross-functional nature of the squad is sometimes called the triad of the stool, and it tends to be archetypically the. Product manager, the engineering leader, and the product designer. And at Airtasker, wanna popularize this term and maybe this podcast can be the way to do it.

We moved away from calling them triads with that implication of three to a hydra, know, we said many heads, one heart. And that heart is that one mission, And the point there is the cross-functional aspect of it is actually flexible, it should be. Adapted to the needs of the squad.

What functions does it require inside it in order to be effective? Now, there's a reason why product management, product design and engineering tend to be in there, as sort of elevated, but I think it's unnecessarily rigid to think of it as always being those three and only those three as being the core members of any given squad.

Chris: That's right,

Yaniv: So the next principle about squads is they should be autonomous, but aligned. And this goes back very closely to our first point about missions and not projects, We're saying instead of having a squad that is told what to do, And what is their roadmap and what are their deadlines and so on.

We want to give them empowerment. We wanna say, this is not what you have to do, but this is what you have to achieve. And that's the mission. And the mission doesn't just need to be, and shouldn't just be like an airy fairy, vague statement. You can have. Clear metrics and goals within that mission, but the point is it's more outcome driven.

Now, the reason for that is we want the squad who are best placed to understand all the nuances of what they're building and the environment in which they're operating to make the decisions about what to do. that means they need to be autonomous and empowered. in order to be able to iterate quickly, they need to be able to understand their users, understand their infrastructure, understand the whole area that they're operating in, and then say, okay, in order to achieve our mission, knowing what we know, and we know more than leadership because we're in this shit all day, every day in order to achieve what we need to achieve our mission. These are the things we should do.

In other words, the squad determines its own roadmap. It is held accountable not by its roadmap and deadlines, but rather by achieving the outcomes that are aligned with their mission.

And another way of thinking about this, Chris, is that in a sense, the contract between the team and the organization changes fundamentally from. This is the roadmap that we are going to deliver to. This is the outcome that we're going to deliver, right? And we'll talk about accountability later, but, this is the fundamental, most profound change.

Now, as a leader, I've had situations where a team's like wanted to do something and I said, no, you shouldn't be doing that. And they're like, wait, but I'm supposed to be autonomous and empowered, so why are you not letting me do the thing that I wanna do? this comes down to we said autonomous but aligned.

We are not running an anarchy. We're not running chaos. an organization is still fundamentally a somewhat hierarchical, top-down organizational. Structure. The question is how do things actually operate day to day? the role of leadership here is now to create alignment, to drive alignment, to share context, so that the teams are able to make the right decisions.

Autonomy doesn't mean free for all. Autonomy means I. The freedom to make the right decisions and the right choices in an aligned context. And Chris, we have a whole episode on alignment. folks, I really recommend listening to that one. It's actually in a lot of ways, one of our most important episodes, but that is the contract here, right?

We have alignment around mission and outcomes and autonomy in the choices made to execute against that mission.

Chris: To be very pragmatic about that, like how does that alignment work? And it certainly works, based on the business providing clear context about the goals for that cycle and having a great planning process. But day to day, the alignment is maintained through the group leadership.

So squads are often organized into groups if there's enough of them. And so there might be the demand side group and the supply side group those groups have group leaders, a group product manager, a group engineering manager, and so on.

Those group leaders perform the function of keeping the squads aligned with each other and with a broader mission. there's also another form of alignment, which is that the squads. need to talk to each other. They can't be kind of in a foxhole, hunkered down and blind to the rest of the world.

And so it applies more pressure. raises the bar on product managers and engineering managers to encourage. They're engineers stakeholders in the squad to talk to their functional peers in other squads and also for the product manager and the engineering manager to talk to their peers in other squads.

And so if you have an upcoming thing you want to achieve and it might affect or bump into or involve another squad. The product manager should go talk to the product manager of that other squad and go, Hey, Sally, like we're thinking of doing this and that. What do you think? We know you've been playing in this area.

The engine manager would go, Hey, you know, my engineers are about to come to you to talk to you about this or that, you know, keep an eye out for this or this, we need to collaborate or coordinate on that. And so these squads need to have a really healthy culture of setting up conversations with each other when and if their spheres of influence might overlap just a little bit.

Which is a good segue to the next principle, actually, which is collaborative but not blocking. these squads, we've been talking about how they have a mission. that mission tends to align with a set of surfaces inside the product, and or a set of microservices, right, a set of actual running code that has been built.

And the key here is that they don't. Own it. They don't own the microservice, they don't own the mission. They shepherd the mission. And what that means very pragmatically is that they're not allowed to block others. they're there to nurture the microservice. They're there to nurture that surface area of the product.

But other squads may have something to contribute to that part of the product. And. They should be welcomed with open arms to come and have a conversation with that squad, with the PMs talking to the PMs, and the EMs talking to the EMs, and engineers talking to engineers. to be empowered to make the changes they need to make.

Yaniv: That level of ownership, doesn't make the squad the gatekeeper, right? It makes them an owner and a facilitator and a key stakeholder. But this is not something where you say, okay, you know, I, I own this screen and therefore everything has to go through me.

The last thing you want is like these little fiefdoms. Across different parts of the product that say, no, everything has to go through me and no one else gets to do stuff. I do think that there are points where squads do kind of have to be gatekeepers.

Like, you know, if, we're talking about the squad that owns the homepage and everybody wants their stuff on the homepage, then. that squad does need to, in alignment with their mission, exercise a degree of control over what appears there. But I think the point you're making Chris, which I agree with, is that the squad's job isn't to like wrap their arms around something and keep everyone else out, but to be an excellent custodian of that thing so that all the other functions, all the other squads, with their missions are able to use That stuff that your squad owns as a resource to help them achieve their missions more effectively. Because ultimately, you do not wanna ship your org chart. Your customers see one product, one company, and that needs to be very much part of the way that different squads work together.

Chris: Okay, so the next principle is supported by service leadership and escalation.

Now, Yaniv, we had an entire episode about service leadership and escalation, and so I would recommend for the audience to go check that out. It was I think, one of our best episodes and really one of our most important episodes. But to summarize very quickly here, creating squads for your organization can be a form of creating lots and lots of silos if those squads are not coordinating and collaborating as we've just discussed. And if they are not led by strong service leadership in a culture of escalation. And so you can imagine two product managers, each in a different squad, each with different priorities and each with different levels of context for what they're trying to achieve.

They might have a very well meaning disagreement. about how to affect that home page, as you just touched on, Yaniv, one of them is shepherding the home page, they're the custodian of the home page, the other has an OKR to really move their numbers and they think the main way to do that is to change the home page, and there is a kind of conflict or contention there.

Well, it's very important in those cases, and those cases will occur quite frequently, part of business as usual, that those two product managers escalate to their group product manager or to some higher authority to figure out what the right business trade off is.

And so it is role of leadership in this case to be of service, to help understand both perspectives, the trade offs, and so on, and to provide more context. And to ultimately, perhaps, make an executive decision. Say, yep, we can see the tension there. Here's a way to split the difference, or here's a way to adjust your thinking, or no, ultimately we have to protect the homepage and that bit of surface area for this reason.

And so this is about resolving well meaning, reasonable, differences of perspective and opinion, and having a regular cadence of escalation where those trade offs need to be made by some kind of higher authority.

Yaniv: Like you said, we've got a whole episode of this, so we don't, need to be diving too deep. But the point here is, you know, I don't, like sort of the fake humble, the upside down pyramid. I'm, a servant leader. think the hierarchy is still, the hierarchy and leadership still has authority and power and should wield it wisely.

I think the point about this is what, Is leadership trying to achieve in wielding that power, And here it is really about unblocking teams and allowing them to be effective, not telling them what to do, not kind of standing on their neck and giving them a hard time, saying, what do you need to be effective so that I can hold you accountable for your success.

And then it is your job to unblock that and make that happen. And that is how you as a leader are able to have a multiplier effect on all of your teams because you are allowing them. To do their job effectively, and that gives you the moral authority to hold them accountable to achieving their mission.

Now the next point, Chris, I think is a really interesting one, is to strive for consistent outcomes with functions. Now, what do you mean by this one? I think this one's a bit less obvious.

Chris: Yeah, so the idea here is that you have these individual squads, they're acting with their own autonomy, they're empowered to get what's done, what they need to get done. But again, There is a risk that these become silos, right? The engineers in one squad start to behave very, very differently than the engineers in another squad.

Product principles in one squad can start to become very different in another squad. And so what's really important, again, as part of this service leadership, is for the function leaders, the product leadership, the engineering leadership, to create Common principles, common ways of thinking, and common rituals, meetings, and meetups, and off sites for them to develop a function wide view, a business wide view of how product is done.

At the company or how engineering is done. What are our priorities for engineering? we elevate security above all things? Or do we just look for a certain level of security? Do we look for zero technical debt? Or do we accept technical debt under these circumstances? Are we looking for 0 percent downtime?

Or are we happy to live with, you know, three nines? are we doing a microservices architecture? Or do we want to build a monolith? How do we create some kind of consistency across the function, both with principles, patterns, performance rubrics, and, a regular cadence of everybody in that function getting together to break down those barriers between squads.

Yaniv: Yeah, I believe in the Spotify model, they're called these things guilds, right? There's this idea that When you ask a person in this structure, what is your team?

What team are you on? This is a really interesting tell. They should say, I am on the onboarding team, right? They should identify with their cross-functional squad as the team that they work with every day as their people, But they're also still an engineer or a product manager or a product designer, and they have a craft and they report to someone in their function who is responsible for that overall craft and the effectiveness and the consistency of the application of that craft.

And so, while you have the sort of organizing principle of the squad is the most important unit, reporting lines go functionally. And then you have things called guilds or whatever you wanna call them. we call them schools at Airtasker. but the idea is this is a, community of practice where you get together with your fellow front end engineers or with your fellow product designers and you say, this is how we do things.

These are our norms. These are our processes. This is what good looks like. These are the trade-offs we make. This is how we work and collaborate with our cross-functional peers and so on. And that's actually a really important part of the mix here, right?

Because I don't see this as a matrix. Reporting structure matrix reporting is when you basically have two managers, right?

You report to like your functional lead and your cross-functional lead. And I think that's actually really messed up and I hate that. This is, you are a part of a cross-functional group that is your team. That is actually the primary unit of accountability to the business is within your cross-functional team, But then there is a level of accountability to your craft and how you execute your craft. That is where you go into this. Functional structure. So these are rather than matrices where you're pulling in two opposite directions, it's the functional structure is actually there to support the cross-functional organizing principle.

Chris: So the next principle we have here, and the second last one is funded by the business.

So for me, one of the most important parts of squads is that it unearths under investment by the business. Because I'll often meet scale ups who have this amorphous engineering team, and amorphous product team, and amorphous design team. And they're like, why are things not moving faster, Chris?

And like, what's going on? And why can't these guys get the job done? We have so many more engineers than we had before. And why is it still going so slowly? And the answer is, sometimes, often, that they've under invested. In the team, they have like five or seven or ten engineers and they have like 30 engineers worth of work and there's this massive resource contention and then it's all buried in the engineering team, right?

And so when you break the org into a series of squads with a series of missions, what becomes very apparent very quickly is like, wow, we have a lot of missions and we do not have enough people and we need to understand how to properly resource this organization. what that suggests also is that the most important lever that the leadership team has is to choose what the business is doing and how funding is allocated.

And so when the business has a new idea, has a new initiative, has a new bet, has a new business that it wants to pursue, it needs to understand that it needs to create a corresponding squad or squads in order to support that new initiative. so therefore squads are funded by the business, they are created by the business, and they're right sized, or the investment is right sized, depending on how important that particular mission is to the business.

And that is the main lever by which the business maintains a kind of degree of direct control over the squad structure. Because often also when I talk about squads to scale ups, they're like, well, Chris, How do we control what the hell's going on and the investment's being made? And the answer is, you control along with your chief product officer, chief technology officer, the creation of these squads, the missions of these squads, and the investment, the funding, and the headcount for these squads.

the other nice thing about it is that the squads can actually help with hiring. So if you give the squad a headcount of five or ten people, and they only have three or four, Well, they can help you. The engine manager, the product manager, the designer can go and help hire and flesh out their squad.

And that is another thing is often I'll hear like, well, we don't have enough people yet for full squads. And I will say to scale up, actually, you should still create the squads. highlight the resource gaps, and then empower the squads with headcount, with budget, to go and fill in their own blanks.

And that helps accelerate hiring, it helps, get people excited about the role of hiring, and it helps, bring people in for a mission, for a very concrete mission. They understand who their colleagues are, they understand the work they're going to be doing, and helps distribute hiring and growth across the entire organization, while maintaining alignment with those missions.

Yaniv: I've actually got a little tactic that I've employed that I think works quite well. you may or may not agree with this, which is, we used to call it bloat and split, right? Because I think creating a squad that's can be really problematic and forcing them to hire externally can mean.

You end up with a squad that doesn't have a lot of context around how the company works. So sometimes what we would do is we would temporarily, we would take an existing squad, we would load another mission on them and we would say, it is your job to grow to the point where we can then split you in two.

So it's a bit of a sort of cell mitosis type of structure and, that actually worked pretty well as long as you made sure that you moved through that process relatively quickly.

Chris: It's so funny that you used a medical term There because I'm actually working with a healthcare company right now, and we've been calling it nucleating. You like to say, you kind of the cells, right, exactly. And so, I think you can do bloat and split, I think you can do, what we used to call at Uber, a minimum landing party.

So you can, cannibalize a few squads and create a new squad with a new mission, which is underfunded. and the other squads have to try to, backfill their roles, and the new squad tries to flesh out themselves. I don't have a strong opinion about which one I like better.

I think the nucleation, the bloat split model is actually a pretty good one because you're kind of like, educating everybody on the problem and then you break them out.

I think in both cases, though, point is very important, Yaniv, which is you don't want to do this, unintentionally. You don't want to bloat a squad unintentionally. And you want to always come back and make sure you split it. And you don't want to create an underfunded squad. Unintentionally and leave it underfunded.

You want to always be right sizing and properly funding the squads to the degree possible.

Alright, And now the final principle,

Yaniv: And the most important one.

Chris: The most important one is that these squads are ultimately accountable for outcomes, right? They're certainly accountable for their mission, but on a quarterly basis, a half basis, where you have a planning cycle, probably using OKRs, you want to make sure that these squads are achieving the specific objectives and key results that are aligned with their mission.

And along the way, you don't want to wait until the end of the quarter or the end of the half. You want to be checking in with them. At Uber, we used to call them business reviews. You might call them squad reviews. Every week, every two weeks, the immediate leadership of that squad should be checking in and understanding how well the squad is doing and holding their feet to the fire making sure they're achieving their near term OKRs or their goals and their medium to long term mission.

Yaniv: I touched on this before and, I think to me, this is the simplest and hardest and most important aspect of all of this. This is the foundation upon which everything else we've talked. Rests Chris, because it, is a change to the leadership culture, to the leadership operating system of the organization, You are accountable for outcomes. You are not accountable for outputs, So I. I think the difference between a proper squad and a, kind of a faux squad. A mock squad is whether you say, okay, how do you hold them accountable or, the phrase that I often use, like I said before, is, what is the contract between that squad and their leadership team is the contract.

You have to ship this thing by this date and that thing by that date, or is the contract, this is the outcome you need to drive. These are the metrics we need to move you figure out. How to do that. The incentives structure within an organization, the accountability structure is ultimately going to drive people's decisions and choices in how they operate.

And so the leadership team needs to get comfortable with saying, I'm going to hold squads accountable for outcomes and not for what they deliver. but we also talk about regular business reviews here. And so what this means is just because a squad is autonomous and accountable for outcomes, it doesn't mean that leadership.

Shouldn't be kept abreast of what's happening. And it also doesn't mean that the squad shouldn't need to justify their thinking and their reasoning and accept feedback from leadership. Right? Autonomy is not complete, This is not black or white. The idea is the squad is leading the decisioning, the reporting back to leadership who can review it, provide feedback occasionally, but hopefully only very rarely override the squad's decisions and talk about how things are going at a business level.

Chris: Alright, that is the principles for building great squads in a cross functional squad style org. So hopefully that's helpful. Hopefully that's revealed some subtle, faux squad like behavior in your scale up or maybe inspired you to go build your own squads at your company.

Yaniv: So if you're a company and you're struggling to implement squads, maybe you've tried to roll it out and you're, you're running against some of the problems that we've actually talked about in this episode. You need some help. Someone who's done this a number of times before Chris, perhaps they can talk to you.

Chris: That's right, Yaniv, I've helped, but geez, I've lost track of the number of companies now rotate over to squads or, better fix problems they have with their squads because they kind of sort of half did it. so chrissaad.com/advisory and, we can connect there.

Yaniv: All right, fantastic. Thanks, Chris. Have a good one.

Chris: All right. Awesome, man. Talk soon. Bye bye, everybody.