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…

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.

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.

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.

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.

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…

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.

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.

I ran an exercise where I asked a group of executives “What is transparency?”. Take a moment, think what it means to you and say it out loud before you read the answer I gave.

Transparency is when you give someone the information they need, in the format they need so that they can make the decisions they need to make to fulfill their responsibilities.

Transparency is a collaboration. Sometimes the person asks for the information they need in the format they need. Sometimes the person with the information decides that another person needs it and works out the best format to present it. Formatting the data is often about constructing the context so that the information has meaning.

Transparency is not open kimono, the sharing of all information. It is not drinking from the fire hose, receiving huge quantities of data to be sifted and sorted. It is not the pretense of sharing everything, expecting the receiver to find Transparency in the aacennprrsTy. Transparency is the sharing of information with context to allow everyone in the organisation to achieve their goals. Sometimes the information is focused on an individual or a small group, and sometimes it is shared with the entire organisation. Sometimes it takes a great deal of effort to help someone understand that they need the information you are providing.

In “risk managed” cultures, the leadership create an environment where everyone, including themselves, share information so that others can decide and act. In “failure” cultures, the failureship create an environment where information is carefully controlled, and sharing of information can be seen as a crime against the organisation. The failureship do not want information to be freely shared as they want plausible deniability in the case where they fail to fulfill their responsibilities. Speaking truth in a “failure” culture can be career limiting or career destroying.

In “failure” cultures, information is carefully curated and filtered, often translated through several excel sheets, powerpoint decks and summaries until it presents the story that subordinates want the failureship to read… which is the story that the failureship want to read. Drilling into the information requires the failureship to navigate the reverse trail through the organisation, offering the opportunity to correct or delay access to the truth. In a “risk managed” culture, information is automatically assembled to be always available for all concerned, with alerts when appropriate. The information acts as an “invitation to the Gemba” for the leaders in the organisation. “Invitation to the Gemba” is a phrase that Jabe Bloom introduced to indicate that the leadership should not act on the information they receive but rather use it to identify the places where they should “Go to the gemba”, go to where the work is done, and see for themselves what is actually happening.

In a risk managed organisation, the leadership create the culture and environment where everyone is encouraged to provide information to those that need it. They actively work to encourage people to share information up, down and across the organisation. This requires a great deal of work on the part of leaders as they will constantly be employing new people who are used to cultures where sharing of information is forbidden, discouraged, or where information is “power”. Leaders not only send out memos or give organisation wide speeches on the subject, they also encourage it in every interaction or meeting that they attend.

All leaders ask for transparency, they all want to know what is going on. It is their behaviour when they receive information that determines how willing people are to share it. Getting people to share information requires the leadership to build trust. A second question I ask executives is “What do the RAG statuses, Red, Amber and Green” mean to you?”. The traditional meanings are:

• Green – Everything is OK
• Amber – The project might be late
• Red – The project will be late – (actually, it means someone has revealed the truth about what is going on.)

Anyone who has worked in a failure culture knows what happens when someone reports a status with “Amber” and “Red”. It is a very unpleasant process for all involved, the failureship swoop in, possibly deploying someone from outside of the project to find out what is going on, even though the failureship already know. A lot of weight is thrown around with an associated dollop of Kabuki (Japanese theatre with the players cutting all sorts of shapes on the stage) until some sort of reset is performed and the status can return to “Green”. The reset normally involves moving out the target date if it can be negotiated, or reducing the scope until it no longer delivers any real value for the customer. Normality resumes until the next RAG crisis. Everyone knows that nothing good comes from reporting status of “Amber” or “Red”. The failureship lament that most projects are “water melons”. Green on the outside, and red on the inside. They lament that they normally only find out that a project is “Red” when it is too late and they can do nothing about it. They already know what is going on. They find out it is too late because they want to find out too late and make it unpleasant for those that tell them. They do not find out too late as they already know, they are forced to acknowledge the problem publicly when the options to address it have expired.

In a “Risk Managed” culture, the RAG status have a different meaning:

• Green – We are good, and are unaware of any problems that will prevent success.
• Amber – We might need help. There are problems that we might need help addressing. We are signalling that the leadership may need to step in and help.
• Red – We need help. There are problems that we are unable to address and require the support of leadership to address them.

