AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

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.

Swim Lanes
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.

Potential Problems
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.

Conclusion
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.

Send to Kindle

Comments RSS TrackBack 6 comments

  • silver price

    in December 25th, 2012 @ 10:06

    Teams that make or do things. These teams include people at or near the front lines who are responsible for doing the basic manufacturing, development, operations, marketing, sales, service, and other value-adding activities of a business. With some exceptions, like new-product development or process design teams, teams that make or do things tend to have no set completion dates because their activities are ongoing.


  • Idebenone

    in December 26th, 2012 @ 01:06

    The list of available supervisors includes any agent tagged as a supervisor. Supervisors can be assigned to multiple teams.


  • Piracetam

    in December 31st, 2012 @ 15:09

    Team based structures are different from those found in hierarchical type groups. Hierarchical groups generally operate in a directive or consult type mode whereas teams operate in a consensus or delegate type mode.


  • piracetam

    in January 1st, 2013 @ 17:05

    Lack of empowerment can be a functional glass ceiling and it can prove to be a stumbling block especially for teams that front organisations in customer services or client relations. Lack of empowerment can also slow down the work flow because the decision making is vested higher up the hierarchy. A certain amount of authority and decision making leeway helps improve work efficiency and also ensures that a team takes pride in its existence. If the team is empowered to make some of the decisions, this empowerment becomes an enabling force and positively impacts the efficiency and revenues of the organisation. Many companies have reaped tangible benefits by using empowerment as an ‘enabling force’.


  • Dealing with Shared Services

    in January 10th, 2013 @ 15:54

    […] piracetam on Newsletter – Pod People […]


  • Enablement | AKF Partners Blog

    in May 13th, 2013 @ 09:30

    […] infrastructure team and one of the first changes we made was breaking apart into reasonable sized PODs with the primary purpose of ensuring that decisions for the product & technology were driven […]