Category Archives: Uncategorized

Three Levels of Metric Maturity : Demonstrate Success

For any Executive thinking of introducing Metrics, they need to understand that there are three level of Maturity:

  • Step 1: Map Investment to Metrics.
  • Step 2: Use Metrics to demonstrate Success.
  • Step 3: Use Metrics to assist Decision Making.

Demonstrating success is the next step after the organisation achieves alignment using Metrics.

air-1869955_1920

Consider the hot air balloon captain who got lost in the fog.

  • “Where am I?” they shout.
  • “You are in a hot air balloon!” comes the reply from the ground.
  • “Are you an Executive without Metrics?” asks the Air Balloon Captain.
  • “How did you know?”
  • “Because your answer was one hundred percent accurate and utterly useless.”

If you do not have metrics, your decision as to whether your investment yielded a success is based on opinion and not facts.

To quote Jim Barksdale, former CEO of Netscape:

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”

In other words, if you do not have data to demonstrate the success of an investment, the CEO, an executive or steering committee decides whether it was or not. So why is that such a terrible situation?

When an organisation makes an investment, it is either a success or it is a failure. If it is a failure, the organisation learns (normally about its customers) so that its subsequent investments have a greater chance of success. If an executive decides that the investment is a success when it is a failure, then the organisation is denied the opportunity to learn and it may continue to make poor investments. Executives who declare success based their opinion rather than data are cheating the organisations that they are morally obliged to serve and protect. They are cheating the organisation out of an opportunity to learn.

This leads us to the second level of metric maturity…

Level 2: Demonstrate Success

No one would question that in general Start Ups are much more successful than traditional organisations at innovating and learning about their customers. The reason is simple, they use data extensively to determine whether their hypotheses about their customers are right or not.

The first step to demonstrating success is to establish a baseline. The baseline is the “value” of the metric before the investment.

The baseline…

  1. …should be for a metric that is either a sub-set of the business value metric, or another metric where the executive believes that they have a hypothesis that moving the metric will move the business value metric.
  2. …only has to be accurate enough to prove whether the investment was a success or not.
  3. …needs to be calculated using the same method as the result of the investment.

All three of these points will be covered in more detail in subsequent posts.

As an aside, it is easy to spot a culture where the executive’s opinion decides success because Product Owners do not care about establishing a useful baseline.

Once you have a useful baseline, the rest of the process is simple:

  1. Articulate your hypothesis.
  2. Construct an experiment to test the hypothesis.
  3. Run the experiment.
  4. Measure the metric and compare the results with the baseline.

Note: The baseline may be determined at any point prior to running the experiment.

There are three possible outcomes:

  1. The investment is a success. Our hypothesis is correct, we understand something about the customer and we have successfully created business value.
  2. The investment is a failure. Our hypothesis is incorrect. However we understand something about the customer and we have a better chance of creating business value in the future.
  3. The results are inconclusive. It was a bad experiment and we need to construct a better one to test the hypothesis. We may or may not have learned something about the customer.

Whether success is demonstrated using a metric or the opinion of an executive is a cultural matter. It is purely the responsibility of the executives as it is their decision whether to allow investments to take place that do not demonstrate success using metrics. If an executive wants to help their organisation succeed and insist on learning about the customer, they should simply fail any investment that does not use data to demonstrate success.

At Skype we had a metric to measure this… “The percentage of the investment portfolio that could be demonstrated using metrics”. More on that later.

The next blog post will look at how to “Use Metrics to assist Decision Making”.

Photo credit: https://pixabay.com/en/users/Pexels-2286921/

 

Advertisements

Three Levels of Metric Maturity : Mapping

For any Executive thinking of introducing Metrics, they need to understand that there are three level of Maturity:

  • Step 1: Map Investment to Metrics.
  • Step 2: Use Metrics to demonstrate Success.
  • Step 3: Use Metrics to assist Decision Making.

Your metrics will mature with your (understanding of) your Product. Do not expect to build the perfect Metrics system in one go. Rather your Metrics system will evolve with your product. Consider building a road:

  1. You lay the paving stones where the grass is bare and muddy.
  2. Someone watches the path for a few days to see if is used enough to justify an upgrade. If it is, we build a one lane road.
  3. Next we lay a rubber counting strip across the road to electronically count the cars using the road.
  4. By the time we have a seven lane highway like those in Los Angeles, we have real time tracking of cars and an advanced flow management system that controls the number of cars allowed onto the highway.

muddy path

In other words, start small and evolve your metric system gradually.

Level 1: Map Investment to Metrics.

Before your product owners get to invest, make sure they know what they are trying to improve. Get them to specify which business value metric they are hoping to move. Use Cynefin to help them understand whether their investment should a definite improvement on a metric or whether they should be testing a hypothesis.

Get them to map their Stories (Or Epics) to a business value metric.

  • In order to improve conversion on the pay channel
  • As a customer
  • I want the pages to load faster
  • So that I do not lose focus and attention to the task at hand

( Pay channel conversion is the value metric. )

Once your organisation has simply mapped their work to metrics, you will have a strategic view on where investment is taking place. To illustrate this, lets start by looking at you portfolio without a mapping to metrics.

Screen Shot 2017-09-24 at 18.43.01

As an Executive, there is little you can do but ask about the details of each Widget and DoDah.

Now lets map each Story/Epic to a Metric…

Screen Shot 2017-09-24 at 18.43.14

Doesn’t look like much but lets consider some of the analyses we can do:

Screen Shot 2017-09-24 at 18.43.31

As an executive, you can create an aggregate view of metrics that you cannot create by looking at functionality.

Now you can see that you do not know where most of your investment is going. You can also see whether the other metrics are the right ones to invest in depends on the state of your metrics.

The key is that you do not know which metric you should be investing in until you know the health of all of the metrics in your portfolio. When starting out, you may not have the perfect comprehensive view in which case you’ll have to “lay the paving stones where the grass is bare”.

stone path

The next two blog posts will focus on level 2 and level 3, “Use Metrics to demonstrate Success” and “Use Metrics to assist Decision Making”

Photo Credits:


A Tale of Two Hedgehogs

Over Christmas I introduced the Hedgehog strategy for Agile Transformations. Unlike the fox who is very clever, the Hedgehog does one thing well. The Hedgehog strategy I suggested was to “Reduce Lead Time”. This is a great strategy for an IT Director or CIO. It is not a very good strategy (on its own) for an organisation. In particular it is not a good strategy for the business or product leadership. An organisation needs two Hedgehogs, one for delivery, and one for product.

TwoHedgehogs

The Product Hedgehog strategy is very simple…

Insist that every investment delivers value by increasing a business value metric.

Why is this so important? The answer is because of what happens when you do not. When you do not insist on improving a metric, the team will do the easiest thing which is to agree a list of functionality to deliver instead. This leads to all sorts of naughtiness. Some common symptoms of failing to focus on value are below:

  1. The team focus on delivering functionality rather than something of value to the customer.
  2. Teams build what they can build easily rather than build what the customer needs or wants.
  3. An executive with no detailed knowledge of the investment will decide on the functionality of a product after being presented the “options” by the team.
  4. No consideration of the customer’s needs. Although everyone will talk about customers, they will have no empathy or understanding of the customer and their needs.
  5. A rapid turnover of User Experience Researchers. It is obvious when you do not use a designer, but UX Researchers are easy to dismiss. UX Researchers are highly sought after and will move if you do not value them and use them.
  6. Executive steering committees are spent discussing functionality rather than metrics and value (mainly because the team have no metrics and can demonstrate no value… other than in the “Business Case”).
  7. User Testing always results in success as teams value “being right” over learning about the customer.
  8. No interest in establishing a baseline for the business value metrics.
  9. Large Waterfall Style releases of “value” as teams see no value in releasing small increments to learn from customers.
  10. Success of the product is based on the opinion of the Executive Steering Committee rather than based on facts and data.
  11. No investment ever fails. No one is ever sacked for the failure of the investment… which is the whole point of not using metrics in a risk averse culture.

Do you recognize any of these symptoms on your “Agile” project? Or perhaps you have other examples that I you could leave in the comments.

So do your organisation a favour and unleash the Hedgehogs of Success:

  1. Reduce Lead Time.
  2. Deliver Value (as evidenced by Business Value Metrics).

Why Business Cases are Toxic

Business Cases where product owners have to justify investments by presenting the benefits in financial (monetary) terms are toxic. They create two significant problems that prevent a customer focused agile approach to product development:

  1. They remove the need for executive decision makers to learn about business value metrics.
  2. They create a big batch development mentality rather a desire to create a continuous flow of value and learning about the customer.

Many executives embark on an agile transformation with the intention of becoming more responsive to customers needs. Unfortunately executives want to change their product organisations but retain practices that stifle agile transformations. The worst of these is the business case expressed in financial (monetary) terms.

The Business Case

An Agile product owners identifies an opportunity to invest in the product. Traditional organisations insist that the product owner justify the investment in financial terms. The product owner then has to explain the investment idea in monetary terms.The conversation goes something like this:

  • Product Owner: I want to build a purple widget.
  • Executive: What is the business case?
  • Product Owner: This spreadsheet model shows that if we build the widget we will make £1,800,000.
  • Executive: How did you come up with this model?
  • Product Owner: We hired some consultants who used the data from one of our other products.
  • Executive: The return looks good so go for it.
  • Product Owner: Great so if we deliver a purple widget, we get to claim the £1,800,000 benefit? After all, there is no way to check that we have actually delivered the £1,800,000.
  • Executive: That makes sense.

