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.

BeforeAfterChange
Head count2070+250%
Value delivered600150-75%
Cost100150+50%
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…

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: