Saving teams from the failure culture

The unit of delivery in a risk managed culture is a cross functional team. How do you create value delivering cross functional teams?

Photo by Randy Fath on Unsplash

The diagram below displays the most common organisation I have encountered for a system. Teams focused on one part of a system are referred to as component teams. Each valuable delivery requires work from the input, logic and output team, and a project manager is needed to allocate and track the work. Although the output team may be able to deliver business value independently, it is likely that any change involving the logic and input team will also require work in the output team, even if it is only testing.

A shift from Inward Looking to Outward Looking

A common pattern for this structure is that each team contains one or more business analysts who are assigned functionality to deliver. The business analysts in the input team of an accounting system asked me to review some stories they had written for a change to the mapping logic. The mapping determined where values contribute to the line on the output report. The new mapping meant that values on one line were being split, with some of the values being moved to another place. For example, comic books are currently mapped into “Toys” but going forward any comic books worth more than $100 are mapped into “Investments”. The business analysts had created stories to explain how mapping values needed to be changed, and the functional changes. They described the changes in the rules. It is rare to find stories that clearly describe the business value and these stories were no exception. As always we start by understanding how the change is perceived by the user in the output of the system.

With comics worth $1500 of which $500 worth are worth $100 or more, and bonds worth $2000, the system would currently display:

  • Investments: $2000
  • Toys: $1500

With the new rules, the system would display:

  • Investments: $2500
  • Toys: $1000

Now that we were looking at the requirement from the perspective of what the user would see rather than simply the functionality to change, we could ask what needs the user would have. The users were accountants and one of their key needs is the ability to evidence any changes to the accounts. Simply changing the rules would not satisfy that need. Either the accountants need to run the rules, take a hard copy of accounts, change the mapping and rerun the rules, OR they needed a report that showed the accounts before and after the rule change. For example:

Date of mapping change: 1/1/2022

Mapping change:

  • Old mapping: “Comic” mapped to “Toys”
  • New mapping: “Comic” worth less than $100 mapped to “Toys”, “Comic” worth more than $100 mapped to “Investment”


  • “Toys”: $1500 changed to $1000 <Click here for detail>
  • “Investments”: $2000 changed to $2500 <Click here for detail>

By considering the “requirement” from the perspective of the accountants, we discovered that the proposed solution to be implemented did not meet their needs and was incomplete. In order to deliver something of value, not only did the logic and output teams need to do testing, they also needed to add significant functionality. The business analysts admitted that they had already made the change and it had been stuck in user acceptance testing for months as the users would not sign it off.

The first rule of creating teams is that they should be cross functional. The team should contain all the people needed to deliver value as perceived by the user. These teams are referred to as feature teams. This indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.

The second rule is that each team needs a product owner. A product owner is someone who understands the needs of their customers, whether those customers are external or internal, human or another computer system. Product owners need to understand customer value and how that leads to business value, and as such they are outward looking (h/t to Scott Zebedee). Traditional roles like business analyst tend to be inward looking with an understanding what needs to be done to produce output but not necessarily understand the value of the output to the customer and the business. This also indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.

Typically each product owner will work with one team. Occasionally an experienced product owner may work with two teams but this is such a demanding role that an individual adopting the role for the first time should never work with more than one team.

Teams that deliver value rather than functionality?

When forming teams, we need to consider the VALUE that they are going to be delivering over the long term. To understand the value to be delivered, we look at the book of work (which will eventually be replaced by a roadmap based on metrics) and identify which teams will need to do work for each piece of value delivered, not which teams will need to make code changes.

EpicMetric ImpactInput TeamLogic TeamOutput Team
Regulatory changeRevenue at riskYYY
Accounting rules changeRevenue at riskYYY
New mappingsRetain customersYYY
Ads from third partner serviceNew RevenueNNY
PerformanceRetain customersYYY
New customer on-boardingNew RevenueYNN
Migrate to CloudReduce CostYYY

It is clear that most of the work requires a team that can work on all three components. The work with Ads integration may not need work on all three components but if its a small piece of work there is no justification in having a separate team. The new customer on-boarding may justify a focused team if there is a lot of on-boarding work. The performance and cloud migration may justify a separate team if a lot of work is to be done over a long period of time that does not require work from the other teams.

The result shown in the diagram below would be several feature teams that cover all three components, an on-boarding team that has specialist client handling skills (purple man) and a specialist performance team to improve the performance metrics of the system. The goal is to form the teams so that about 80%-90% of the work they do can be done as a single team without having to work with another team on this system. The key point is that they are stable long term teams with a stable long term mission. The stable long term mission in this case might be business value, performance or on-boarding. The product owners for the performance and on-boarding teams may be people in the “grey” technical lead or project manger role.

At Skype, this group of cross functional teams was called a release vehicle or RV, something that could release value independently of other teams. The number of teams depended on the amount of work that the executives expected they needed to achieve strategic goals. Mark Gillett told us the unit of investment is the team. The quarterly capacity planning was used to refine the number of teams in each RV, with the creation of a new team, moving a team to a new RV or temporarily shifting of a team to a different mission. The teams were moved rather than individuals ( Note that the Skype model only had feature teams, not the specialist on-boarding and performance teams mentioned in this example. )

Anti-Patterns of team formation.

There are a number of anti-patterns that mean the team is not a not fully cross functional team that can independently deliver value.

  • Missing skills – The team is formed with only some of the skills that are needed to deliver value. Most commonly, the testing capability is missing from the team and is provided by a central testing team.
  • Missing parts of the Value Stream – As mentioned above, the teams are formed around a component of functionality rather than the entire system.
  • Non-diverse teams – Jim Coplien has done research that shows diverse teams out-perform non-diverse teams, especially if there is a mixture of men and women on the team.

Another common mistake is to split the teams so that some focus on the delivery of customer value (business facing) and some who focus on code quality (Automated Test Coverage, Clean Code, DevOps). This creates a culture where the customer value teams do not care about code quality. As the teams are funded rather than the projects, the code quality teams are the ones most likely to be unfunded in a review by the business investors.

If you have experienced other anti-patterns, please share in the comments.

So the conclusion is to form teams based on value rather than functionality, with product owners that are outward looking at customers and business value rather than individuals that are inward looking at functionality. The next blog will describe how to get the teams to the right size using a skills matrix.

Thank you to Scott Zebedee for helping me with the inward looking / outward looking concept to explain the ideas in this post.

How the failureship destroys teams