To make this approach work, the product owner describes the solution in terms of functionality and then translates that into a financial amount. The executives then agree that building the solution will deliver that amount of financial benefit. Given the complexity of most organisations, it is impossible to directly attribute any financial outcome to an individual investment. As a result, the product owner gets to claim success simply by delivering the solution.

It is even worse when the translation to a financial amount is limited to those translations supported by existing data. This is equivalent to searching for you car keys under a street light when you dropped them in a field.

city-1487891_1920

A further consequence is that the product owner knows what they need to do for success and seeks to minimise the effort to build it. Rather than build the solution incrementally, learning about the customers and their needs as they build it, the product owner builds the whole thing in a big bang waterfall or water-Scrum-fall development. There is no point building it incrementally as the Product Owner already knows what they have to do in order to be successful.

The Metrics based Approach

In the metrics based approach that modern, customer centric organisations use, the Product Owner identifies an opportunity to invest and expresses it in terms of a metric.

The product owner and the executives should engage in a conversation to agree the exchange rate between the metric and a monetary amount. For example, the product owner has identified an opportunity to improve the conversion rate of the customer acquisition funnel. The conversation might go something like this:

  • Product Owner: Currently our conversion rate is 35%. I think we can do some things to get that closer to 50%. What is that worth?
  • Executive: I’m not sure, lets work it through.
  • Product Owner: We currently get 100,000 potential customers a month into the funnel and 35,000 sign up as customers, or a conversion rate of 35%.
  • Executive: Our existing one million of customers generate £10,000,000 in revenue which means £10 per customer.
  • Product Owner: Therefore a 15% increase of conversion means 180,000 extra customers a year.
  • Executive: Or £1.8 million, which is a good deal based on the proposed investment.
  • Product Owner: And a 10% increase of conversion is worth £120,000.
  • Executive: So every 1% increase is worth £12,000, or lets keep it simple and say £10,000 per 1%.
  • Product Owner: I can work with that. Do you want to know what we intend to build? I have the specs for the purple widget here.
  • Executive: Only out of interest and to ensure that the investment is coherent with the outcome. It is your responsibility to ensure the conversion rate moves, after all, you are the one with all the detailed knowledge.
  • Product Owner: So if you agree with what I suggest and I build it, I’m a success?
  • Executive: You are only a success if you increase the conversion rate regardless of whether I agree the purple widget sounds like a good idea. The responsibility stays with you.
  • Product Owner: In that case I build what I want, how I want, as long as I improve the metric you agree to, in this case the conversion rate?
  • Executive: That’s the deal. That what autonomy means.
  • Product Owner: What about the coherence thing you mentioned?
  • Executive: I’m responsible for a wider set of metrics. The only challenge I will make to your investment is if what you intend to do is not coherent with the metric you intend to move. For example adding Adverts to the funnel to improve conversion.
  • Product Owner: Got it, because Adverts increase revenue but will possibly harm conversion. So Adverts should be aligned with a revenue metric directly rather than the conversion metric.
  • Executive: You got it.

In this example the Product Owner retains responsibility for moving the conversion metric. The Product Owner needs to build something that moves the metric and cannot claim victory simply by implementing the purple widget. The success of the Product Owner can be easily determined from whether they moved the conversion metric. The Product Owner and Executive have agreed an exchange rate between the conversion metric and the “financial return” so that the executive can judge whether the investment is sound or not. The exchange rate can change based on the sentiment of the executive. For example if churn is high and customers are leaving, they may prefer an investment to reduce churn rather than conversion which simply on-boards customers who leave.

The First Investment

The first investment that a competent product owner makes is to establish the baseline values for their metrics. This allows them to determine whether their investments are working or not. If you do not know your starting point, there is no way to know whether the things you are doing are improving the product or otherwise. Without your baseline metrics, you have no way of learning whether the things you have built are a success or not.

A culture of Metrics versus Features

When your goal is to move the metrics instead of building features, you have to learn about your customers and their needs. If you do not study your customer, the features you build are a big gamble, nothing more than a wild bet.

Building features is hard, however it is CYNEFIN.complicated problem which can be solved by experts or analysis. Moving metrics involves building features which is CYNEFIN.complicated, and it is also hard because understanding what your customers need is a CYNEFIN.complex problem to solve. Poor quality Product Owners will ask their executives to turn their CYNEFIN.complex problem (Move the metric) into a CYNEFIN.complicated problem (Build a feature). It is the responsibility of the Executive to prevent the product owner from doing this.

A simple trick for Executives is to get their product owners to move the metric to claim success, and give no credit for simply building the feature. In short, ditch the business case and embrace metrics.


