I never cease to be amazed at the sheer complexity that Tech organisations build into their structure and their ways of working. Complexity that conceals the essential simplicity of what they are trying to achieve. Complexity that adds cost and decreases efficiency as we have to navigate through the complexity to achieve our daily work.

Organisational design never seems to resolve the problem of complexity. Typically we see it just adding new layers on top of what was already there. If we are lucky, a new form of complexity simply replaces the existing.

This behaviour seems to be an innate human response to problem solving. In all sorts of fields, but especially in systems engineering we see complexity being added at a more or less constant rate. After an extended period of time the cost and risk of this complexity is recognised and the system (organisation design, computer system, way of working) is re-architected from top to bottom. The cost - financial and personal - and risk of this “saw-tooth” of complexity are obvious.

Smoothing The Saw-Tooth

Having anAgileMind is partly a response to this saw-tooth approach. Short-timescales and intensive, short feedback loops at least reduce the vertical scale of the problem. The risk and cost of each reset is significantly lower as a result.  Today, many organisations are basing their approach to systems engineering on the concept of systems products. Emphasising intensive engagement with the consumers of the product and rapid feedback to continuously validate the direction of work.

But, I have not observed any progress in smoothing the saw-tooth when it comes to the way we structure our organisations and create our systems of work. It is true that at the smallest scale we encourage teams to retrospect, to learn lessons and benefit from their immediate application to future work. These small scale gains are mostly the result of the move towards agile practices.

Big And Flawed

When it comes to larger scale organisational change we are still at the mercy of very long cycles and very substantial impacts. Part of this rigidity is created by the legal complexity that surrounds organisational change. Organisations have the belief that the only way they can implement meaningful change is through a big-bang approach.

It is doubly disappointing to see that even when organisations get around to making a change they typically miss the opportunity to radically simplify. Instead we see the old complexity replaced with new complexity. We see Larman’s laws - that organisations are optimised to avoid changing the status quo - being applied with a vengeance. After just a few weeks the organisation feels identical to how it felt before. Plus ça change…

This is not surprising when we see so many organisations allowing legal constraints to drive their design. Perhaps it would help us to build simpler, better organisations if we focused on where value comes from as we build systems products and deliver services. I want to suggest that value is driven in four key ways:

• Teams at the heart - that’s the only place value comes from

• Enabling high performance - so we get the best from everyone we employ

• Guided by customer value - so we get our outcomes and priorities right

• Efficient process - so we are productive and minimise the cost of bureaucracy

Teams At The Heart 

Everything else is waste. 

Teams create new features for our customers and deliver the services that our customers need. This is the only way we produce current and future revenue. Everything else the systems organisation does is waste. It may be necessary waste - imposed by legal framework or company policy, for example - but it adds no value to the systems and services we are building and delivering.

As we design our new structures and ways of working we should focus on how we can build strong teams and how we protect those teams, recognising they are our most precious resource. Simple metrics like role efficiency (what proportion of roles in the organisation make a direct contribution to feature creation or service delivery?) and organisational efficiency (what proportion of posts in the organisation make a direct contribution to creating value?) can help us evaluate different organisational designs.

Enabling High Performance

Everything else is ineffective.

Given a choice between two teams, one produces average performance, the other delivers high performance, which would you choose? 

The answer is obvious. So as we undertake organisational design we need to ask what features can we include in our organisation design that will enable high performance in teams? Of course, this is not a guarantee that high performance will emerge. But at least we are creating the circumstances where it can emerge. We enable rather than inhibit.

After many years coaching teams and organisations, I identify 4 critical characteristics that, together, provide an environment for high performance:

Stable - everyone recognises the Tuckman model, but most miss its implication. Everytime we meddle with the membership of a team we meddle with the performance of the team. We push the team back down the Tuckman stages from Performing to Forming or perhaps Storming. There is substantial cost in terms of lost performance and the time taken to recover performance. There is a risk that we may never recover performance because it does not emerge from the new team formation.

Integrated - the team needs to be capable of doing its work from start-to-finish. This means we avoid the inefficiency of hands-off. We also avoid the excessive use of specialists that can too easily become single points of delay or failure. In any case, the working relationship with a specialist is more remote than the close, high performance relationships we can create within the team.