The unit of delivery in agile is the long lived cross functional team. Rather than individuals struggling to perform their allocated tasks, a team takes responsibility for delivery of work items that deliver value. The team work together to deliver value for the customer, supporting each other to perform tasks, and learning new skills to become “T” shaped. Each team contains between five and nine people. The failureship, especially the frozen middle, act as a serious impediment to the formation of teams, and will destroy teams if they form.

Photo by Shane Devlin on Unsplash

The most common organisational design to support a single system in a failure culture is shown below. It arises out of a desire to reduce costs and use expensive low cost developers that can quickly come up to speed. There are separate “teams” who look after Input, Logic, and Output (ILO). Similar anti-patterns include the Front End, Back End, and Database (FBD), Business Value, Support and Refactoring (BS Refactoring), or Development, Operations, and Testing (DOT). The net effect is that several teams are required to deliver anything of value to the customer. Each of the “teams” will contain any number of people from one to one hundred and beyond.

Each sub-system has a individual shown in Grey who acts as technical lead / architect / component lead / sub-system manager (line manager). This person is normally from a developer background rather than a project management background. Their power comes from having a holistic understanding of the component that they lead, especially an understanding of where the technical debt is hidden or “where the bodies are buried” as it is also known. In effect they have a skills matrix inside their heads where no one else can access it. In order to deliver anything of value, several teams are always needed.

This is not considered a problem because a Project Manager pulls it all together into a deliverable. They take named individuals from the team and form a short lived team (called a project) to make the deliverable happen. The individuals are not part of a real team and are solely responsible for making their part of the deliverable happen. The Project Manager works closely with the Grey who allocates the “resources” to the project manager.

The good news for the organisation is a dog eat dog hero culture will emerge, but the bad news is there are a lot of key man dependency (poor skill liquidity). In reality, apart from the Grey, the developers in each of the teams are not skilled in all aspects of the sub-system and each developer has part of the sub-system that is “theirs” which maximises job security.

Where the delivery of value involves more than one system, a program manager is required to manage the deliverable from the project managers.

A shift to a team based culture would result in an organisation design as shown below. Each team has all the skills necessary to deliver end to end value. ( How to form the teams will be discussed in a later blog post. ) The “Grey” roles would disappear, as would the project manager role as teams took responsibility for their own work. Long lived teams teams of five to nine people would work together and collaborate, sharing knowledge and skills. Although the long term team size is five to nine people, during the formation of the teams, larger teams may form to facilitate the transfer of skills and knowledge (possibly using a skills matrix to assist) before splitting into more appropriately sized teams.

Where more than one system/team is required, the teams would form a scrum of scrums to facilitate the delivery of the value. Where the same teams are coming together in a scrum of scrum over and over again, the teams may merge for a period and then split into two or more teams as appropriate.

In addition to this delivery structure, the organisation may implement the chapter from the Spotify model. The chapter lead acts as line manager for the individuals with a particular skill set to ensure personal development and alignment of skills. Historically this need for personal development lead to the development of departments and silos (Source: Marc Burgauer).

We need to talk about Kevin

One of the biggest challenges for an organisation looking to move to a team based model is what to do about the frozen middle failureship… the Project Management Organisation (Project Managers, Program Managers, Portfolio Managers and PMO) and the “Grey” role. In order for the new organisational design to emerge, the frozen middle failureship must disappear. Whilst they exist, the project based model will persist. The frozen middle has more power than any other group to make things happen, or prevent them from happening. They can easily force any transformation into failure, and they often do. Simply put, the transformation shifts power and responsibility from the frozen middle failureship to the teams. The frozen middle often resent the loss of power, and the teams are often fearful of taking up the responsibility.

The frozen middle anti-pattern

The easiest way to spot the resistance of the frozen middle is in the organisation structures. The frozen middle suggest an intermediate step to the formation of teams as shown below.

The executive failureship cave in to their suggestion because any changes they want to happen either happen through them, or the failureship need to lead the teams to do something that some of them do not want to do. This structure reinforces the roles of the frozen middle failureship, retaining their power base, and prevents the need for the teams to step up and take responsibility. Project managers and “Greys” continue to allocate individuals to projects and nothing significant changes as the teams are not really acting as teams.

All that happens is a cosmetic change of the organisation hierarchy at the bottom of the organisation, possibly with the introduction of addition layers of management (more frozen middle)

I have experienced this failure to remove the frozen middle failureship in several organisations. Normally because executive failureship was either too scared of the frozen middle failureship or because they were not really committed to improvements in the organisation.

An alternative to this structure is the adoption of the SAFE framework with its roles that preserve the frozen middle failureship.

Dealing with the Frozen Middle Failureship.

Removing the frozen middle failureship roles does not necessarily mean removing the individuals from the organisation. Often the individuals in the frozen middle failureship are some of the most effective individuals in the organisation at doing things and getting things done.

It is important for individuals to choose a new role based on invitation rather than be assigned a new role. People who are assigned a new role will almost certainly continue to behave as they did in the old role. Asking a project manager to manage in an agile way will result in no change in behaviour.

This is likely to need an organisation wide change. If the technology group make this change but the “business change” group do not, it is likely that a rival organisation will emerge to manage the new way of working during the period of uncertainty and change. The leadership will need to build alliances across the organisation to shift the organisation from one controlled by the frozen middle failureship to one based on self discipline and teams with lightweight (Scrum of Scrum) coordination.

At one organisation the transformation started with the leader of the company sacking all forty project managers in one go. I joined shortly after and the stories told lead me to believe that sacking the project managers en-masse was a mistake. In that organisation, a healthy product owner organisation emerged that truly lead the development of the product based on customer focused metrics. The development teams took responsibility and pride in their work. We eventually re-introduced the project manager responsibilities as a scrum of scrum master responsible for facilitating cross team development, and with none of the power. It was one of the most impressive organisations I ever worked in.

At another organisation the project managers were given the choice of either becoming a developer, a scrum master or leaving the organisation. Combined with other changes, the result was a 50% increase in productivity.

Subsequently I have worked in several organisations where the frozen middle failureship was allowed to remain intact. The project managers played lip service to change, with agile theatre, and an appropriation of agile terminology but no change in behaviour, and no real improvement.

For many years I thought the wholesale sacking of the frozen middle or forcing them to chose between a new role or leaving damaged the organisation was wrong. I WAS WRONG. I now believe that any transformation that does not actively dismantle the power base of the frozen middle failureship is doomed to fail, It will simply introduce agile theater. The leaders in the two companies above were courageous in the changes they made but that is because they did the research and built their own experience rather simply rely on the recommendations of experts. They owned the changes and ensured their success.