Fairness in processes and systems

Just back from the annual holiday with the family. One of the worst things about the work we do is that there is no switch to “Turn it off”. Whilst on holiday we had the cliched problem with sun loungers and towels and it bought focus to the problems we face at work in Product Management.

sun-loungers-461425_1280

The situation was typical. So typical that it was a cliche in management terms as well as sun loungers. Simply put, there were not enough sun loungers, towels were deployed, the rules were not clear and people got upset. Management had policies in place that made matters worse. Even worse, staff were not empowered to resolve problems for customers. It was a classic case for deployment of the theory of constraints.

Step 1: Find the constraint. That was easy. There were more people who wanted a sun lounger than there were sun loungers to go around.

Step 2: Prioritise the constraint. This is where management policy failed the “fairness rule” and customers got upset. This lead to conflict between customers, and conflict between customers and staff.

No need for step 3 and step 4.

So the problem for the hotel management was that there were not enough sun loungers. We have all been in that kind of situation. The problem for the customer was that the system was not fair and even monkeys get upset when treated unfairly. ( <– Watch this 2 minute video, its a treat. )

Screen Shot 2017-07-29 at 09.42.34

So why wasn’t the process fair?

  1. The customers knew that only two thirds of the sun loungers were actually being made available. One third were being held back for unspecified reasons. (Two reasons suggested were that “The manager thought it made the pool look untidy.” and “If too many were put out, the decking around the pool might collapse.” – Neither of which are good from the customer’s perspective. Either the manager’s sense of esthetics was more important than his customer’s comfort, or the pool area was dangerous.)
  2. Some sun loungers were deployed in the darkened indoor spa pool where there were already warmed stone beds to use instead. As a result the sun loungers were not used but they could not be moved to the pool side (unless you applied enough pressure on the pool staff).
  3. The spa reserved some sun-beds for people from outside the hotel who had signed up for a day spa experience. This meant that people staying in the hotel would be without a sun lounger all day because a day spa guest might want to sit by the pool for an hour.
  4. The rules for reserving sun loungers with towels were not clear or explicit. On day one I discovered that a French family had reserved a number of sun loungers with towels. On day two, I reserved a number of sun loungers before breakfast only to discover they had been removed by a German couple when we came to use them. When I asked one of the pool staff for assistance he randomly removed some towels from sun loungers for us and when the Dutch owners of the towels turned up, we faced the same awkward conflict situation with the them as the German couple had faced with us.
  5. The hotel staff did not take ownership. When we complained to the pool staff, they pointed us to reception. When we complained to reception, they pointed to the pool staff. It was only when we demanded that the General Manager come to the pool that the spa management rudely and begrudgingly found some extra sun loungers. (Note – We do not blame the spa management, anyone who has managed a constraint before knows that you need to lose empathy or otherwise you cannot function). It should be noted that the staff were wonderful but had no space to move within the rules specified by a general manager who clearly did not understand empowerment.
  6. An extension of the lack of ownership was that pool staff were only available to put out extra sun loungers at 11:00am. (The hotel wisely took the light weight sun loungers in overnight in case they blew about in strong wind.) This meant that there were even fewer sun loungers during the most popular time of 9:00am to 11:00am. Check out this wonderful picture of a person with a medical walking stick having to sit on the floor next to another person using the step as a cushion because the manager thinks the pool looks better with fewer sun loungers. Other customers choosto lie on a towel on the floor. The Emergent Behaviour of customers can be quite vexing for managers who would rather they shayed in their room out of sight.Screen Shot 2017-07-29 at 13.13.52
  7. Reception staff were helpful and raised the issue with management. Their solution, my family would get special treatment and have a number of sun loungers reserved for us… more unfairness.

So what can management do? We can apply the same kind of thinking for most constrained resources:

  1. Transparency – Make sure customers have transparency on what resources are available. No hidden resources. Hidden resources are unfair and destroy trust in the integrity of the system which leads to people gaming the system. Screen Shot 2017-07-29 at 09.42.49 After all, Unfairness leads to unhappy Monkeys!
  2. Deploy all resources – Get all your sun loungers out at 8:00 am rather than force people to wait until 11:00 am and create an even more severe and artificial constraint. In other words, its not fun being a constraint. (Step 3 applies here. People from other departments could be deployed to assist. Else step 4, more staff.)
  3. Understand customer need – Customers need sun-loungers in the sunshine by the pool, and not in darkened rooms. In other words, respond to customer needs rather than management needs. If management needs trump customer needs, make it a feature of your hotel and notify your customers at their time of booking. A simple “Basil Fawlty’s opinion matters, not yours!” on your web-site should suffice.basilFawlty
  4. Reserved Resources – Where resources need to be reserved, make it clear and make sure they are only reserved when needed. Attaching a tag to a sun lounger saying “This sun lounger is reserved for day guests, please vacate it if a day guest needs it”. Note – If the London Underground can do this, I’m sure an exclusive hotel can.LondonUndergroundSeat
  5. Transparent Policies – A notice warning guests that they cannot reserve sun loungers using towels.
  6. Police the Policy – Staff need to consistently enforce policies. It should not be left up to customers to confront other customers. After all, customers are meant to be on holiday and are not really expecting conflict with other customers and staff because the hotel is creating an artificial constraint and failing to implement proper policies to manage the artificial constraint they have created.

