A company-wide multitasking machine
Teams should solve one problem at a time. Monotasking is the road to predictable planning and high-performance teams.
But companies can't monotask. They have to do multiple things at once. A company can't tell the sales team to wait until a feature is ready before hitting the road. They can't have their developers sit idle while the product manager interviews users.
Companies need to multitask.
We do this by setting up separate teams. These teams work independently from each other and can focus their attention on different problems.
Let's take a small startup as an example. They have a product manager and two engineers. The romantic sentiment is that they should all be one big team. But that's counterproductive. They can't solve the same problem at the same time. The nature of their responsibilities is such that they need different timescales.
If they truly were one team, they would start their timebox without a clue what to work on. That's not what we want. We want them to start their Focus Block with a clear Problem Description. That means the product manager has done some legwork to talk to users, gather feedback, and identify, describe, and rank problems. That's not something we want to happen on the first Monday of the timebox. Given the natural difference in the cadence of Product and Engineering, it makes sense for them to be divided into two teams.
The PM will work with her people to identify and prioritize valuable problems. She lives at the speed of user feedback. In some environments, the users might be in the building, and conversations can happen daily. In other cases, the users meet up at that quarterly convention, increasing the length of the feedback loop.
The developers, on the other hand, live at the speed of delivery. They progress as fast as they can ship solutions. They can’t wait until the quarterly conference is over.
Trying to synchronize these two work rhythms is detrimental to both! It's much better if they work in two separate teams that keep each other informed through a shared roadmap.
Now, let's assume the company is growing, and after a few rounds of hiring, that engineering team has five developers. That's a lot of engineers working on the same problem! This might be a good time to split those up into two teams. If the startup has a web app for regular users and a back-office app for admins, we could create a web app team (3 devs) and a back-office team (2 devs). Each team owns a part of the product and can solve their users' problems at their own pace.
When splitting large teams into smaller ones, we must do this based on problems rather than skills or technologies. It's a common mistake to create a front-end and a back-end team. Dividing by anything other than product/problem creates structural dependencies where one team has to wait for the other to complete stuff. We don’t want that. Teams need ownership of a product or a part of the product to be effective.
While we can avoid structural dependencies, it's impossible to avoid dependencies altogether. Sometimes, Team A relies on the output of Team B. Such dependencies should be conversations between teams. If the web app team relies on a feature by the back office team, that dependency should be clearly reflected on the roadmap.
That might sound straightforward, but it isn't common. We often see a layer of managers trying to coordinate those teams. Rather than fostering inter-team communication and ownership, companies often rely on top-down coordination of tasks and dependencies. A good manager might be able to run a team or two this way, but this approach quickly reaches its limits.
If we want to have predictable plans, we need direct feedback from the teams that do the work. A manager who plays conductor in an orchestra is a bad idea. Such a top-down plan reflects the perspective of a single person, and people are fallible no matter how talented they are. A plan that's not teamwork is wrong by definition.
What we want is a network of small, independent teams solving their own problems, communicating through a shared timeline.
That's how we get a company-wide multitasking machine.