Where do the frozen middle go?

As I mentioned, many of the individuals in the frozen middle failureship are brilliant. They just need to do a different role. They need to give up control of the allocation of work to individuals and making commitments on behalf of other people.

So what are the roles that they could move to?

The “Grey” role has many options due to their deep technical knowledge:

  1. Product Owner – They could become a product owner who focuses on delivering value against technical business value metrics ( Performance, Lead Time, Through put, MTTR etc. ).
  2. Lead Developer / Developer – Nuff said.
  3. Chapter Lead – Line managers responsible for the development of other developers.
  4. Architect – Trusted advisor to the product owners, writing technical user stories.

The project managers similarly have many options:

  1. Product Owner – They often have the closest relationship with the customers.
  2. Scrum Master – Nuff Said
  3. Scrum of Scrum Master – More in a later post.
  4. Developer
  5. Chapter Lead for Scrum Masters

Most of the agile roles are based on facilitation rather than command and control. They require relationships that are adult-adult rather than parent-child. Some people find that idea scary and they may chose to leave the organisation for that reason, or for some other reason.

If your organisation claims to want to be team based, look at the structure of the teams and the behaviour of the middle management. If you see the anti-patterns mentioned above, know that it will be theater rather than genuine change.

Failureship and the Parent-Child Relationship

Organisations need to move from Leader-Follower to Leader-Leader relationships according to David Marquet’s book “Turning the ship around”. This is very similar to Eric Berne’s transaction analysis which describes Parent-Child and Adult-Adult relationships. Dysfunctional workplace relationships are often when one of the people acts as a child and the other acts as a Parent. Some people move into a child role, pushing the other person in the parent role, or some people move into a parent role and the others adopt child roles accordingly. Many years ago a policeman friend of mine said that the secret was to always stay in the adult role, forcing the other person to adopt the adult role. This is much easier to say than do.

Eric Berne’s Parent-Child best describes relationships between the failureship and the workers in failure cultures, and Adult-Adult best describes relationships between leadership and workers in a risk managed culture.

The key point is that the relationship is a dynamic between individuals. It is very common to find the Parent-Child relationship in failure cultures and less likely to find it in a risk managed culture. One of the challenges for organisations moving from a failure culture to a risk managed culture is the move to adult-adult relationships. This is hard because the first party to move to the adult role has to deal with individuals still acting in either the parent or child role. If a leader moves to the adult role, they have to deal with individuals who remain in the child role and oppose taking responsibility for their own work. If the workers move to the adult role, they still have to deal with leaders in the parent role who continue to treat them like children.

As well as moving to adult-adult relationships, it is just as important to stay in them and guard against automatic responses that create the parent-child relationship. Many years ago I worked on a system where each release required the whole team to stay late on a Friday night. We would perform a release after business closed on a Friday at 5pm. The system would be run and a standard set of reports would need to be checked. The management introduced a ban on food for people working late, probably because a number of employees were in the habit of working until 9am to get a free dinner. The team were unhappy and so I met with management to explain the situation. Dinner would cost between £100 and £200, however half of the team were contractors who could rightfully demand overtime payments or refuse to work as it was outside their contractual hours. The contractor’s overtime payments would cost thousands. An agreement was reached on how to control the costs for this and future releases, and the team got their “free” meal. The team approached this perceived “parent” move as “adults” seeking to understand the needs of management as well as articulating their own. Alternatively the team could have taken the “child” approach of being naughty, getting one of the contractors to claim an extra half day for unworked time to pay for the food, or using bogus taxi receipts to pay for food, or “buying” computer equipment. The “child” approaches all destroy trust when discovered and lead to stronger parent-child dynamics and more bureaucracy and controls. More insidiously, they erode the ethics and values of the organisation as the “child” is taught that fraud is acceptable.

The adult-adult and parent-child lens is particularly useful when thinking about responsibiliy and discipline. In a risk managed culture the workers take responsibility for their own work and act with self imposed discipline. In a failure culture the workers may act without discipline and fail to take responsibility for their own work which forces the failureship impose discipline and take responsibility for things the workers should own and impose discipline. Alternatively the failureship take responsibility away from workers, and impose discipline which results in workers either leaving the company or those that stay abdicate responsibility, relying on the failureship to impose discipline. In failure cultures, an entire parasitic structure emerges to impose discipline which opposes the emergence of self discipline. Even though the leaders in an organisation might want to move to adult-adult / leader-leader relationships, they will be undermined by the project managers, programme managers and PMO whose only purpose is to impose discipline, and whose only goal is to survive.

UNLIMITED work in progress

One of the most effective strategies that the failureship deploy to justify failure is the concept of UNLIMITED work in progress. The failureship justify Unlimited Work in Progress by stating that they are “making efficient use of resources”, “getting a lot done” or “sweating the asset”. They know that the ultimate crime is letting anyone sit idle and “slack off” at less than 125% utilisation.

UNLIMITED work in progress is a most effective strategy for avoiding focus and justifying failure.

Photo by Jéan Béller on Unsplash

Most agile/lean/buzzword/digital transformations require the organisation to deliver value with high quality, and with lower lead time. These are challenging goals, requiring genuine change with focused commitment from the leadership. If the leadership focus on these goals, it requires them to understand their context and make changes that will impact their organisation. The problem with these goals is that are they are hard to achieve and it obvious whether the organisations has improved or not. To prevent this level of transparency, the failureship deploy the “Unlimited Work in Progress” strategy. Instead of three meaningful goals, the failureship will create dozens of goals for the organisation. By creating a large number of goals, teams can pick those goals that they find easiest to achieve and ignore those that actually improve things but are hard to do. Ideally, these goals should be cherry picked from those espoused by industry experts.

At one organisation we developed a test for the maturity of transformation programmes. We suggested the three goals (More value, Lower Lead Time, Quality). An additional twenty eight goals were added giving a total of thirty one goals. The transformation programmes ALL scored twenty eight out of thirty. Guess which three goals none of them achieved.

The next organisation had a set of about two dozen random “industry” goals. I suggested to the person responsible for the goals if we could just focus on just two goals ( “How much of the investment is invested against a metric”, “How much of the investment has a lead time calculated” ). Instead, they told the executives that their organisation needed to “focus” on the two dozen goals. Leadership is about providing focus for an organisation so that it can succeed. Overloading an organisation provides it an excuse for failure, and also demonstrates that the failureship have done a good job by being a “strong and demanding leader”. Of course, when the goals are reviewed, none of the executives will have made any valuable progress but they will have the excuse that they had too much to do.