In summary, constraints can cause conflicts so don’t create them artificially, and make sure any policy for managing the constraints is transparent and fair. The similarities with constraints in product development are striking.

So now I’m off to read some books and find out if there is a way to switch off these mind viruses when I want to get away from it all.

 


Executives and Empathy

One of the major global IT companies has a saying

Its not personal, you were just road kill.

Screen Shot 2017-04-17 at 15.49.03

“Road kill” refers to the fact that your career destruction was not a personal act but simply a result of a shift in an executive’s strategic direction, or a whim. Although it feels personal to the hedgehog, there was nothing personal from the eighteen wheel truck driver’s perspective, and why should it. The phrase is normally used when the hedgehog is well known to the driver of the eighteen wheeler.

Lets take a systems thinking view of this phenomena.

Whence Road Kill?

Why “road kill”? “Road kill” refers to the “unintentional” destruction of someone’s career when an executive rolls out a top down strategy.

Whence Top Down?

Why a top down strategy rather than a bottom up strategy? “Top down” puts the executive in charge. They can be seen to be active in the initiative. At the end of the year, they point at the result of the initiative and claim them for themselves. “Top Down” is a Dragon Slayer strategy.

Have you ever noticed that a visit to the local Doctor (GP) normally results in either a prescription for pills, or a referral to a consultant (a specialist doctor)? That’s because doctors in the UK get a bachelors of medicine, bachelors of surgery which is one degree with two titles. In order to maintain their status in society and justify their high salary, the GP wants to be in control of your treatment. Doctors are finding life increasing stressful as the internet allows people to self diagnose or check their doctor’s diagnosis. If you receive a diagnosis of Diabetes you can expect Metformin or Insulin as a treatment. Alternatively, your doctor will prescribe a change of lifestyle, a change of diet and prescription of daily exercise and regular vigorous walks in the Welsh Mountains. Changing lifestyle is as much to do with changing your social network.

So why do some Doctors prefer to prescribe medicine? In the UK, only Doctors can prescribe medicine, patients cannot just rock up at a chemist and ask for whatever they would like. Doctors act as a gatekeeper to medicine. If a doctor convinces someone to change their lifestyle, it is the patient who gets the credit for their cure. In other words, some Doctors prescribe medicine rather than lifestyle because it puts them in control whereas lifestyle changes are in the control of the patient.

This is not meant to be medical advice. Always consult a doctor!

Similarly, only executives can implement top down strategies. People at the gemba (where the work is done, the coal face) cannot implement top down strategies. They have to get the support of executives to do so. Top down strategies empower the executive, giving them something to point to at review time.

Whence the need for Empowerment?

Executives are like sharks. They need to keep moving or they will drown. Its not their fault, its the lack of life support at such high altitudes. They need to keep demonstrating value otherwise they will be out in the next corporate reshuffle caused by the top down initiative of a more senior executive or the turmoil caused by a merger or acquisition*

Friends

The executive suite can be a very lonely place. As an executive, you have probably seen a number of your friends turned into road kill… often at your own hand. The safest thing to do is not have friends. You are constantly fighting turf wars with other executives, with minor skirmishes being fought at lower levels of the organisation requiring your close attention. You hire ambitious individuals to get the job done, and each one of them is looking to stab you in the back and take your job as they seek to reach the top of the pyramid. Friends become a liability as you climb the ladder, they may reveal a weakness or may be held hostage in some executive action. The executive suite can be a very lonely place.

business-792176_1920.jpg

Training

There are no training courses for executives. There are no training courses to prepare people for a role in the executive suite. MBAs and their flawed case based approaches teach students what good looked like a decade ago but do not teach practical day to day skills for today. Harvard Business Review and its monthly serving of early majority ideas provided comfort for executives looking for ideas. The HBR Online blog is a machine gun rapidly firing out anxiety inducing ideas reminding executives of the things they are not doing. Add subscriptions to CourseRA, Economist, Wired, McKinsey and you are fully in overload, and in need of beautiful expert consultants to help with your anxiety. None of them talk about failure, about things that other executives tried but failed. Talking about failure would only make you feel less inadequate.

And none of them teach obvious practical skills that you need to perform well in the long run.

