No man is an island, entire of itself

Imagine a red balloon full of air floating in front of you. Floating peacefully, going nowhere, which is fairly typical behaviour for a balloon.

Invisibly the individual air molecules are moving at several hundred metres per second.

But the balloon sits still.

At times, discussion about engineering improvement feels a bit like this. How can we get more output from each engineer? Will AI make your best engineers produce more code? How can we make those molecules move faster?

But throughput – the amount we produce – is not a good measure of success. Nor is velocity – that much-loved Agile measure of the complexity of the work we believe we completed. Measuring our hours at the office isn’t great either. They have their uses, but are all assessing how busy we are.

The balloon sits still because, however fast the individual molecules are moving, they are acting independently.

Jeff Sutherland fell into this trap with the title of his 2014 book “Scrum: The Art of Doing Twice the Work in Half the Time“. And no, that’s not a fair criticism of Scrum, or the book. Just of the title, which was memorable but unwise. The choice of title shows how much increasing output is an easy sell.

Optimising the volume of individual production may sell books. Attributing success to individuals is also loved by some managers as it promotes the idea of “measurable performance”. But it doesn’t lead to success.

As John Donne says, no man is an island.

Building bridges

If our employees aren’t to be islands, we need to make sure they are connected to the mainland. They need to be part of a team. And a team works together towards a common goal (where a “group” may just be a collection of individuals operating independently).

To work towards a common goal, there are a number of sharing activities which individuals cannot perform for themselves. These act as “bridges” to the wider team. We might group these into categories as below.

• Interpersonal roles.  These might include coaching and development, mentoring and liaising with those outside the team.
• Informational roles.  These include representing the team, sharing information and giving feedback.
• Decisional roles.  These include proposing change, unblocking problems, supplying needs and negotiating for resources.

These categories are based on work by Mintzberg, who observed that these were the activities where management were spending their time. In Mintzberg’s model, this is what management is – the set of activities which, like a spider’s web, binds individuals into a wider organisational structure.

Scaling the bridges

I prefer to view these linkages from the viewpoint of the developer. To function within a broader context, the individual needs to be able to draw on these capabilities which “bridge” to the wider team and beyond to the organisation.

Traditionally, these functions are supplied by “managers”. In Taylor’s “Scientific Management” approach, there is deliberate separation between the “doing” functions of the workers and the “linking” functions of the managers.

Traditional management maximises the individuality of workers. It promotes individual objectives, individual performance assessment and individual reward or punishment. This is done by separating non-individual activity, as far as possible, into “management”.

As an organisation scales, this becomes harder. There are more cross-linkages and more dependencies. More management is needed and organisations become more hierarchical. Escalating decisions becomes too slow and loses too much information. We hit what Greiner refers to as “the crisis of red tape” in his paper “Evolution and Revolution as organizations grow”. Well worth a read if you have never done so.

Cross-functional teams

Taylor’s Scientific Management separates management from individual working. There is an alternative approach, which is to integrate the two. Where individuals are unable to support themselves, teams can do so.

We could pull management away from individual working as Taylor suggests (and as many organisations choose to follow). Alternatively, however, we can integrate the two to form self-managing (or self-organising) teams.

The best architectures, requirements, and designs emerge from self-organizing teams

Principles behind the Agile Manifesto

But how does “self-management” fit with Mintzberg’s ideas of “management” above? Clearly the more that the team “self-manages”, the more of those management functions must be integrated within the team rather than separated to external management.

The solution here is the adoption of cross-functional teams. An individual is limited to his or her own capability. A well-designed cross-functional team allows the team as a whole to support each of the individuals contained.

Let’s look back at Mintzberg’s categories in the light of cross-functional teams.

Informational needs are significantly reduced because the dependencies outside the team are reduced. A cross-functional team can minimise dependencies and be more self-sufficient.

Many of the decisions can also be taken by the team. Escalating decisions is slow and inefficient and a result of externalising management. It is far less necessary if the team has the skills and knowledge to make those decisions themselves.

External management can then move to function at a much higher level – coaching, mentoring and giving some strategic direction.

Role of the business

Organisations find scaling through self-organising teams to be a huge challenge. At one level it is very simple, as suggested in the Agile Manifesto.

“Agile” change is typically applied only within the engineering teams. And yet scaling applies to the organisation as a whole. This needs a much more extensive interpretation of “cross functional” than mixing front-end and back-end developers with some test experts.

In “The New New Product Development Game“, Takeuchi and Nonaka talked about self-organising teams operating with a high level of independence. What the authors realised is that this is not just about how developers work, but the implications run far wider.

A key step is to integrate the market facing part of the business with the development part within the same self-managing unit. Scrum took a strong move in this direction with the concept of a “Product Owner”. As the name suggests, this was intended to allow the team to own the product and the decisions around it. Team autonomy extends to embedding that ownership within the team.

However, organisations have struggled with this integration and its clash with traditional management roles. This ownership role is rarely implemented as described, and instead is diluted in a way with disempowers the team, forcing decision making to reside outside the team. Look for example at the rewrite within the more traditionally-oriented SAFe framework. Now the Product Owner no longer has ownership, but only administration.

Part of the challenge is that we have moved from individuals to teams, but the Product Owner again falls into the trap of individuals. The Scrum Guide explicitly rejects the idea that the team’s cross-functionality extends to sharing ownership of the product.

It is far more important for the team to adopt Product Ownership.

Scaling to shared ownership

Distributed product ownership can scale far more easily as the organisation grows. If the team becomes accountable for the product and its success or failure, we move to a “microenterprise” model.

Let’s look at how this is described by Zhang Ruimin, CEO of Haier, who migrated the entire organisation to a microenterprise model which they refer to as “RenDanHeYi”. Here the power of the team is focussed wholly on value, not on volume of output. This forces a complete rethink of traditional externalised management.

An organisation can move beyond the Scientific Management approach. It then scales by delegating more management to the teams. The end point could be a microenterprise view, where the teams define and pursue customer value directly.

The challenge is that this requires management to have the confidence to delegate these functions. Many organisations struggle with this level of delegation. Zhang Ruimin is clear on the impact of this.

This is the point at which many organizations falter. Management need to take a bold step to delegate true ownership to teams in order for the organization to scale effectively.