Unlimited Work In Progress is a fantastic strategy to avoid blame for poor decision making. The failureship instruct a team to do ten things, even though they only have the capacity to do two things. The team obviously fail to achieve the ten things but even worse, they fail to achieve two things because they do a little bit of all ten. The failureship then promote the team leader for their failure to deliver anything which would have revealed their poor decision making if they delivered the wrong thing. I worked on a project with a consultancy company called “Negligensure” (Its not an accident). The business product owners did a great job of providing thirty slices of value (epics) and asked the consultancy provided teams to deliver. The “Negligensure” lead ignored the product owner and decided to create a proof of concept instead, effectively starting all thirty epics at once. This allowed them to hide the fact that the teams did not have the skills to deliver a single epic. It also meant that the project had no effective way of tracking progress given the huge amount of work in progress, none of which made it into usage until months after the deadline. The failureship were delighted as they genuinely had no idea what was going on and could not be blamed. I think we all know the result, the failureship rewarded the consulting team with a bigger follow up contract. Big name consultants are world class experts at deploying “unlimited work in progress” to hide their lack of ability.

Nothing frustrates the failureship than limiting work in progress. Limited WIP forces them to focus, revealing problems that should be solved, and revealing the work that they think is most important. Limiting work in progress forces the failureship to acknowledge that which is most important to the organisation and makes it hard for them to focus on things that are best for their own personal career progression. When encountering an organisation limiting work in progress, members of the failureship should declare “slackers!” And double, quadruple or 10x the work being done.

This Christmas, give your failureship the gift of “Unlimited Work in Progress”, the comfort blanket that prevents focus and provides the perfect excuse for their failure.

Why failure cultures hate Agile.

We have been discussing failureship for many years. It has helped us understand motivation, and helped us predict the behaviour of individuals and teams in a failure culture. One coach contacted me to confirm one of our prediction. They were helping teams implement a new technology in the organisation. Even though the technology was VERY well established, the way it was implemented in the organisation was unique to the organisation. They shared an exchange with the team:

  • Team: “How do we implement this new technology?”
  • Coach: “We will work together closely, creating a number of safe to fail experiments to discover the best way to implement it given the constraints imposed by the organisation.”
  • Team: “Not acceptable. You need to send us an e:mail detailing exactly how we implement it. We will implement it exactly as you specify. If it fails, it is your fault!”

And this is why failure cultures hate Agile…

Agile processes and practices are NOT solutions, they are the simplest thing to help you find the problem you need to solve in order to succeed.

Photo by engin akyurt on Unsplash

Over many years, agile practitioners have shared their solutions to problems they have encountered. Over time, the number of potential solutions has grown and expanded. Some problems are frequently found in many contexts and the associated practices are considered core even though they are not necessarily mandatory. A classic example is the definition of done and definition of ready. High performance teams often operate without an explicit definition of done and ready, only formally recording them when a new product owner or senior developer starts working with the team and challenges the status quo. Being aware of the context on where to deploy an establish solution, or experiment with a novel solution requires a great deal of experience. This is why the pre-requisite for a coach is lots of experience and a network of coaches that they can reach out to discuss problems. This huge toolkit of contextually specific solutions within a lightweight framework often gives people the illusion that agile is a solution. In reality, the value of agile is the simple frameworks, or scaffolding, that help teams identify problems they need to solve to be successful:

  • Test Driven Development is a scaffold that allows a developer to spot a problem with the solution they have implemented. It does not tell the developer how to fix the problem, only that there is one and its precise location. This is particular useful for developers changing existing software that they are unfamiliar with… like code they wrote a month ago.
  • Scrum is a scaffold that forces the team to develop a solution within a regular time box. If they cannot deliver, they become aware of the problem to be solved. e.g. If they cannot deliver because testing takes too long, they need to speed up testing.
  • Kanban is a scaffold that uses queues to identify bottlenecks and a mismatch of capacity. Kanban does not tell the team how to fix the bottleneck, only that it exists and where it exists.

In each case, the agile framework shows the team what the problem is, and the team has to figure a way to solve the problem according to their context. This is anathema to a failure culture where they want to be told detailed instructions on exactly how we implement it. They want to implement it exactly as specified. If it fails, it is someone else’s fault!

Scaled Agile requires organisations to solve very context specific problems. The capacity planning framework that we developed at Skype and subsequently implemented at several organisations is an example of an agile framework that shows organisations the problems that they need to solve. It adapted to the organisation and several different solutions emerged. In one case, the problem it revealed could not be solved and the organisation became stuck, having to focus on other lesser problems. Capacity planning is an agile process because it helps the organisation identify the problem but does not tell it the solution. It tells the organisation that it needs to order the backlog but does not tell it how to.

The failureship do not want a framework to reveal problems that they have to fix. Instead, they want a solution that they can blame when it fails to deliver. This is the space that SAFE and LESS occupy:

  1. Safe aims to be a solution to the scaled agile problem. It does not help the organisation understand the problems it needs to solve. Instead it provides a prescriptive “there is only one safe” way to do things. Safe provides a number of roles that reassure the existing power structure that they have a place in the new world without having to change their behaviour, your project managers get to becomes Agile Release Train Managers. The good news with SAFE is that tens of thousands of consultants at the big five have sent their consultants on the five day training course. The primary goal of Safe is to allow the failureship to say that they are agile because they have implemented Safe, not because they have improved the organisation.
  2. LESS is a solution that only works in certain contexts. In one of the earliest implementation of LESS, it was implemented in two locations in the same department in the same organisation. In one location, there was group of highly motivated developers who were advocates of agile practices and principles. In this location LESS was a huge success and resulted in a 50% increase in productivity. In the other location, the developers had been involved in several rounds of redundency and saw holding onto knowledge as providing job security. LESS succeeded in one but failed in the other because it is a solution that does not adapt to the context. The managers of the department eventually deployed another solution where LESS had failed to deliver the benefits it promised.

Neither SAFE or LESS are agile frameworks because they are solutions rather than a mechanism to identify problems.

The failureship love solutions because they get to blame the solution when they fail. They love LESS and Safe because success means implementing them rather than fixing the problems they need to solve. The failureship hates agile because it reveals problems they often cannot solve, or do not want to solve.

Failureship deliver things instead of value