How many of them teach the following strategies:

  1. Coaching and skills to help others learn. To enable executives to distribute their strategies effectively rather than having to rely on consultants.
  2. Real Options so that executives can effectively risk manage their organisations, and learn to make decisions when faced with uncertainty.
  3. Cynefin so that executives can understand the appropriate approach for each problem.
  4. Exaptation so that executives can reuse existing people and assets instead of buying new products and services.
  5. Safe to Fail so that executives can ensure that initiatives are safe to fail, and they can teach their organisation to be safe to fail.
  6. Culture. How to see it and how to left shift it to where they want to be.
  7. How to build a learning network that extends beyond their organisation so that they can learn from other organisation’s failures.
  8. The values and principles of Lean, Flow and Agile so that they understand and further the state of the art.
  9. Facilitation skills so that they can show by example how their managers can step back and let others do the work in a focused and risk managed manner.
  10. Cost cutting.

Transparency

Many executives are often blind to the realities of what is happening in their organisation. They rely on second, third and fourth hand accounts of the impacts of their initiatives. They receive their intel from power points that are beautiful with beautiful images and beautiful diagrams and beautiful prose that tell beautiful stories that are written by beautiful story writers who are beautiful consultants from beautiful firms.

When the executives “Go to the Gemba” to see the work, it is part of carefully prepared state visits that would make ambassadors and state department civil servants blush. It is joked that the queen thinks the world smells of paint because everywhere she goes, one hundred metres in front of her is a decorator painting the walls. Executives think the world smells of fresh powerpoint, immaculate Kanban boards and improv presentation skills.

When executives do make impromptu visits they are made aware that they are causing a disruption.

No one teaches executives how to read the raw data or create a culture where no one notices when they make an impromptu visit.

Consultancies

Most executives rely on consultancies for introducing change. Consultancies have access to skills that are not available in the organisation. In reality, organisations have better access to the skills.

Consultancies are great for people looking to get diverse experience, or build their brand. Most competent practitioners in a new skill are unlikely to work for a consultancy. Why would you work for a consultancy and give up 60%-70% of the fee? Furthermore, world class experts want to build their own brand rather than be subservient to the consultancy’s brand.

Assuming you are an executive who knows the community you want to hire from. You will struggle to bring them into the organisation. You will spend orders of magnitude more effort to bring in a world class expert over the effort of bringing in someone mediocre from a consultancy on the preferred supplier list. Most organisations are geared to make it easy for executives to get good support from consultancies rather than top class support from world leading experts.

Consultancies come with other added benefits. If you bring in someone from a top consultancy, they will have a hot line to the top of the organisation. Whilst you need to respect the hierarchy, anything that threatens the success of your consultant will go straight to their engagement partner who will tell the top guy what to do.

The Executive Team

Most executive teams are not an executive team. They are a bunch of individuals each with individual responsibility for their own initiatives. They succeed or fail according to the success of their initiatives. How often are the entire executive team held responsible for the success of an initiative? If they are, they becomes the responsibility of the CEO.

Most executives really are on their own.

workplace-1245776_1920

Safety Net

Many executives have spend many, many, many years building a network within their organisation. They need the network in order to make them effective. Studies have shown that shown that high performers at one firm become significant less effective when they move to another firm. It would seem that executive effectiveness is much a function of an their network and relationships. Often an executive moves organisation, to discover they it was their network and relationships that made them successful, and their skills are not enough.

Al-Noor Ramji understood the value of the network. He successfully moved from Swiss Bank to Dresdner Klienwort Benson to QWest to BT, and each time a chunk of his team followed him.

I know a number of senior executives who devoted a significant chunk of their career to building an organisation. Executives who failed to get a similar role when they left the organisation and are now working in a much smaller role because their network has no value to them. Executive effectiveness does not tend to be transferable.

In most cases, an executive’s network in the organisation they leave has no value to their new employer. The exception is consultancies. A friend who worked for a consultancy once told me that they had reached the time in their career where they needed to work for their client, a government department, for a few years. They would hire a team of managers to report to them before rejoining their current employer as a partner. Then the network and all of the relationships would be valuable, especially their successor who they would chose and mentor. This is why consultancies are often perceived as the recruitment consultancies for senior executive positions.

Is it any wonder that executives are often risk averse?

Whence Empathy

I started writing this series of posts where “Executive and Agile Beliefs Diverge” because I hoped to show executive a better way of thinking. As I’ve written the pieces I’ve developed empathy for executives. They exist within a system that prevents them from succeeding at introducing change.

The following are all set up to make the executive’s life hard:

  • No friends to support them
  • No training
  • No transparency
  • Consultancies without world class experience
  • No team
  • No Safety Net

Would you want a job like that?

Most organisations have a group of experts in system thinking. Perhaps they should get them to map out the systems at the executive level of their organisation to identify the system level changes that need to be made.