In a “Risk Managed” Culture, the responsibility for delivery remains with the team, including the responsibility for requesting help. No team should be green until they have completed their first end to end production delivery of value. In a “Risk Managed” culture, the leadership act as servant leaders to the team. The leadership work hard to build trust with the team so that there is no barrier to revealing the real status of the delivery. The leadership see it as their responsibility to help the teams. The crime in a “Risk Managed” culture is to sit on information that you know others need.

Transparency is not about systems and reports, it is about how the leadership behave when they encounter transparency or the lack of it.

For over twenty years I have been reciting the mantra:

“In agile, we fail fast to win early. Traditional teams are afraid to fail!”

For many years I have been observing agile teams and non agile teams, and their attitude towards failure. Once I started to observe them using the lens of “risk averse” and “risk managed” culture I realised that the agile mantra about failure was wrong.

In agile teams, practitioners do not fail fast to win early, or fail fast to learn. In agile teams, they act with self discipline as a single team to deliver value in small increments. At regular increments, the team and/or team of teams come together in a retrospective to identify what is going well and what should be improved. Agile teams do not focus on failure, they focus on value delivery and continual improvement. When failure occurs, agile teams acknowledge the failure so that they can learn from it and improve.

It is not the goal or focus of an agile team to fail or learn, it is the focus of an agile team to deliver value.

In addition, traditional team are NOT afraid to fail!

Teams in “Failure Cultures” know that their managers in the failureship are even more scared of failure than they are. As a result, their managers will never acknowledge failure. The result of this is that the failureship will REWARD failure to prevent anyone knowing that a failure has occurred. The bigger the failure, the bigger the reward. This inability to acknowledge failure and the subsequent rewarding of failure is why I call this “Failure Culture”.

Career progression in a failure culture is based on avoiding failure rather than being successful. If your portfolio of interest contains a large strategic project, it has to be hailed as a success regardless of whether it is a failure or a success. If you have a large strategic project in your portfolio and the key individual(s) are not rewarded for their contribution, people may question why they have not been rewarded. So if you are in a failure culture, the easiest way to get promoted is to join a large strategic project in a key role. Once you are established in the role, your promotion is guaranteed regardless of whether you are a success or failure. In fact, the bigger the failure, the bigger the chance of promotion.

I worked on a project that was meant to be an Agile Flagship. As an Agile Coach I gave it my full attention. The business users and product team adopted the agile approach with gusto, even reorganizing to sit together in the same space within earshot of each other. The technology team was a different matter. The technology lead refused to engage and turned a blind eye to his lead developer’s misogynistic and bullying behaviour. Eventually the team refused to even listen to suggestions about how they could improve the way they worked. “The developers are working sixteen hours a day, seven days a week. They do not have time to work in new ways”. The senior executives were informed of the situation and responded by saying “That’s not Agile, Its not even Waterfall, Its a death march project!”. The first production delivery on the Agile Flagship project took over a year. It failed to be useful because the the business users had built an interim shadow tech solution which better met their needs. The technology leadership blamed the business users for not being engaged enough. The same executives who declared the project a “death march” promoted the technology lead who was the main cause of the failure.

Another project started with a decent plan. The introduction of a new pervasive technology would begin with a three month pilot period with teams scattered across the organisation. Even though the technology was well established in the market, the internal implementation at scale needed to be debugged. After the three month pilot, the plan was to roll out the new tool to the entire organisation. I am a huge fan of the work of Chris McDermott and Marc Burgauer with Social Practice Theory. Introducing a new tool is normally a way for getting the organisation to adopt a new practice. Building organisational muscle memory in a new practice takes time and should ideally occur before the tooling. Those engaged in the pilot were the best of the best in the new practice and easily adopted the tool. Hundreds of teams adopted the new tooling. At the end of the three month pilot not one single team had successfully migrated. Just before go live, we summarised the status as a “shit show!”. The executive explained that it was a game of chicken. “Who will blink first, the central team or the teams implementing the new tooling. No one wants to call it a failure.” The mass migration of the entire organisation went ahead over Christmas. Some highlights from the project:

• A lot of teams discovered that the migration had failed for them and were unable to work.
• The central team had not considered that thousands of developers in India do not take vacation over the Christmas period.
• The entire central coordination team went on vacation the day before the week long migration started. No one knew who to contact for help.
• The central team did not even think about creating a help desk or support team until weeks after the migration by which time teams were in chaos.
• The definition of done for the migration was cut back, and cut back, and cut back as the end date for the migration moved out quarter by quarter. As a result, cost savings were not realised as licenses needed to be extended.
• There was a lot of disruption for teams, with many millions of dollars worth of lost productivity across the organisation.

I think you know what happened next. The migration was declared a huge success by the Group CIO, and a few weeks later the Group CIO was rewarded with a promotion to the Board of the Group.

In a “Risk Managed Culture”, stage gates based upon success criteria rather than arbitrary dates would have determined progression, and retrospectives would be held on a regular basis to learn and improve. There would be proper transparency rather than a game of “Chicken”. The retrospectives would seek to ensure that similar failure would not occur in the future for the same reasons.

In a “failure culture”, the failureship do not want genuine transparency. They do not want to know that there are problems. They just want to make sure that they can contain and hide it. They promote the people who cause failure so that they do not need to acknowledge it.

Failureship doesn’t avoid failure… Failureship REWARDS failure.

The culture of an organisation is vital to its ability to change and acquire new capabilities so that it can adapt to new contexts. Whilst academics and thought leaders will tell you that culture cannot be changed and is different for each organisation, careful observation will reveal that there a couple of key cultural archetypes when it comes to change in organisations. Like blind men scrambling over an elephant, there are many ways to describe these polarities. Currently I name them a “risk managed culture” and a “failure culture”. Associated with each culture is a set of behaviours. In a “risk managed” culture, we have a set of behaviours that lead to change, a set of behaviours we call leadership. In a “failure culture”, we have a set of behaviours that prevent change and perpetuate the status quo, a set of behaviours we shall call failureship.

“All that change needs to fail is that good leaders do nothing”

Failureship is the set of behaviours that prevent change and perpetuate the status quo. It is a mixture of conscious AND unconscious behaviours that undermine and block change. Failureship behaviours are not the fault of an individual “managers” but a complex interaction with the culture itself. They are a behaviour-plex where one behaviour leads to another which leads to another which feeds back and stabilises the original behaviour. Sometimes they are held in place by an enabling constraint rather than a governing constraint.

An understanding of behaviours in a “risk managed” and “failure culture” and the associated “leadership” and “failureship” behaviour sets can help us better predict the success and failure of a change within an organisation. As most people consider leadership synonymous with leaders, I will refer to “leadership” as “changeship”, the act of leading change rather than leadership which most consider to be the rulers of an organisation.

It is worth noting that failureship often leads to huge success for the individuals but ultimately leads to long term damage of the organisation they work for. The “failure culture” rewards individuals engaged in failureship and although it does not punish those engaged in leadership, they are likely to be undervalued and will seek organisations where they are valued. The result of failureship is the squeezing out of leadership and the eventual dominance of a failure culture and the establishment of a ruler group who are experts in failureship… the failureship. As the goal of the failureship is value extraction, the failureship will ensure that the organisation will appear to be in rude health even though it is unable to change to meet changing contexts. The Failureship will trade long term health for short term gains.

An understanding of failureship will help the following groups of individuals:

1. Leaders of organisations that are genuinely interested in change. An understanding of failureship enable them to identify colleagues that are consciously or sub-consciously preventing change. It will also help them to understand the behaviour-plexs that need to be disrupted in order for change to occur. Most importantly it will help them to understand how their own behaviour contributes to change and prevents it.
2. Change agents can use it to identify whether the leadership in their organisation is commited to change or is consciously or unconsciously opposed to it. They can identify whether their efforts to help an organisation improve will result in success, or frustration and failure.

It is worth noting that any organisation consists of many sub organisations. It is possible for different sub organisations to have a different culture, especially if the leadership of the sub-organisation is strong enough to resist the culture of the wider organisation.