Small - we can only sustain a few close relationships of the type that lead to high performance. Beyond this limit, larger teams will decompose into smaller informal groups. Being informal it is hard for the team to optimise the groupings that form, the groups may be unstable or become specialised in one aspect of work. In other words, we no longer have a stable or integrated team.

Long-lived - this is different from stability. Stability talks to the rate of change of the membership of the team. Longevity talks to the total life of the team. Like my grand-father’s wheelbarrow, I may change the wheel, the tyre, the handles, the stands, even the barrow itself - but it’s still my grand-father’s wheelbarrow. In a product-centred world the expected life of a team becomes very obvious - we align the lifetime of the team to the lifetime of the product the team is responsible for.

Evaluating these four features as a part of our organisational design will create the opportunity for high-performance to emerge. The actual emergence of high-performance depends on the team members, their culture and their behaviours too. This makes performance harder to measure because what we measure will depend on the context in which we work.

Guided By Customer Value

Everything else is less valuable

We have a finite amount of effort we can consume and a finite amount of time in which to consume it. From the huge list of work we could do we need an effective filtering mechanism to help us to choose what we should do. In a product-oriented world, the filter we use is pretty obvious. Which of these items on our list will deliver the greatest value to our customers?

The whole thing is made more complex because we have no a priori knowledge of the value that will actually be delivered. We form hypotheses of the value that is likely to be delivered and then measure the outcome once it has been delivered. Whether or not the data proves our hypothesis, we can use the data gathered to decide our next course of action.

In terms of our organisational design we want to create mechanisms that will look for potential value, gather data to measure realised value. We also need to provide rapid feedback loops that allow realised value to be evaluated so that we can confirm or modify our future priorities.

Efficient Process

Everything else is costly bureaucracy

Bureaucracy

IT organisations traditionally run projects. Projects create rafts of bureaucratic processes so that we can establish budgets, monitor expenditure, track time spent and allocate capital and operational expenditure appropriately. These processes are made complex by the relatively short-lived nature of projects.

It is precisely this transient nature of projects that creates unnecessary cost. Not only are there layers of bureaucracy, but the short-termism associated with projects means that we will fail to create the environment for the emergence of high performance in teams. Short-lived projects means short-lived teams that are often changed in a dynamic way as the project proceeds. Project teams are typically short-lived, unstable and unintegrated.

Obviously we can’t do away with bureaucracy altogether - organisations have a legal duty to track expenditure, for example. But perhaps there are simpler models?

If we have stable, integrated, long-lived teams then we can make very clear projections of the run-rate of the team. If these teams work consistently on a product, then it is likely that the split of work between capital and operational expenditure will remain stable for appreciable periods of time. This means we can radically simplify the way we monitor expenditure. Who knows, we might even do away with the curse of timesheets?

Scaling

But not everything is stable. Sometimes we do have to scale our work beyond that which can be managed by a single, small, stable, integrated, long-lived team. Again we need to focus on the most efficient way to scale our work. The problem we need to solve is getting multiple teams to collaborate together on a single problem. There’s the key. 

The problem is represented by a single backlog. All of the teams working together must be capable of completing any item from the backlog. Now, the collaborating teams can choose the smallest, simplest set of activities necessary for them to be able to collaborate on the work and to resolve dependencies. Which leads us on to the need for autonomy. .

Autonomy

Only when we give teams autonomy do we give them the opportunity to consistently improve their ways of working. Only when we have stable, long-lived teams can we give them the opportunity to apply the lessons they have learned to their future work. We can only give teams real autonomy when they are integrated - so they don’t have to rely on other teams to complete their work.

Getting Organisational Design Right

So, what’s the lesson from all this?

We need to start with why - what is the vision that we have for undertaking the organisational design? 

Then we need to think about the fundamental characteristics we are trying to induce in the organisation. What principles are going to underlie the structure and culture of the organisation? 

If we want to deliver the best value from our organisation, then a focus on a clear understanding of where value comes from can help us to establish the goals of the organisational design.

For me the critical principles that can drive great organisational design are:

• Teams at the heart - that’s where value comes from

• Enabling high performance - so we get the best from everyone we employ

• Guided by customer value - so we get our outcomes and priorities right

• Efficient process - so we are productive and minimise the cost of bureaucracy

Now, how deep does my management hierarchy need to be?