Small Parts, Loosely Connected

Another aspect of teams, networks, organization, or other associations of people is how the always-necessary subcomponents interact.  Clearly, the “clinking and drinking” example shows why we can’t have huge teams just working things out as a group.  The early discussion about Dunbar’s Number indicates this isn’t even workable for humans sociologically, though I wonder if ever-connected millennials may argue this point, or at least expand the upper range of Dunbar associations that they can effectively manager.

The trick for any larger organization is to be purposeful about how the component sub-groups work with one another, and I think the tech world has something to offer the low-tech world of politicians, educators, and business people as well:  2-pizza teams and modular approaches that favor small parts that are loosely coupled.

Jeff Bezos at Amazon made the 2-pizza Team term ubiquitous in the tech world, but it makes sense in any company, and any organization, where change is underway.  A team of 5-8 people is big enough to have broad skills, some diversity of opinion, and enough manpower to make an impact, but is small enough to self-organize work and get things done expeditiously.   Such teams have been proven to be able to tackle a range of problems successfully, and often can outperform larger teams and pull off feats that seem remarkable.  Of course some jobs are too big even for a well-oiled and capable team, and so it takes multiple teams, and that’s where the other aspect of a modular system comes in – loosely connected.

One of the truisms of systems theory is that you can’t purposefully create highly functional complex systems (note that complex systems are not the same as complicated systems, as complex systems have time-varying interactions that are chaotic in nature and impossible to predict accurately over the long term).   Good complex systems are almost always the result of starting with a good simple system and then letting it grow, often by informal trial and error.  This phenomenon is quite evident in software systems, where you see software platforms like Google, Amazon, and Facebook that are massive and successful but that started very simply, yet big systems like the US healthcare.gov and updated air traffic systems were massive failures.  Healthcare.gov only started working well when it was split into parts, with development of much simpler subsystems by – you guessed it – small teams of highly skilled people. 

Unfortunately, most human systems are complex systems, and so we know that to expect to design a large system at once is not a recipe for success.  If we’re going to do something well, it needs to start small, and grow incrementally.

The key point about growing incrementally is to revisit the overall structure as you go, and ensure that it becomes modular, with clear bounds between the parts.  This is critically important for software systems, where technologies and needs change and evolve fluidly, so you need to be able to upgrade some parts while adding other pieces new, and dropping obsolete functions entirely.  Defined interfaces between the parts – protocols and application programming interfaces (APIs) – are the way you do this with software, and there are similar approaches that have been used successfully for many other systems.  Your car, with various interfaces between chassis, driveline, dashboard, etc. with standards for things like radio sizes and tire specifications, is a good example as well.

Amazon, as one of its core practices, requires that each team create a public API for the other software systems and associated people to interface to it, and that API also provides a set of performance expectations (service level agreements, or SLAs).  This means that for any new capability invented or innovated inside Amazon, there is a clearly defined way for others to leverage it for their own purposes, and a clear statement of the performance they should expect.  Often, a team comes up a solution for an existing need, then other internal customers leverage the solution for new uses, and then Amazon makes it available as a new service. 

This notion of simple, public APIs and two-pizza teams is exactly how Amazon promotes the idea of “small parts, loosely connected”, and makes it a tenet of their culture.

I think we need to consider the design of human systems for our city innovation project in a similar vein; each part needs to be clearly delineated, with a specific function and a small dedicated team supporting it.  Each team should offer an API – the way you do business with it – with a service level agreement to manage expectations.   Really, this is something we should expect for ALL city/governmental services, and it’s such a direction that Code for America intended to promote, and probably the local Code for Tulsa and Civic Ninjas would likely support the notion as well.    Empirically, when you make the public interface and its responsiveness/performance the focus of attention, you tend over time to get better interfaces and better performance.