Pillars And Governance Structures


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.

A goal at the top and a bunch of pillars at the bottom. No foundation.

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

A goal at the top, a bunch of pillars holding it up, and then a bunch of subpillars. Still no foundation.

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 TeamTopologies1 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,

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 …

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

It’s a Graph

Interdependencies form a graph, not a tree.

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 efficient2. 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:

Big organization, goals, outcome oriented pillars, outcome oriented teams, activity oriented pillars, and activity oriented teams

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.