Software Product Teams
Benefits of long-lived, cross-functional, right-sized teams.
The team is the atomic unit in an organisation. They are how things get done. Teams are composed of individuals of course but individuals come and go and no matter their ability they can not consistently achieve strategic objectives alone. The team is what can persist and thrive and be depended upon across time.
Team Product Model
Teams are groups of people that work closely together on things.
Products (for lack of a better word) are the things that teams do. The product or service that the team provide to solve problems for specific users. It is a logically coherent grouping of things that deliver value to a user. It can be really clear like “the product is the website”. Or it can be a bit more abstract. For example a product could be a set of processes, tools and analysis that provide a view into a complex area e.g Developer Experience, that can then be used to help make decisions and perhaps develop more products.
Products have objectives, long-term visions and roadmaps to move closer to those visions.
Teams have a logical purpose and are responsible for one or more products that help achieve that purpose.
Models are important so that we can conceptualise how things work. Practise is important because it shows what happens in reality. In my experience the Team Product Model is the best in terms of theory and practise. In terms of being able to think about organisational design and the outcomes you can reliably expect and — importantly — the actual experience of workers.
This simple and flexible model can work really well as long as some important details and nuance is accounted for.
Composition
Teams need to be cross-functional. That is that they have the skills sufficient to consistently deliver value to users in a self-contained way. Because the modern technology environment is so complicated any individual team will likely need the support and services of many others but fundamentally it needs to be in control of it’s own value stream. It’s important that teams don’t hand over their work to another siloed team who might perhaps hand it over again to another. This traditional working model isn’t effective. Those closest to the product and the users simply have the best knowledge and perspective to make decisions around the product and respond to unexpected events regarding it. This is further enforced via true ownership and accountability.
Ownership
Teams enable clear and unambiguous ownership in an organisation. This is a strong source of efficiency. If support is needed or change is needed in a particular area then there is a clear place to go. We should be able to directly attribute every single running system, piece of source code or piece of documentation in an organisation to a team. If we can not do this then we have a systemic operational problem that needs to be fixed.
Shared ownership only works where there is a tight understanding between parties involved with a clear and consistent commitment to a roadmap with roles and responsibilities. It absolutely never works when there are many parties involved. In this case a steward team needs to be appointed. In my experience shared ownership can often result in no ownership; no maintenance, no evolution, no quality and is irresponsible.
Another key is that individuals do not own things. The organisation owns the thing and the stewards for that ownership are the team. It’s stewardship really.
Explicit ownership ensure there is skin in the game. There is less chance of careless drive-by hacks to just get something done because the team have to live with the operational and development consequences of everything that changes. Every debt choice is one that they need to pay back themselves. It’s not offloaded to some other poor souls.
Time
Teams need to be long-lived because products are long-lived. In fact teams can own multiple products and their purpose is above and beyond the scope of any single product. The product is just a means of achieving their objectives.
Focus
This long-lived ownership gives the team the time and space to really understand their problem domain, their users and their technology. This longer-term focus enables a deeper understanding, unlocks higher levels of quality and makes change way more efficient over time. This way teams can increase scope without slowing down and needing to increase team size.
There are two pernicious beliefs in custom software product development that time and focus provide a remedy for.
One is that all software is basically the same and so any software engineer can just go and work on any project at any time. In reality different skills take different time horizons to develop. But, even assuming 2 products use very similar technology it still isn’t so straight forward. It is very difficult to fully understand software so that you can make good decisions regarding it. Constantly moving from one codebase to another means that you are never working efficiently and reliably produces lower quality outcomes that cause visible issues or slow down future development. It is like getting an author to work on 3 novels at once.
Two is that once something is done you can leave it alone and don’t really need to think about it again. Custom software environments just don’t work like this. They require continual care.
Size, Redundancy
I want to start this section with the recognition that 1 single person can create impressive complex software systems. Not just architect them but actually fully build them. For the most part software is a problem of design and logic not labour. Throwing more and more people at a software problem will in fact slow it down and decrease quality and cogency. This was understood by Fred Brooks ~50 years ago.
One single mind can have a really good understanding of a problem space. They can see an opportunity and have the motivation to solve for it with high quality, well architected software that can readily evolve for future scale and changing needs. If you check the history in your favourite software projects it is quite common for the first 100 or 1,000 commits to come from an individual inventor.
In reality we oftentimes aren’t always super motivated about the problems we are required to solve. We don’t have all of the information and we can benefit from others diversity of experience and perspectives. We can learn from each other to improve and grow. Teams are also a good forcing function for quality in terms of documentation, explain-ability and technical standards because multiple people must understand what the codebase is doing, why and how and agree on methods.
Even when someone really can do it all. Which is common enough. What happens when they go on holiday or get sick? What happens when they lose motivation? What happens when they decide to leave the organisation? One person can never provide durable reliability. And at a certain scope things are simply too much for any individual. Linus Torvalds could not run modern Linux alone.
I see 4 people as a minimum team size. At all times at least 4 people should understand each software product in your organisation to a non-general level of detail. This de-risks person-dependency. Four people can make progress on multiple priorities at once, they can handle unplanned work, they can run a sustainable on-call rota if needed and they can continue to operate with reduced capacity.
Indeed not all software projects require 4 people. So you should combine logically related smaller projects in to a team or implement through existing teams. For example 1 team could handle 4 smaller projects instead of 4 people handling 1 project each.
If you want to get a system up and running by taking advantage of 1 person’s skill and clear vision then you need to ensure they are able to sync up with the rest of the team and bring others in to the fold before too long.
Various resources coalesce on ~8 being a good team size to effectively communicate / collaborate / coordinate rapidly. “Two-pizza teams”. This is also the consensus for being the approximate limit number for a managers line reports. Software product teams of this size can have a massive impact and they can remain around this size if they continually invest in terms of quality and automation that enables sublinear people scaling. From personal experience it gets difficult to as efficiently plan, coordinate, integrate and maintain standards at around 10 people working concurrently on something. This is the reason most sports teams are in the ~5 to ~10 range. Think about it.
Tightly knit groups with sub-teams of up to ~20 people can work but this does require more management overhead and strong team leadership.
Perhaps ~20 to ~100 people requires a director, team and group leads, continual departmental alignment and continual relationship building activities.
Past this point you need to do different types of organisational alignment and depend on clearly visible team-to-team communication and publishing channels.
Empowerment
We are constrained in a positive way by having a defined team purpose because that means that everything within that constraint is fair-game. With expertise developed over time and high degrees of ownership and control we can be more creatively ambitious in finding the best ways to do things and the best things to do. With a little slack in the team size and the ebb and flow of work we can afford to be innovative and use time to research new stuff.
I am always sceptical of separate innovation teams. I don’t think that is often effective or cost effective as innovation should often be problem-led and embedded with those closest to the problem.
Happiness
All of these benefits of teams also provide an improved experience for individual team members in different ways.
Being empowered is inherently positive. Having explicit purpose and ownership increases mental clarity. Being able to directly make changes is satisfying. Deep focussed work is a positive feeling. Also, it’s nice being able to get really good at something that is difficult. And having reasonable team sizes reduces the chances of overwork and burnout.
Alongside this humans are tribal creatures at-heart and having a closer-knit longer-lived home team with a shared view and experience can promote belonging.
Collaboration
“But if engineers are not all working on everything at once how can we coordinate projects where something need to change across products?” you may ask.
Team to team collaboration can be coordinated between those teams involved easily enough without any outside help. When there is a cross-cutting concern across many teams then an architect should coordinate and lead this effort between the teams. You can create a temporary team out of existing teams where each individual can ensure that the changes are able to go in to their product safely. This is best if things need to be tightly coordinated but sometimes it isn’t necessary.
“Where will the architect come from?” you may ask. Just as good team sizing will leave a little slack then departments should have enough slack for an architecture group or they may be senior engineers who have other home teams on a day-to-day basis.
