Routing Work
A critical moment in the life of a startup is when they start to grow, and decide that instead of having one dev team, they need to create 2-3 teams that can work on different issues at the same time.
Work flowing to a single team is a fairly easy thing to model - the one team owns all of the work and it just decides the most important things to do. But when you add in a second or third team, real questions begin to emerge.
How do you define what each team is responsible for?
How do you manage dependencies between the teams?
How do you parse work to the teams?
The most obvious, and probably common, solution to this is to break up the product into different systems. Team Aardvark takes the search functionality, Team Baboon takes the money handling code, Team Camel takes the customer UX, Team Dromedary owns the seller UX.
The advantages to this approach are pretty easy to grasp:
Each team owns part of the code base, which minimizes merge conflicts
Developers will ship faster in their area, as they get extremely comfortable with the codebase
Routing work is simple when most projects will fit neatly into a single system
This approach creates specialization, which creates efficiency - and greatly increases the speed at which a single new feature is shipped.
However this efficiency is actually a trap.
Imagine for a moment that the CEO of our above example sits down and writes down the 4 most important problems facing the business. What are the odds that each team just happens to have one problem in their system?
Far more likely that the majority of the critical projects fall onto the shoulders of a small number of teams, while the majority of teams cannot contribute to the critical projects at all.
You end up with a queue of work that looks like this:
Of course Team Baboon and Team Dromedary aren’t going to do nothing, so they will build a roadmap of useful things to create value in the meantime. Team Dromedary will adds lots of nice new features for sellers, but none of these are mission critical. The business will ship a lot more code, but will it ship more value?
It’s common for the CEO to feel like the company is moving too slowly as she waits for Team Aardvark to churn through its backlog, even as the company is shipping more features than it ever has before.
There is a better way - to focus more on delivering value than delivering code. Instead, if the teams were each given one of the major problems to focus on and solve - and then each team were given the right to build code wherever they needed to to solve the issue.
This creates a lot of inefficiency:
Devs will build slower because they are much less familiar with the code base
There are risks of merge conflicts if two teams touch the same system at the same time
Deciding how to hand out work to teams is more complex
However, the benefit of this approach is that after a single time cycle all four of the most important problems in the company have had code shipped against them. Less code is shipped, but more of that code really matters.