About a year after implementing Capacity Planning ( aka Delivery Mapping ) at Skype, the product leadership team asked for reporting to support the process. Tony Grout, Lisa Long and myself implemented the “Strawberry-jam-o-meter” and the “Wrong-order-o-meter” with the product leadership team ( report names inspired by Dr Seuss books which were a favourite of one of the product executives ). The product organisation consisted of about two hundred product owners working with about three hundred scrum teams. Capacity Planning meant that for a year the product organisation had come together once a quarter to prioritise an organisation wide product backlog based on the available capacity of teams.

Skype consisted of several front end products (Windows, Windows Tablet, XBox, iOS, Android and Windows Phone) that implemented back-end products (Audio/Video Codecs, Transport, Login). The architecture was constructed using Reverse Conway principles with the aim of allowing each scrum team in a release vehicle (a set of scrum teams) to be able to deliver independently.

The organisation wide backlog (known as the meta backlog) was a set of business goals whose success was measured using metrics. For example, reduce the day one churn (number of users that only use the product once and never return), conform to regulatory rules to prevent significant fine or enable asynchronous chat by moving it chat from peer to peer to server based.

Anyone who has worked in a large organisation knows that it is pretty much impossible to set up your organisation such that every business goal can be delivered by a single scrum team. Several teams are often required to achieve a business goal. Large organisations need to create a single ordered backlog to provide focus and create alignment between the teams.

Once the leadership team had established the process to create an ordered backlog, they were able to get better insight into what was actually happening in the delivery. To that end, they reduced work in progress by over 50%. They also created two reports:

The Strawberry-Jam-O-Meter was used to identify teams that had the most backlog items in progress. Inspired by Jerry Weinberg’s “Law of Strawberry Jam”.

The Wrong-Order-O-Meter was used to identify teams that were working on items in the wrong order according to the organisation wide backlog that the product owner organisation had specified.

The reports were to help the leadership understand which teams needed their help and support. The reports provided bad smells that helped them identify issues to resolve. To quote Jabe Bloom, the reports Were an “invitation for the leadership to go to the gemba”. There was an understanding in the product leadership team that the “behaviours” were often a result of constraints in the system. For example, the team is blocked waiting for another team and moved onto the next item. In some cases the product owner was not aware of the impact of too much work in progress which was a “learning opportunity”. In one case, the product owner on the 16th priority was very aggressive at getting their own delivery done such that they put the 1st item at risk.

The two reports provided leadership with a system wide view so that they could identify constraints. The leadership were more interesting in solving system wide issues rather than issues with an individual team.

Layout and Calculations

The Wrong-Order-O-Meter was very simple. It showed the team name and the effective position in the backlog that they were working. It was possible to drill down on each team to show the items they were working on.

Drilling down into Slytherin’s backlog:

Fifty percent of the effort in the organisation will be for “Items not on the Organisation Backlog” because the teams will not be able to work on the backlog item as there will not be enough capacity in the teams acting as the constraint in the system. For this reason, the leadership needed the strawberry-jam-o-meter as well to identify teams that are spread too thin both for items on the backlog and for items not on the backlog.

Corona virus has raised the importance of Skills Liquidity or “key person dependency”. As well as managing the normal skill liquidity risk, organisations now need to consider the “summer holiday” effect. During the summer holidays the productivity of many teams plummets for an extended period because of skills liquidity. The absence of one or more team members means that the team experiences a significant reduction in throughput and a massive increase in lead time. To address this, organisations need to move quickly address risks that are normally annoying but are now significant.

To address skills liquidity it may be necessary to redeploy people from non-core applications to core applications. So the first step is for organisations to classify applications as core and non-core (possibly with more refined classifications).

Then create a skills matrix for each application ( I like the way Cat Swetel describes it here ). We end up with a skills matrix like this one:

Then we create a scenario where team members are unavailable for any number of reasons such as:

• Being ill for a few weeks
• Looking after sick friends or relatives
• Unable to login due to lost internet capability
• Called up by the government to assist in army or medical capability

We assess the scenario impact on the ability of the team to fix problems or make critical emergency changes:

Where we do not have enough skills liquidity (options), we need to create them. Bring new people onto the team, possibly former team members if they are not supporting other core applications. Creating new features is probably higher risk and can reduce the stability of the application. The new team members can refactor the application, create automated tests and pay down technical debt. They can automate the build chain and generally make the application more resilient.

Core versus Non-Core

A follow up on core / non-core and the risk profile of each skill / component to follow.