Use Balanced Teams to Suck Less at Software
Or the art of removing friction, and not creating it
If you’re in the business of creating software, you’re in the business of innovation: using an iterative approach to continually discover the best way to fix your customer’s problems with code. This process requires a lot of back and forth and experimentation. Hence the small batches mind-set, which does exactly this. You’re operating in an incredibly chaotic, information-poor environment, where decisions need to be made constantly to keep moving ahead. In complex systems like that, speed and quick access to information are important to make, implement, and analyze decisions, always exploring and looking for the best fit of your software to the customer problem you’re looking to solve.
When you’re executing on a weekly, if not daily deployment feedback loop, you don’t have a lot of time to synchronize across teams. You also don’t have time to continually “go up the chain” to ask permission to try something new.
Instead, you need autonomous, broadly staffed teams that can collaborate with each other to consistently create and ship software, squarely focused on the overall outcome rather than just their individual part in the process.
Thus far, the organizational practice of “balanced teams” seem to be the best staffing approach to maintaining focus on that overall outcome. Because of the huge degree of automation in cloud technology, organizations are now able to free up resources from “the bottom” of the stack (infrastructure) to focus almost all of their resources on the more valuable layer “on-top,” the actual applications being used to run the business.
The exact implementation of a balanced team can vary, but in general it means one team of people per application, who have responsibility for and authority over the software you’re creating and delivering. This team is dedicated full-time to the application for which they have “ownership.”
Staffing-wise, this typically means teams of roughly 6–12 developers, operations folks, at least one designer, a product manager, and often a QA. In larger organizations, there will likely be “shared” resources that may start to look dangerously like traditional teams in silos—like security testers or domain experts. Ideally, you truly want every role and person on the same team, but that’s not always possible.
Worked in my silo
Balanced teams are pretty much the polar opposite of traditional, silos of organizing staff around software development and delivery, where teams of people are sliced up by function, both vertically and horizontally: the data team, the QA team, the front-end team, product management, and so forth. Large organizations have, for many reasons and many years, organized themselves into functional silos, the most logical sounding being the scarcity of IT resources and skills, real or just perceived.
Lean-think people will quickly point out that dividing teams up functionally results in local optimization, which in turn damages the end-to-end goals of your software. This desire to cluster and then control resource allocation is usually done to get as much “value” out of individuals and teams as possible. As with factory thinking, if a DBA’s time is worth $500 an hour, your inclination is make sure they’re always working so that you’re not burning off cash when they’re at idle. The problem of locally optimizing comes into play when the silo team does, indeed, work as efficiently as possible, but to the detriment of the larger project.
The communications overhead required between many different teams can also create waste in the system. A lot of information gets passed around, usually resulting in meetings and large documents, as software is handed off between business stakeholders, product managers, designers, developers, operators, auditors, and other teams that must get involved to ship and then run the software.
Just like a game of telephone, the result is often a highly mutated understanding of the original goals and intentions.
Worse, the “worked on my box” mentality quickly pervades: Those earlier in the chain are responsible only for their area of responsibility — creating requirements, writing software, testing, etc. If something goes wrong for someone else, well, it’s not their fault. These types of issues — and more — tend to introduce a huge amount of waste into the overall, end-to-end, small batch process of creating, running, and then refining software.
Balance your teams
When you hear the old saws about “two pizza teams”, and how “communication is terrible,” and that high performing teams need a high degree of trust with each other, you’re butting up against the wry summaries of the balanced team approach. However you end up staffing the team, keep in mind that the point of a balanced team is to remove as much friction as possible from the process of creating and delivering software, and to remove as much chance for misunderstanding and communications break-downs that lead to developing the wrong software, which snowballs into monkeying with requirements mid-stream, all leading to the usual causes of software failure.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