Me, I now have a lot more empathy for executives trying to make change happen in organisational systems that provide them little in the way of support. Rather than seeing them as the controllers of the system, perhaps we should see them as the ultimate victims of the system who need our support.

Happy Easter!

easter-1240521_1920

*Mergers were very popular in the 1980s and 1990s as a means for investment bankers to make money out of over capacity in markets. Unfortunately mergers lead to lumpy revenue streams but require maintaining high cost M&A departments. Since the 2000s, investment banks prefer to make money out of over capacity in markets through the credit derivatives markets. The credit derivatives market provide constant revenue streams which benefit from the occasional bankruptcy.

 

 


Executives and Top-Down Transformations

An obvious place where Executives and Agile Beliefs diverge is when it comes to Agile Transformations. Executives tend to favour top down big bang implementations whereas Agile Practitioners prefer bottom up safe to fail experiments.

Screen Shot 2017-04-15 at 10.55.47.png

This is not really the executive’s fault as they are driven by the need for fast results. Executives generally have a tenure of five to ten years. This is a surprisingly short period of time to effect significant lasting change in any established, traditional organisation.

The difference between traditional methods and Agile is that traditional methods tell you how to write software. Agile methods do not. As Tony Grout says “Agile methods are the simplest practice that will tell you the problem you need to solve“. Whereas traditional methods force the team to mold around the practice, Agile molds practices around the team and the context that they operate in. In other words, one size DOES NOT fit all. It takes time for a team to develop a stable and effective method for their context. It is not simply a case of the teams learning a new method, its a case of the team using Agile practices to create their method.

The change is bigger than just the development teams

screen-shot-2016-12-03-at-06-46-57

Its not just the teams. The program management structure that manages the risks of the cross team development needs to be developed using Agile techniques. Whether you adopt Flow, LESS, Nexus, SAFE or DAD, its not just a process. All of the people operating the system need to learn a new way of working, and even harder, a new way of behaving. People need to learn how to learn “work with” rather than “work for”.

At the portfolio level, the organisation needs to bring all the business heads together in order to agree on the organisation’s backlog. This allows engineering to start managing its skill liquidity using a tornado graph to support investment and divestment of capacity. The organisation can become a team of teams and focus on its customers and it external competition rather than focus all of its energy on internal rivalries.

Screen Shot 2017-04-15 at 14.17.04.png

And this brings an uncomfortable truth and realisation to the CEO and Chief People Officer. Getting a business executive to give up their goals in order to help a fellow executive achieve theirs for the greater good of the company means that the (executive) reward system needs to be upgraded. An upgrade to reward collaboration and reward focusing on the goals of the overall organisation rather than sub-optimal local goals. It will take the HR function a number of attempts before they find the right path to a new successful reward system.

The organisation will need to implement a risk management system that allows business leaders and IT leaders to collaborate on managing the risks associated with investments involving IT. Not just copying a blog post but training audit and assurance functions in how to tell the difference between a well run project and one that presents a serious risk to the organisation.

The simple matter of funding becomes a issue at some point, though later than most think. Although the finance department needs to build a new way of funding projects, a more urgent imperative is to find a better way assessing the value that investments in IT deliver.

As well as learning to collaborate as a team, the executives need to learn how to create safe to fail cultures that promote learning. Executives need to learn an entirely new set of skills and behaviours. They need to learn how to create a new culture and tools for changing culture such as story telling and walking to talk. They need to learn how to see culture, the culture they need and the culture they need to move away from.

But before anything can start they need to build trust and respect with their fellow executives. Not something that happens over night.

And they need to do this fast, during their short tenure of five to ten years. No wonder they prefer big up front design, top-down transformations run by consultants who can be blamed for failure.

Starting an Agile Transformation Fast the obvious way

Doing it fast is easy. You select a method…. LESS, NEXUS, SAFE or DAD and simply roll it out. You hand out copies of the relevant book. You hire clever consultants and coaches, and you hire trainers to roll out standard training.

That “works” if you assume that an Agile transformation is “obvious” in Cynefin terms.

You will start fast and fail even faster, though perhaps only after you have spent a lot of money on consultants and coaches and training.

The upside for this strategy is that your bosses will perceive that you are a “get it done” individual who is making a difference. You will have a big up front design for your transformation. A big plan from a big name consultancy to get to success.

In the words of Helmuth von Moltke the Elder

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength” (or “no plan survives contact with the enemy”) and “Strategy is a system of expedients”.

Starting an Agile Transformation Fast the complicated way

