Newsletter – Pod People
Here is a copy of our newsletter, if you would like it delivered to your inbox signup here.
“Pod people” was a nickname for an alien species featured in the 1955 novel The Body Snatchers. They were a group of nomadic, extraterrestrial parasites floating through space and taking over planets. Today we’re seeing a reemergence of “pod people” in our technology organizations but unlike the alien pod people these are productive groups of employees who speed up Time to Market (TTM) and foster greater creativity.
Problems with Hierarchical Organizations
Corporate organizations are primarily modeled after military organizations which are hierarchical. While some corporations have attempted to eliminate managers, most are aligned by division under a C-level executive (finance – CFO, technology – CTO, marketing – CMO, etc). Under these individuals are typically sub-divisions by specific tasks such as software development, QA, product management and technical operations under a CTO. There are three major problems with this hierarchical model – no single owner, conflict, and efficiency.
When delivery of a product requires multiple teams within a hierarchical organization no team or person on the team is actually responsible for delivery. Ownership by all is ownership by none. When the release of the product is late no single person / team is to blame.
Speaking of blame, putting people in teams causes people to start associating their self-identity to that team. In 1968, a teacher named Jane Elliott divided her class into blue-eyed and brown-eyed groups. On the first day, the blue-eyed children were told they were better than the brown-eyed group and on the second day the roles were reversed. Children designated as inferior performed poorly on tests and those designated as superior became mean-spirited. We see similar issues when people are separated into different groups by function – they start thinking other groups are inferior.
So if there are all these problems with hierarchical, functional organizations, why do we organize this way? One reason is that this organization structure is optimized for efficiency of the different functional skills. For example, this isolation by skill is very efficient for software developers to produce code. However, SaaS companies provide their customers with services not code. Certainly code is an important part of the service but it isn’t what the customer is buying. In order to optimize for what the customer is buying (the service) we need to organize around those services.
In systems architecture we use the term “swim lanes” or fault isolation zones to describe a service that is completely isolated. In order to achieve this there can be no synchronous calls between services. The reason is that synchronous calls tie the availability and scalability of services together. If you have separate services on your site such as browse, search, and checkout if the third party that provides the checkout service goes down, your users can still browse and search. What if we apply this architecture to an organization?
Org to Architecture Alignment
It turns out that organizations grouped into small cross-functional teams are very efficient in terms of overall service delivery. If we align these teams or pods with the services in our “swim lane” architecture they are able to act even more autonomously which speeds up their TTM. This is what Agile teams are supposed to be, at least according to the Agile Manifesto that states as one of the twelve principles that “the best architectures, requirements, and designs emerge from self-organizing teams.” The teams no longer have to coordinate across teams for changes in code or approval of ideas before implementing.
Individuals on these Pods associate their self-identity with the team rather than with their skillset. Because the team is responsible for delivery of the service – from idea inception to delivery and support – there is less conflict between teams. Team members participate in more cognitive conflict (the good type) where they debate how things should be done and have less affective conflict (the bad type) where they argue about who should do what tasks.
We also have a single team that owns the service rather than this responsibility spread across multiple teams. We have one group of people to praise when things go well and one group to work with when delivery dates are missed. While pods provide a lot of benefits and solve many of the problems with hierarchical teams, there are also some issues to watch out for.
For maximum efficiency, pods must be aligned to the architecture. They also need to be aligned to business units. Having general managers of different business units pull on a single Pod to help achieve different goals forces the pod to prioritize which business goal is more important. Instead, the GM and pod should jointly decide how important each goal is in achieving and allowing this to determine the priority of work. Having a single GM sponsor of a pod helps ensure that this is done properly.
Another potential issue with pods is when they are not given ground rules to operate under. While we want the teams to be as autonomous as possible, there are some things that should be standardized across teams. For example, teams might find it useful to select whether they use ideal days vs. story points for estimation. This type of “customization” of a process is probably fine. However, customizations that cost more to support, in terms of extra people or training, should be avoided. Having multiple source code control systems (Git, CVS, etc) is probably not necessary and just costs the business more.
Whether you want to be a pod person or stick to a hierarchical organization there is no panacea. Building, delivering, and maintaining great services still require hard work and dedication. However, in the ever present cycle of distributed-centralized we are now seeing the trend towards small decentralized teams or pods. If you’re implementing pods, good luck, and let us know your experiences.