The failureship deliver things rather than value. The successful delivery of things is normally under the control of the failureship, whereas successful delivery of value is often outside of their control. A common behaviour-plex observed in failure cultures is a tendency towards delivery of things instead of value. The form of the behaviour-plex is as follows:

  1. A senior executive decides they want to develop a strategic solution. To justify building the solution, they create a robust business case declaring the delivery of massive value that will be delivered in several years time.
  2. The investment starts and value is never mentioned again. No one ever goes back and validates that the agreed value is delivered.
  3. As there is no feedback mechanism to validate the value is delivered, completion of the investment is subject to the opinion of senior executives who have a vested interest in declaring success.
Photo by Torsten Dederichs on Unsplash

When an executive or manager instructs a product owner what to build, the product owner has no responsibility for the impact of what is built. They can only act as a delivery manager, and the executive should take full responsibility for any failure to deliver business value.

An alternative variant of this behavior-plex is as follows:

  1. Someone identifies a metric that should be improved. For example “The number of customers defecting to the competition”.
  2. An investment is agreed to improve the metric.
  3. The team perform an analysis and decide that the best solution is to build a “widget”
  4. Based on the analysis presented, the executives agree that building the “widget” is the best solution. The team get an agreement from the executives that the goal is now to build the “widget”.
  5. Value is never mentioned again.
  6. As there is no feedback mechanism to validate the value is delivered, completion of the investment is subject to the opinion of senior executives who have a vested interest in declaring success.

The key point here is that the executive(s) have control over whether an investment is deemed to be a success. This success is normally negotiated several times during the investment, always with a reduction of “scope”. Success for the project manager responsible for delivering the investment is more about managing the relationship with the stakeholders than the actual delivery of value.

When an executive or manager agrees on what the product owner should build, they are taking responsibility for the value delivered.

In order for this behaviour-plex to work, there needs to be a large power distance between the team and the executives so that the decision cannot be challenged. The executive needs to be powerful enough to dictate reality.

The risk managed approach is as follows:

  1. A senior executive decides they want to develop a strategic solution. To justify building the solution, they create a robust business case declaring the delivery of massive dollar value that will be delivered in several years time.
  2. A product owner (team) is assigned to the product. They immediately try to understand the value of the solution to the customer and the business. They establish the metric that will be used to determine the success of the project and agree that with the executives. The metric is one that is either measurable or will be measured as part of the product initiation.
  3. As the original robust business case had a dollar value, the product owner (team) can now agree the initial exchange rate between dollars and the success metrics. The exchange rate or financial impact of the improvement is the responsibility of the executive team.
  4. The product owner (team) now understand the value of moving the metric and can focus on understanding the (internal or external) customer needs to be met in order to move the metric. Responsibility for moving the success metric sits with the product owner (team). They should be completely empowered to ignore the strategic solution suggested by the executive.
  5. The product owner (team) should meet regularly with the executives to reflect on the progress at moving the metric, whether the metric is still the correct metric, and whether moving the metric is having financial impact that the executive team stated it should. Success is about moving the metrics, it is not about implementing a solution. The executives cannot declare success if a solution is implemented but does not move the success metric or achieve the financial goal.

At Skype, Yuval Dvir and his team introduced a formal mechanism where every month the Product Owners would meet with the Product Executives for a formal discussion of their metrics. Every quarter the Product Owners and Executives would discuss the metrics with Mark Gillett, head of Skype. Yuval built a dashboard at Mark’s direction that showed all of the available metrics in a single place.

This process to formally review metrics was separate and distinct from the quarterly capacity planning session that was used to build an organisational (meta) backlog. The discussions in the review process had a significant influence on the discussion in the capacity planning as they were about the same metrics.

When a product owner asks executives if they are building the right thing, the executive can share an opinion but they should make it clear to the product owner that they are still responsibility for moving the metric.

When an executive pushes a product owner to “build a feature”, the product owner should push back if it will not move their metric, or alternatively get the executive to agree a new metric.

Whereas the executive cannot chose the solution that will meet the customer need and move the metric, they should ensure that the solution is coherent with the success metric. It is common for “product owners” to claim their solution will move the success metric simply because they want to build a particular feature. For example, claiming that adding adverts to an app will increase engagement because the organisation wants to focus on engagement rather than revenue. This means the executive should challenge the proposed solution if it is not coherent with the outcome (metric).

Focusing on metrics instead of things pushes responsibility for success to the product owner (team) in a manner aligned with the goals of the organisation. Specifying success as moving the metric allows the product owner (team) to innovate in the way that it is achieved.

We need to talk about failureship.

Reading these failureship blogs, you may be mistaken into thinking that I am critical of individual leaders. The very name “Failureship” is deliberately provocative by design. The purpose of these blogs is to draw attention to the fact that individuals in a failureship role in a failure culture are actually part of a behaviour-plex where their behaviour and the behaviour of others form reinforcing (negative) feedback loops. These behaviours have been established over decades of stable market conditions, often learnt from successful leaders in a different time. Leaders are keen to introduce beneficial change to their organisations but they are unaware of how their own behaviour undermines their own best intentions. Without an awareness of failureship, leaders will continue to trip over their own shoelaces and fail to introduce change.

Photo by Shelbey Fordyce on Unsplash

Leadership is hard, and it is particularly hard for the current generation of leaders. We are experiencing a period of massive change in all aspects of life. Most of our leaders grew up in a period of relative stability and learned how to be a leader from those around them, people who were successful and effective. The behaviours that lead to success in the past no longer lead to success in the present.

These blog posts share my observations so that we can start a conversation about leadership and failureship. Fundamentally changing the culture of an organisation requires leaders to do new things, and as importantly, they need to understand that they need to change their behaviour, and put a stop to doing some of the things they do and put a stop to things that others do. A conversation needs to take place with those leaders who are “doing it”, leaders need to share stories with each other so that we can build a new approach to leadership and cultural change. Leaders are desperate for help which is evidenced by the fact that they are buying snake oil by the gallon from the “Communities of Solutions”, believing that training and certification in pre-packaged context free solutions will do the hard work for them.

As Mark Gillett noted, these posts are ethnographic studies of organisations. They are ethnographic studies of organisations performed by someone who is not trained in ethnography, probably more like the observations that a tourist might make when visiting a foreign or different culture. They are observations that have been filtered through my own understanding of reality and as such they should not be considered as fact and instead as an initial hypothesis that point towards more experimentation. The hypothesis about the behaviour of individuals in an organisation is as advanced as the belief that day and night are caused by a scarab beetle pushing the god Ra across the sky to light the land.

