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.

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.

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.

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.

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.

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.

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.

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.

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…