Poly-skilled Teams Deliver Products

A lot of what sets Atomic Object apart is our people – we work very hard to ensure we hire the best. But hiring great people isn’t enough. The best people need to be set up in an environment where they can use their skills effectively and translate their excellence into business value. Atomic’s strategy of deploying poly-skilled, co-located teams of generalists puts us in a position of delivering quality to every customer every time.

We’re:

• Poly-skilled – our teams mix developers and designers so that the team’s skills span the needs of the project in rough proportion to the size of the need.
• Co-located – our teams work together, side-by-side on a project, allowing people to pair on problems as necessary, so that all opportunities and constraints are balanced.
• Generalists – we hire people that have mastered or can quickly come up to speed in many areas, whether technical, strategic, or creative.

In an Atomic team the whole team has ownership of the feature they’re developing, with each member or pair solving the component problems with their own skills or via consultation in the most efficient way. Contrast this with rigidly organized teams of specialists. Such teams solve specific problems with great efficiency but introduce inefficiencies at the boundaries, when the next problem is in a different domain than the former. Each group has ownership of their own domain and cross-cutting features accumulate latencies as it passes from group to group. Atomic generalists solve what problems they can and exercise judgement about when the inefficiency of a context switch or consultation is worth the payoff.

And consultation is an extremely important part of why our approach works so well. Since teams are co-located without the burden of specialization-induced boundaries, pulling in another team member for a quick brainstorming session is trivial and low-overhead. Furthermore, team members with a stake in, and ideas about, a particular problem often pick up on discussions between their nearby teammates, pushing themselves into the discussion and helping drive progress toward an ideal.

This team organization is a microcosm of Atomic as a whole. It’s not uncommon that teams run into problems that no one on the team has the expertise to solve. Since AO is, itself, a poly-skilled, co-located team of generalists (though more poly-skilled and less extremely co-located than a project team), teams can draw on talent elsewhere at Atomic with nearly as much efficiency as pulling in a team member working on another feature. There are no formal barriers to seeking advice from another Atom to solve a problem – just the time needed to provide context and consideration of budget and billing.

This flexibility helps make up for one of the potential shortcomings of our generalist-oriented approach. With the teams of specialists, a skilled and highly specialized DBA is making decisions about the database schema and indexing strategy, for example, instead of a skilled generalist with less expertise in database optimization. These local efficiencies within a specialization domain might cancel out the latencies we avoid that come from that very specialization, if it weren’t for our equally effective alternative. Because we can draw on our global pool of diverse talent with little overhead, we get all the benefits of specialization while avoiding most of the cost.

And the cost of specialization can be substantial. A piece of software is a vertically integrated project which incorporates all of these concerns. A successful product has a delicate balance of technology, design, and copywriting where all three components exist in harmony, respecting the constraints each imposes on the other while delivering maximal effectiveness within those constraints. Separation of responsibilities introduces a mismatch between this delicate balance and the process that needs to produce it.

Consider a hypothetical organization with a software development team, a design team, and a marketing team, which is responsible for copy. The design team produces a design. The development team evaluates it, and begins implementation. While under development, part of the design is realized to be technically infeasible. The design team is notified, while the development team moves on to another part of the design. In the worst case, the development team gets blocked and wastes capacity. But in the best case they’re multitasking; dividing their attention between concerns and addressing neither optimally. Eventually the copy team is brought in to write copy that is too long or short for the design. A set of back and forth exchanges addresses the copy concerns via a combination of copy and design adjustments. But then the development team needs to implement the new design. Unfortunately, each team is split amongst multiple projects, and the developer or designer or copywriter who deals with an issue may not be the same one who worked on it originally, and their lack of context may introduce other problems because they violate other constraints with their proposed solution. These teams begin a limiting process to approach the desired equilibrium, but are thwarted by the latency between and interchangeability of their members, settling instead for a buggy, mediocre product.

Doing things the way we do it isn’t easy. Everyone needs to be able to pull their own weight and provide a complex of skills that can delicately balance those of whatever team members they’re likely to end up with. You have to have excellent people. You can hide a bad practitioner or two in a pool of otherwise excellent specialists, but a poly-skilled team can never succeed if any team member isn’t up to the challenge. But if you have great people, vertically integrated teams of poly-skilled, co-located generalists can build vertically integrated products with unmatched efficiency. I’m proud to say we do. We’ve built an organic company, building products organically, with significantly more efficiency and excellence than other organizations.