At the NYC Complexity Lounge I was asked to name names, to call out members of the failureship who engaged in behaviour that leads to a failure culture. I said that whilst I was happy to call out the names of leaders in “risk managed” cultures, I would only call out the behaviours observed in a failureship but not the names of the individuals. The goal is not to punish people but rather to learn about leadership so that we can create better organisations. This will be one of the principles of the discussion, there will be no naming and shaming, of either individuals or organisations.

The thought leaders, consultants and trainers who are selling leadership and certification need to step back and give leaders the chance to work out some stuff for themselves. In my experience consultants and trainers selling leadership solutions have little or no empathy or understanding for the real challenges that leaders face. They are firmly in the community of solutions and have no understanding or interest in the real needs of leaders. I recently spoke to a transformation lead and told them of my frustration at taking a year to onboard a new consultancy into a large organisation. They told me they had experienced the same problem. So whilst consultants are selling “Scaled Agile”, “Holocracy”, “Sociocracy”, “Teal Organisations”, “Complexity”, and mainly “themselves”, those leaders engaged in making real transformation happen could really use some help on-boarding consultancies that can provide high quality, cheap, developers.

The Conversation

If you are interested in joining the conversation, please reach out to me on e:mail. If you do not know my e:mail, contact me on twitter ( @papachrismatts ) or linkedin. Alternatively leave a comment either here or linkedin with details of how I can find you. I will send an e:mail to all that are interested so that we can choose the best venue for the conversation. Please note that any thought leader or community of solution attempt to sell solutions ( including themselves ) will result in removal from the conversation.

I look forward to hearing from you.

In the mean time, here are some of the posts to date:

  1. Seeing culture
  2. Presentation at Lean Agile Scotland on “Seeing Culture”
  3. Presentation at Lean Agile Scotland on “Community of Needs & Community of Solutions”
  4. Introducing failureship, the dark twin of leadership
  5. Failure cultures reward failure
  6. aacennprrsty and the failureship
  7. Step away from the office and join the team
  8. Failureship and expensive low cost people
  9. The failureship and turkeys voting for Christmas

More posts on failure culture and failureship will follow…

The failureship and turkeys voting for Christmas.

In some organisations, the individual succeeds if the organisation as a whole is a success. This is often where the organisation is at risk, either a start up, an organisation in trouble, or continuity requires achieving success. In these organisations, success is only possible if all the individuals align their goals with the goals of the organisation. It is not possible for an individual to succeed if the organisation fails. A “risk managed” culture will normally emerge in this context.

In some organisation’s where continuity is guaranteed, the success of the individual is best achieved by out performing their colleagues. The individual succeeds by placing their own goals above those of the organisation. A “failure” culture will normally emerge in this context if the leadership do not act to prevent it.

Puzzled by their colleague’s strange behaviour in December.

In a “risk managed” culture, adoption of new values and practices will be natural and easy. In a “failure” culture, adoption of new values and practices will only occur it aligns with the goals of the individual, something that leadership has a huge impact upon.

The failureship in a failure culture is dominated by self interest. Even if the CEO is trying to improve the share price, they do not necessarily care about the long term future and health of the organisation. The goal is short term value extraction rather than long term growth. I worked at an organisation that was deeply damaged by the financial crisis and specifically the mismanagement of government. Prior to the crisis the CEO had been leveraging the strong national brand to build a trusted global brand. This was a slow and complex process of investment that would take years to evolve this centuries old institution to it next incarnation. The Crisis eventually lead to a new CEO. The new CEO retrenched and shifted to a short term national strategy and sold off the international assets to make the short term profit look good. This strategy distracted from his poor revenue figures. The CEO got their bonus at the expense of the future of the organisation.

Why does this self interest impact the quality of the developers that an organisation hires?

Consider two organisations. The first organisation hires the cheapest staff that they can find. They normally do this through a consultancy which is also driven by self interest. More later on that. The second organisation hires staff who cost twice as much but they need half the amount. The first organisation has two thousand (2,000) developers costing one (1) unit, and the second organisation has one thousand developers costing two (2) units each. Both organisations spend the same amount two thousand units (2,000) on developers. The organisations look like the following.

Although the cost of the workers is the same, the management headcount and the the cost of management have more than halved. Furthermore, if the workers are significantly more experienced, they will require much less support from management which means that those managers in Organisation 2 that have an outline could also potentially be removed. So the final result is a reduction in management headcount in the region of 50% to 75%. So if you want to understand why managers in a failure culture do not want to increase the quality of the workers, you only have to ask “Why don’t Turkeys vote for Christmas”. In a risk managed culture, management is focused on value rather than cost. The desire to move fast means that they want smaller teams of higher quality individuals.

In a failure culture, the failureship does not want to be held accountable for the quality of the workers. As a result, they do not hire directly but instead make extensive use of consultancies with a “global brand”. This also has the added advantage of reducing the quality of the workers even further which increases the demand for poor quality managers. Any decent worker can normally find their own work, either as a permanent or temporary member of staff. People join consultancies because they want to gain experience either in a skill set or in an industry. This is particularly true of graduates (that includes me) who want to get some experience in a variety of industries before deciding where they want to work. Whereas a permanent or contract individual receives 100% of the money paid by the organisation, a consultant from a “global brand” consultancy receives only 30% of the money paid for them. In effect the individual consultant is paying 70% of their fees to the “global brand” consultancy. They are paying that 70% fee for the learning experience that will eventually enable them to receive 100% of the fee. So why would the failureship pay such a huge premium for such poor quality staff? We have to remember that the motivation is self interest rather than the goals of the organisation. “Global Brand” consultancies look after their customers. In the event that a member of the failureship is fired, the “Global Brand” consultancy is incentivised to find that person another job, ideally with more authority as they are more likely to use the services again at their new organisation. Some consultancies even act as car parks for members of the failureship. Once again, asking a member of the failureship to move away from “Global Brand” consultancies to hiring competent individuals is like asking someone who is falling from an airplane to hand over their parachute.

My favourite experience of this nature was a meeting with a senior executive about Safe.

  • Me: It is my strongest recommendation that we do not use SAFE because it is rubbish.
  • Exec: No! We are going to use SAFE!
  • Me: Why?
  • Exec: Because I say so.
  • Me: In that case let me introduce you to Martin (I still miss you Major Tom) who knows all the people with lots of experience with SAFE.
  • Exec: No! It is more than SAFE so we are going to use the “Global Brand” Consultancy called *********
  • Me: Why?
  • Exec: My best friend is a partner with *********. He finishes his paternity leave next month so I want him to do it.
  • Me: Is that the door? Must be going.