Instead you may consider that an Agile transformation is “complicated” in Cynefin terms and seek “experts” or get a big name consultancy to undertake an extensive analysis.

  • If you are unlucky, you will encounter consultants who will show you powerpoint slides with lots and lots of detail of successful transformations at similar organisations, a brightly painted roadmap, and a standard process that involves time boxed analysis or capability assessments. They will have an army of graduates and cheap developers micro-managed by “get it done” leaders to help you transform.
  • If you are lucky, you will hire one of the small handful of people in the world who have real experience of creating genuine Agile transformational change… And they will tell you that an Agile transformation sits on the boundary of “complex” and “chaos” in Cynefin terms, with large elements of “obvious” and “complicated”. P.S. If you are wondering which stone to look under to find these people, you could do worse than start here.

You will learn the goal or destination in an Agile transformation is “complicated” which only an expert or analysis can tell you. Big name consultancies are good at providing a business case and delivery plan to help you secure funding and “commitment”. They will provide a nice “complicated” powerpoint diagram showing all of the elements of the new organisation. It will be a beautiful diagram with an even more beautiful story told by beautiful expert story tellers in beautiful suits with beautiful hair. It wont work of course, but it will be beautiful.

The good news about assuming the transformation is “complicated” is that if it doesn’t work, you can always blame the experts and their beautiful diagrams. This is a particularly popular strategy in risk averse cultures.

Finishing an Agile Transformation Fast the Complex / Chaos Way

Although the goal is “complicated” the transition from where you are now to where you want to be sits firmly on the border between “Complex” and “Complicated”. Although everyone might agree that the destination is Paris, the path you take will be different dependent on whether you are in Versaille, or London, or Tokyo, or Cape Town, or Athens, or Olympia, or more likely Olympus Mons.

Experienced agile practitioners will tell you that tales of success are inspiring but you need to dig beneath the polish and look at the failures. Success is more likely if you avoid the failures rather than try to emulate the success.

Screen Shot 2017-04-15 at 14.27.17.png

You will need to set up a portfolio of “safe to fail” experiments. Experiments that tell you the best place to apply LESS, the best places to try SAFE and DAD and Nexus. The best places to organise using the Spotify Model and the best to organise using the Buurtzorg Model. In order to make the experiments “safe to fail” you will need to speak to people with real experience of applying these approaches so that you can learn about the known failures. You won’t find out about failures from a sales brochure or a shiny powerpoint. You find out about them from people who trust you.

Executives attempting an Agile Transformation need to build a lot of trust and that takes time. It takes time to build trust with the Business Heads, and the CFO, and the CRO, and the CPeopleO, and the COO… Especially as the CIO is often not considered important enough to be on the board of non technology companies, often reporting to the CFO or COO.

When instigating a Lean Transformation Students of Taiichi Onho would insist on the board, lead by the CEO making a significant change to the production line. Taiichi Onho’s students would lead them from the boardroom and make them publicly dismantle a key part of the production line. If they were not prepared to do that, Taiichi Ohno taught them to walk away as they were not ready. If an organisation is embarking on an Agile/Lean Transformation, the first act of the board should be to appoint the CIO to the board (if they are not already on it). The second act should be for the board to go to the place where the transformation will start and dismantle the desks and dark cubicles with screw drivers and allen keys and , and replace them with collaborative spaces. The board should collaborate with the teams to create the Kanban boards that they want to see when they “Go the Gemba” to sit with the teams so that they can remove impediments and blockers for the teams. If the board are not prepared to do these things, they should abandon the transformation before they start.

The board need to understand that the transformation is not the destination. They need to understand that the transformation is the journey. They need to nourish and protect their experiments, removing impediments and blockers for them. At Agile2007 in Washington D.C. one of the participants stated that “Agile is a commitment to personal growth and learning as well as a company’s commitment to growth and learning.” The board need to make their trailblazers feel safe on their learning journey and shape a culture that supports growth and learning. The board need to be involved and make sure that improvements are happening. The board needs to ensure that value is delivered along the journey and not just at the end. A constant movement towards a better organisation.

A tale of two approaches

The Agile approach to transformations is to start small and gradually grow the size of your “safe to fail” experiments as you succeed. Start small and build your knowledge. Grow your people and get them to engage with the Agile community outside of your company. As you build your knowledge, build your infrastructure and risk management systems to support the new way of working. The key to success is growing the knowledge and experience of your existing people so that its your own people who do the scaling and not external consultants.

The executive approach is to hire a big name consultancy, create a top-down big up front design of the organisation and implement it in a big bang approach. Of course the bang normally comes just after the consultants have taken their fee. It is normally driven out of IT as an IT initiative without the need for proper engagement with the business. The IT executives do not need to learn anything new as they are doing it to their organisation rather than with the organisation. The good news about this approach is that the experts or consultants can be blamed when it fails.

Perhaps if CEOs were given the proper amount of time to roll out a transformation and given the proper support of their colleagues on the board (assuming they are on the board), they might try a more sensible approach.