Three pillars of microservice culture

One of the things that my API Academy colleagues and I learned when we were doing research for our Microservice Architecture book was that software and hardware are only part of the puzzle when it comes to assembling a successful microservices culture for your organization. It turns out companies that are good at microservice implementations also spend time architecting their company culture and, in many ways, the code and operating system details are less important than the culture details.

This focus on culture and values can make some in the IT world a bit uncomfortable. The stereotype of a socially awkward engineer is a handy fiction for television and movie depictions of Silicon Valley, but the reality is quite different. As we point out in the book, the human resource practices of companies like Netflix and Spotify are great examples of the kinds of organizational designs that are an essential part of any successful microservice culture. And, while we found every company approaches the challenge of crafting microservice culture slightly differently, there are three aspects of organizational design that we identified as keys to success: communication, teams, and innovation.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Communication

The role of communication is best illustrated by Conway’s Law, which can be summarized as “communication dictates design.” Basically, the way teams communicate both within the team and with other teams is directly reflected in the code they produce. For example, in the article “Architectures, Coordination, and Distance: Conway’s Law and Beyond,” Bell Labs researchers showed that things like hidden dependencies that can result in “unexpected responses” are introduced at the team level—long before the code is written. That means designing modes of communication can be just as valuable as designing the code modules. The folks at ThoughtWorks even coined the phrase “Inverse Conway Maneuver” to emphasize the notion that companies can actively evolve and manage organizational structure to achieve desired results.

Here are things you can do to improve the quality and immediacy of communications for your teams:

• Design boundaries, don’t fight Conway’s Law: Engage in up-front design to produce clear, stable boundaries in your code modules and assign teams along those same boundaries. Acknowledge existing physical separation as a “natural boundary” for both teams and code. Make Conway’s Law work for you. Try to maintain stable teams, even if the membership fluctuates over time.
• Communication tools: Provide lots of communication tools (video, chat, mailing list, wikis) to make it easier for teams to get to the right person as soon as possible. Most important, try to make it as easy as possible to create connections between teams.
• Decision processes: Initiate processes that require all decisions to be recorded and published for anyone to see. This helps remote workers to keep up when they can’t be present and it creates a “syslog” of team actions and decisions for historical review.

Every company we talked with mentioned the importance of Conway’s Law in their team dynamics.

Teams

That leads to the second pillar of microservice culture: teams themselves. While the story of how Jeff Bezos used “Two Pizza Teams” to help minimize groupthink is well known, only a handful of the companies we talked to were aware of the social science behind this idea. British social anthropologist Robin Dunbar’s research into primate groups identified the importance of group size as a factor in managing cooperation within the group. As groups get larger, the amount of “overhead” needed to maintain cohesion increases. In 150-person teams, Dunbar’s research estimates that almost 40% of the time is spent keeping the group in sync. But in teams of around five, almost no overhead is needed to stay on task.

What can you do to increase the effectiveness of your teams?

• Aim for Dunbar level 1 or 2 teams: Dunbar’s team size observations (teams of 5, 15, 50, and 150) show that there is less overhead and better communication in small groups. Work to arrange teams on the low end of this series and, if you need to work with larger groups, break them into small sub-teams in order to reduce the overhead.
• Autonomy within teams: Give each team as much autonomy as safely possible. Allow them to decide how things work within the team as long as it doesn’t adversely affect other teams. And, with autonomy comes responsibility. Be sure teams own their product and take responsibility for its entire lifecycle — including post-release support.
• Rely on team interoperability, eliminate dependencies: While teams have autonomy within their own group, it is important that they interoperate well with other teams in the company. Stateless interop, not tight integration, is the goal. Teams should not be allowed to break other teams’ code, and teams should not have to wait on each other in order to do a production release.

All of the companies we talked to for the book were working with team sizes of around 5 to 12—well within Dunbar’s efficiency predictions.

Innovation

Finally, the reason communication and team dynamics are so important for microservice-style companies is that these elements can greatly affect the innovation atmosphere in an organization. Small teams reduce unhealthy groupthink and make it possible to communicate with reduced overhead and ceremony. This, in turn, makes it easier to spawn unconventional ideas and get them implemented and tested more quickly. And small ideas, executed quickly, is an important element in establishing an innovation dynamic in your company. As Ron Ashkenas and Markus Spiegel point out in their Harvard Business Review article “Your Team Shouldn’t Run Like a Well-Oiled Machine,” small teams working independently exhibit a greater rate of innovation success than large, tightly managed teams. And our interviews with companies successfully working in the microservices way told a similar story.

So, what are the keys to fostering innovation?

• Central mission, loose structure: Innovation happens when business goals are well understood and “the way we do things today” is not highly valued. Provide your teams with clear goals and let them know they are free to explore unusual paths to reach those goals. Defending the status quo is not likely to produce new, creative ideas.
• Maximize learning: Organizations with innovative cultures value learning. Several companies we interviewed put a major effort into “lunch-and-learn” sessions, guest lectures, and workshops — usually on company time. Also, encourage your employees to study not just within their stated field of expertise, but also in new or related fields.
• Failure is an option: The path to success is not a straight line. There are lots of failed attempts before discovering something new. Elon Musk tells his employees “failure is an option here.” Mistakes are a learning opportunity. If you punish people when they fail, you kill innovation.

More than source code and containers

Microservices is more than source code and containers. Companies that do well transitioning to a community of loosely-coupled, independent teams, all spend a good deal of their time designing and managing their organizational dynamics and fostering an innovation ethos throughout the organization. Of course, evolving your company’s culture doesn’t happen overnight. Like any important refactoring work, it needs to be done in small, verifiable increments over time. When done well, this will result in a healthy and sustainable system that will be easier to maintain over time. And that is the microservice way.

Get a free copy of Microservice Architecture to learn more about designing a microservices system that fits your business practices, organization, and culture.

This post is part of a collaboration between O’Reilly and CA Technologies. See our statement of editorial independence.