In this case it wasn’t even pure self interest, the executive placed the needs of his friend above the needs of the organisation… Though it always helps to keep the “Global Brand” happy in case you need them. 😉

Leaders in a “risk managed” culture would ensure the quality of each individual. They would invest in continual pipeline of high quality candidates preferring to find talent over filling roles.

A large organisation of poor quality individuals in a failure culture gives more opportunity to “leaders” in its failureship. Using “Global Brand” consultancies provides further job security.

Failureship and EXPENSIVE, low cost people

One of the key differences between organisations with “risk managed” and “failure” cultures is the attitude towards talent. “Failure” cultures prefer large teams of “cheap” individuals who have little experience, knowledge and skill. “Failure” cultures prefer individuals with potential. “Risk managed” cultures prefer small teams of “expensive” individuals who have significant experience, knowledge and skill. “Risk managed” cultures prefer individuals with a track record.

When you discover the driver is inexperienced, its not an accidenture, its negligence.

One problem with “failure” cultures is that the failureship do not understand the difference between cheap and low cost. Consider two potential team members. One member costs one unit and delivers one piece of work. The second costs two units and delivers ten pieces of work. Which of the two individuals is cheaper? The second costs more than the first, however we need to consider the value delivered as well. The second delivers five pieces of work per unit of cost whereas the first delivers one piece of work per unit of cost. The second is cheaper than the first. One explanation is that the work or value delivered is subjective whereas the cost is fact based and defend-able if the investment fails to deliver the desired return.

“Failure” cultures gorge themselves on expensive low cost individuals whereas “Risk Managed” cultures carefully select cheap high cost individuals. I worked on a project where we had twenty developers based in London working closely with the users of the software. An executive blindly following the edict of another member of the failureship, and insisted we move the software development to an off-shore location with lower day rates, which was about one fifth of those in London (five units of cost in London, and one unit of cost for offshore developers). The London developers became product owners and fifty off-shore developers took over the development. The value delivered dropped like a stone to a quarter of previous levels ( The value delivered went from 600 to 150 ). The cost went from 100 units to 150 units. The cost of a unit of value delivered went from six ( 600 / 100 ) to one ( 150 / 150 ), an 83% reduction. The exercise was considered a success by the failureship because the average cost per developer went from five to one and a half. It is only possible to think this way if you completely ignore value.

Head count2070+250%
Value delivered600150-75%
Cost per head count51.5-70%
Cost per unit of value delivered61-83%
Agile project lead (Me)10-100%

The video below provides a wonderful illustration of this difference in the cultures.

Even though there are 100 children playing football, only a few are ever close to the ball. What are the rest doing… nothing of value to the game. This reminds me of a transformation project I worked on. A well known consultancy provided a team of twenty individuals to work on the project. We told them that we wanted to focus on delivering one or two epics (i.e. Limit Work in Progress). Very quickly sixteen epics were work in progress and we did an intervention asking why so many epics were being worked on. It turned out that the team members did not have the skills to work on the epics we wanted and so they started a new epic when someone in the team could not work on any of the other epics. They bought in an agile expert. It turned out the agile expert’s most significant experience was sitting next to a team that was using Scrum.

Each “Risk Managed” organisation I have worked for has had a ridiculously high bar for entry. At ThoughtWorks and many other high quality software organisations there is a coding test where the candidate has to write some code and then explain their design decisions in a interview with experienced developers. Thoughtworks hired one out of every one hundred applicants. A tribe lead at Spotify said that they hire one in three hundred applicants. Any developer who does not want to do a coding test because they are a well known “rock star” should not be considered a good cultural fit. As soon as one person is considered “special”, where do you draw the line. A “rock star” developer should want to share the interview experience of their colleagues rather than be important enough to be exempted. A “rock star” should be able to complete the task in an hour whereas another candidate might take a few days to complete the task. The coding tests do not just test for capability, they also test for developer culture fit.

A “Failure” culture struggles to recruit high quality talent because it does not know what good looks like. It takes several high quality individuals to recruit someone of similar quality, because we all have blind spots and it takes several of us to make sense of someone’s experience. This is particularly the case as many people now know the “words of power” used by high quality developers such as “refactoring”, “clean code” and “patterns”. If you have never done refactoring, you might be impressed by the person who “refactored” an entire system without needing any automated tests because they are just so awesome. Once a “failure” culture develops a reputation for rewarding bad behaviour and tolerating mediocrity, high quality individuals will avoid it and no amount of recruitment effort will help. One of the easiest ways to identify a tolerance for mediocrity is to look for organisations that make extensive use of low cost and expensive consultancies like Wipro, Tata Consultancy Services and Accenture rather than apply their own recruitment processes to hire individuals as either permanent or contract staff.

“Failure” cultures find it even harder to retain high quality individuals than they do to recruit them in the first place. High quality individuals want to deliver value to the customer. They quickly become frustrated in cultures that are only interested in personal survival and promotion, where helping others solve problems is not considered sensible. Things that are easy to achieve in a “risk managed” become almost impossible to get done in a “failure” culture where everyone is too busy doing their day job to have any spare capacity to help someone else fix an organisational problem. Eventually high quality talent will leave, shifting the culture even further into a “failure” culture.

The flip side is that organisations that truly embrace hiring high quality talent get a reputation and grow rapidly through word of mouth. The London Agile Developer community descended on Thoughtworks, then BNP Paribas, UBS, Sky, Springer, rapidly growing high quality teams, simply because they knew they would be able to work with similar high quality developers and they would be valued by the organisation. A cautionary tale though, at one of the organisations the leadership drifted into a failureship and all the high quality developers left. The developers who remained “knew where the bodies were buried” and quickly achieved senior positions where they prevented the adoption of practices that undermined their status, thus effectively inoculating the organisation against “risk managed” culture.

As with all leadership, deeds need to match words, or leaders need to “Walk the Talk” as some books call it. Any transformation of an organisation needs to start with building a team of cheap, high cost, high quality individuals and developing a recruitment pipeline focused on excellence. Any organisation that tries to improve by hiring a large quantity of expensive, low cost individuals from a poor quality consultancy is choosing to fail.

If its so obvious that smaller teams of high quality individuals are better, why do the failureship continue to gorge themselves on EXPENSIVE, low cost consultants? I’ll answer that question in the next blog…

Step away from the office, and join the team!

