Pillars And Governance Structures

Re-orgs.

It’s a fact of life for large organizations. A popular metaphor making the rounds now is this concept of pillars. The metaphor makes sense to some extent.

A house without a foundation

Let’s start with a picture of how a sanitized version of a pillar structure would look like.

On the top is some kind of goal or an organization. In the case of an organization we can think of organization’s mission as the goal. Pillars support the goal.

Stage 2: Subpillars

Massive corporations can’t be organized around a handful of pillars. We need more structure: subpillars.

The subpillars are holding up the pillars. Together all of them hold up the goal.

Collectively what we are looking at is a system for organizing people. One that is hierarchical and tree structured.

We all know this. Because that’s what org charts have always looked like.

Team Topologies

In TeamTopologies¹ Martin Fowler et. al. discusses different kinds of software teams.

One can think of pillars and sub-pillars as being higher level structures for organizing these teams. Individual teams at the granularity at which team topologies apply are too granular for pillars.

What I found compelling in “Team Topologies” were the concepts of Outcome Oriented teams and Activity Oriented teams. These have always had names – project teams and service teams.

Fowler’s article mentions

To put it in a nutshell,

• Outcome oriented teams are teams that are working towards something. They hope to achieve some sort of goal, and once it is achieved the purpose of the team has been fulfilled and typically people move on to other things.

  Outcome oriented teams have specific measurable goals like…

  • build a thing,
  • make specific qualitative change happen,
  • research something, or
  • achieve a sales goal.

• Activity oriented teams are teams that perform some sort of activity for the organization. They do things like keeping the lights on, bug fixing, and occasional feature development. Activity oriented teams are typically in the service of enabling an outcome.

  Activity oriented teams have qualitative goals like

  • uptime,
  • efficiency,
  • user-satisfaction, and
  • level of support.

There are more details and nuances and much hair-splitting. But the gist of it can be understood without diving too far into the weeds. What is important is that …

Outcome oriented teams and activity oriented teams can mutually depend on each other.

Also …

• A single outcome oriented team can depend on multime activity oriented teams.

  For example, a team tasked with building a new service will depend on multiple existing services that are under the purview of multiple activity oriented teams.

• A single activity oriented team can depend on multiple outcome oriented teams.

  For example, a team tasked with maintaining a critical service will at times need to implement large changes or features, which require multiple outcome oriented teams.

Uh oh. Our organization is not tree-shaped anymore.

It’s a Graph

The problem is that the the thing we are trying to organize is not tree structured. Each group has relationships that stretch vertically along the reporting chain, and also horizontally across “enabling” teams, support teams, infrastructure teams, or other teams that are solving similar problems.

An organization especially at this level of abstraction cannot represent all this complexity. A large number of free-floating small teams interacting with each other won’t be very efficient². Nor is it conducive to goals at a large scale because that would require a degree of cooperation that won’t appear spontaneously.

So we need to steer this pool of teams. It needs some structure so that some higher level of management can coordinate a number of smaller groups; so that they can collectively work towards a common but larger goal.

With this newfound knowledge we can once again approach the pillars but this time with goals and activities for the higher level teams.

It’s a Tree (Again)

However, the leadership needs to figure out which of these relationships to organize around.

This isn’t quite satisfactory yet because we can’t made things fit into the pillar system. Once people get stuck on pillars everything needs to be a pillar.

We can, however, stick teams into pillars. These teams would be outcome oriented if they are stuck into outcome oriented pillars. It follows that activity oriented pillars will need to be stuck into activity oriented pillars.

So it’ll kind of look like this:

And there you have it.

In reality, the structure can be made much cleaner once you start asking each team what their goals are.

But the gist of it is you can’t plan teams or pillars until you know what their goals are.