The Atomic Team Pattern
One pattern that I’ve seen work well in software development management is one I call The Atomic Team pattern. Basically what it means is that ideally the smallest indivisible unit for management is the team. I think it’s a cornerstone of healthy service-oriented architecture, but it’s rarely talked about because it’s on the more touchy-feely and less-technical side.
Management of such a team ends up primarily involving:
- Communicating expectations and objectives
- Ensuring the team has what it needs to be successful
- Handling (ideally) infrequent interpersonal issues that the team can’t handle themselves.
There are a few disadvantages:
- Teams can take some time to form.
- Some developers don’t have the interpersonal skills for this.
- There are always interpersonal issues to consider.
- Teams are not resilient to reorganization.
- Will individuals on the team be happy with their role on the team and the type of work that the team takes on?
Requires less management
Let the team self-organize around tasks instead of being command-and-control orchestrated. Drop prioritized work into the team work queue and they can figure out who does what and when based on their own availabilities and skillsets. Team members can hold each other accountable for the team objectives.
Cross-functional teams often have more than one person capable of doing a given task. This keeps the queue moving even when someone is sick or on vacation.
Less Stress for Team Members
On a well-formed team, team members can count on one another for help and support. Vacations and sick days rarely affect a delivery timeline much at all. No one needs to be the only one responsible for stressful issues, outages, deadlines, or un-fun work. The increased autonomy in how the team executes on its objectives is highly motivating.
Better cross-pollination of knowledge and skills
Team members can teach each other skills and organizational knowledge so that they level each other up. My best career development has come from working with brilliant peers.
Put simply, two heads are better than one. The best solutions that I’ve seen in software development are most often devised by a team riffing off each others’ ideas with a whiteboard.
Long-term group ownership of codebases and services
In reality, software doesn’t just get deployed and run in perpetuity without engineering intervention. Even if there aren’t any new features to add, there are hardware issues, bugs, security issues, and software upgrades. When teams own the software they write forever, they write better software, they monitor it better, and they manage it more easily. Without team-ownership, you’re often left looking for someone to work on some long forgotten service when it inevitably needs work.
The result of these advantages is an software development organization that scales much more easily.
Anti-patterns when Managing Teams
- adding / removing the members of the team often
- loaning out team-members for other non-team objectives
- holding individuals responsible for results of team objectives
- creating competition within the team
These types of activities remove the mutual trust and comradery from the team and stop the team from forming beyond “just a group of people”. This stops the members from working as closely together as they could otherwise and undermines a lot of the advantages of having a team.
Over-Management / Micro-Management
- dictating who on the team does what
- becoming a communication conduit for two team members when they can just talk to each other
These types of activities are mostly unnecessary except in extreme situations so they’re a time-sink and create a bottleneck that makes scaling your organization harder. Additionally, a manager can often make much worse decisions in these areas than the team members because they’re the people closest to the team and the work.
Not Respecting Communication Overhead
- Choosing teams of similarly skilled individuals (eg “The Frontend Team”). Teams that are not cross-functional often can’t deliver their own solutions without a lot of communication with other teams.
- Choosing teams that are too large. Teams that are too large spend too much time coordinating efforts and coming to consensus on issues.