Years ago I shared a table at a wedding with a primary school (Kindergarten) teacher. We were not surprised to discover that my job in technology was very similar to their job. Understanding behaviour was a big thing we had in common. One common situation they encountered was children behaving badly and the parent’s not believing them, “They are an angel at home” was the common response. The teacher explained that they would arrange for the parents to observe their child’s disruptive behaviour secretly through a window. I’m sure that often the parents would rather not know because then they would have to do something about it. And so it is in organisations. I’m sure we have all seen people behave in an aggressive and domineering manner when they perceive themselves to be the HIPPO in the room, only to assume the demeanor of a timid mouse in the presence of a bigger cat.

Photo by yang miao on Unsplash

Failure cultures prevent access to the big boss, the hierarchy acts to prevent uncontrolled access. This benefits the person potentially behaving badly, and it also benefits their boss because they do not become aware of the bad behaviour. People who tells tales out of school are often told “to escalate through the appropriate channels”. The “appropriate channels” being those that can be used to filter the message.

The leadership in “Risk Managed” cultures spend a huge amount of effort to make sure they are accessible to everyone in their organisation. As well as making themselves accessible, they will also make the effort to reach out to people. They understand that “going to the Gemba” is not a planned royal visit with courtiers and presentations, often it means simply working near to a team for a while. As any ethnographic researcher will tell you, it takes a few days for people to drop the formality and act normally. Spending a week sitting in an area, listening to the buzz of a floor will tell you much more about the mood of the people than any survey or presentation. Leaders are better able to detect issues earlier when they sitting with the team at the Gemba.

The failureship in a “Failure Culture” are like an unruly child in the kindergarten along with their irresponsible parents who do not even want to know about the behaviour of their star child. Uncontrolled access to the big boss is to be avoided at all costs. Meetings with the big boss will be arranged by respecting the hierarchy at all times. Your superior will attend the meeting, acting as a guide to ensure you do not reveal any information that might taint the ears of the big boss. Door stepping a senior member of the failureship with a problem / issue / idea will be met with sanctions of a career limiting nature. Individuals will be given controlled access to senior members of the failureship at intimate breakfast meetings and coffee corners with a dozen of your fellow colleagues, normally those with the same rank.

This leads to a behaviour I observed in the original “Seeing Culture” article. The failureship have offices, and the leadership sit with the team. This is perhaps one of the most visible differences between a “Risk Managed” and a “Failure” culture.

“Turn the ship around” by David Marquet tells the tale of how his submarine went from a leader – follower culture to a leader – leader culture. I prefer the language of Eric Berne’s Transaction Analysis of Parent – Child to Adult – Adult relationships. In a “failure” culture, a leader – follower (parent – child) relationship means you treat your subordinates like a child and control access to the big boss. Going around your superior and violating the hierarchy is normally a career limiting move. In a “risk managed” culture, an adult – adult relationship means you treat your subordinate as an adult and respect them to make the proper judgement as to whether they need to speak to the big boss. The big boss will determine whether the contact is appropriate and will advise your subordinate accordingly, perhaps directing the person to someone else or even back to you. If the contact is inappropriate, its a learning opportunity helping them understand how to address an issue, rather than a violation of the hierarchy.

I previously wrote about how Al-Noor Ramji and JP Rangaswami reduced the power distance index at Dresdner. At Skype, Mark Gillett was even more explicit at breaking down the power distance index. I first met Mark shortly after joining Skype in the coffee area next to his office, he introduced himself and when he knew I was an Agile Coach we discussed User Stories for a few minutes. A year or so later we moved office into a state of the art office as part of the Microsoft family. A couple of years ago Mark told me about his design for the new office. Microsoft had wanted him to have a corner office but he wanted to maximise the possibility for chance encounters. The Skype office was based on three floors. Mark installed a sweeping spiral staircase to link the floors. The staircase was the easiest and quickest route between the floors and as intended by Mark, it was a great way to bump into people. Furthermore Mark installed a coffee area on the middle floor next to the staircase, complete with a professional Gaggia coffee machine with associated Barista Training. Mark’s office was situated right next to the coffee area. If you really needed to chat to Mark about something, all you needed to do was go for a coffee and hang around for a short while.

At Tesco, Jim Banister was entitled to an office. Instead of sitting in his office unable to hear what was going on, he sat out with his teams. His office was made available to his teams for meetings that were either private or would be loud and disruptive to everyone else.

By comparison I worked in a company where senior managers were entitled to an office… and they always used one. They even used an office when they visited other locations. It was common practice for them to use the building where they could have an office rather than sit in the building where their teams sat. Team members would have to travel to a different building to meet the manager visiting from an overseas location. The same company further reduced the chance of unintended access by locating senior management in separate buildings to the workers. Even in open offices with hot desking arrangements, the failureship will soon establish themselves with dedicated seating for senior staff members and reserved seating for important individuals. Nothing signals a flattening of the hierarchy than seeing a senior executive hunting around for a desk because they arrived late, and them sitting with a new group of people, or perhaps in the coffee area.

At one company I worked the executive had an office in London. They only spent one or two weeks a year in London. However, they had an executive assistant sitting at a desk outside the office with instructions that no one was to use the office. Furthermore, they had an additional window added to improve the light to the office that no one was allowed to use. As one colleague commented “I wish they would fix the toilets so that they did not flood instead of improving an office they never use.”

When I did some work at Bank of America, a number of people excitedly told me the same story. A developer was working on some code when a new joiner asked them if they could join them and do some pairing. After an hour of coding the new joiner excused themselves. The developer asked the new joiner what his job was “I’m the new Group CIO”. That story spread through the organisation like wild fire, that the head of a department of tens of thousands of people was approachable and could code!

Along with “Servant Leadership”, “Go to the Gemba” is possibly the most widely held expectation of Agile Leadership. The first rule in “Six Simple Rules” by Yves Morieux of Boston Consulting Group is “Understand What Your People Do” or “Go to the Gemba”. “Go to the Gemba” and “Sit in an office” are the easiest behaviours to spot to identify whether you have leadership or failureship, which is why they are so powerful. Nothing signals change to an organisation better than a senior member reaching out and connecting to real people in the organisation, rather than simply communicating through the hierarchy (or through McKinsey if they do not trust their hierarchy).

If you are genuinely interested in moving from failureship to leadership, move out of your office and turn it back into a team meeting room. Sit with the team but give priority to them, offering to give up your seat if someone else would benefit from it more. Move around your organisation, spending a few days with different sets of teams. If you do need to spend time with your colleagues in the leadership team, split your day between them and the real workers. You will discover so much and you will enjoy your job more.