Faster. Faster. And The Pillars of Management - Cultivated Management Newsletter
Hi all,
Hope you're having a good week this week.
This week I've been thinking about speed and how many organisations set objectives around being faster without understanding whether they are indeed slow, or whether or not speed is really the issue.
It's entirely possible to move quickly but deliver rubbish. Speed doesn't come without other dimensions and challenges. What's going to give? What's important to measure? What's the evidence for change? Is the business geared up for speed?
Faster. Faster. Faster. You're too slow!
Faster. Faster. Faster. Deliver faster. We must deliver faster. We're too slow. You're too slow. Everyone else is faster than we are. This push for speed is often a directive from well intentioned execs who don't see the numbers heading in the right direction. The request for speed can often come from people who've worked in places where things were faster (usually with little mention of whether that speed lead to increased customer happiness or revenue). And sometimes the need for speed comes from political battles between departments. The problem is also compounded by simple measures of productivity that rarely tell a complete picture. How many features have we shipped this week? How many cases have we closed? How many widgets did Bob create?
These are single dimension measures that can encourage people to say more, more, more. Faster, faster, faster. All without really understanding whether speed is really the answer, or whether or not it's even possible. System constraints are very real. The problem with focussing on speed alone is that it often ignores the real elements you should be measuring - the real reason your team or company exist - and that is to add value for your customers.
Value is not a single measure. It is often made up of many different elements and it must be measured over time. Snapshots are dangerous. Trends are important.
What are you trying to achieve and have you achieved it? Speed is a dimension in delivering against that purpose, but so too is quality, communication, cost, morale, revenue, customer satisfaction and many other dimensions.
If you're a manager and you're tasked with making things faster then consider asking a few clarifying questions around the measures.
For example if you are measuring the number of features shipped in a month (a very common measure of speed!)?
How many stayed in production?
How many have issues?
How much revenue/value/potential was released from the feature? (i.e. are we building the right things? Little point in going faster and delivering the wrong things that don't unlock value for both customer and business)
How many people are using the feature (ever seen a company release a feature that nobody used?) "Don't worry nobody is using it - at least we did it quickly!!"
How much rework or failure demand has been generated? By moving quickly did we rush it and get it wrong - how much work have we generated because of this - this is a crucial measure.
Or let's say you're measuring how many cases are closed per week?
How many were opened in the same time period? Did more come in than we close or less? This is a good trend to study.
Were all cases closed to the customers satisfaction?
Were the cases that were closed easy ones (i.e low hanging fruit)?
How long were the cases open for?
What was the reason for the case in the first place?
How many were the same case just phrased differently? (I know someone who got a large bonus for closing 25 cases in one day - they were all the same issue just phrased differently)
How many were caused by a failure elsewhere in the company - and have we prevented future failures?
What have we learned from this and have we improved?
Over time - how does this set of data trend? Or did we just have a great/poor month?
If you move fast but don't deliver value then what is the point?
I'd rather move slowly but ensure that whatever got shipped met the needs of the customer and didn't bounce straight back in. Was it good enough quality to add value?
An often hidden (or un-investigated) part of moving too fast is the failure demand caused by getting it wrong. Failure Demand is the demand caused by a failure to do something, or do it right, earlier. So let's say you ship some bad code and it generates a ton of support calls. It then comes back to the development team to be fixed interupting the next set of work. In moving fast and getting it wrong (cutting corners, lack of testing, rushing it through the pipeline) more work has been generated in support and Dev. It was fast, but it was expensive (and are you measuring that?). If all you measure is speed you only get a rosy picture - the reality is you're generating rework.
So surely moving fast must only be an option if doing things right is also included in this intent. Move fast and do things right. I like that better. Move fast and make sure we meet the purpose and our customers are happy.
And this is how I've always approached it. Build a process and set of methods that delivers value - then work hard to make that process as smooth as possible. Slow is smooth. Smooth is fast.
Most manaager don't push back on the request for speed though. Most managers don't measure things like failure demand. It's easy to just say yes - let's get faster. Yet deep down inside you know it's going to create rework and angry customers.
Here's some advice on how to challenge the speed request if you think it's unfounded:
Ask for evidence. What evidence shows that your team are slow? Challenge it, but with powerful questions.
What other dimensions come with speeding up assuming quality must remain high? Or can we ship rubbish? (Where is the pride in that - yet many do it)
What measures are in place to say whether or not you're getting faster?
What measures are being left out?
Who chose the measures and what were their intentions? Are you stuck in the middle of a political battle between people?
Are the measures related to your team's purpose? Or related to a business metrics that looks good on a report? Did the execs or managers demanding more speed make the target up? (Like the usual - this year we will be 3% more efficient). Or was it based on what was actually achievable?
Is there any failure demand in your process? If so, how many man days are spent on it, where does it come from and can you turn it off. Is it caused by going too fast?
What happens elsewhere in the system if you speed up? Can other teams who consume your work keep up? It's not uncommon for Dev teams to actually have to slow down as the rest of the business cannot cope with the flow of work.
Does speeding up deliver flow or bottlenecks (map it, follow it, report it)
What happens if you do speed up? What next? How will you celebrate? What speed is fast enough?
Above all though start measuring failure demand in the system. Measure it in terms of person days. Measure all of the hours people are working on fixing things that the business didn't get right, or didn't even do first time round. Then turn that person days in to a monetary value. Work out where the demand comes from. Put together a report for the execs and outline where the problems are and how much it costs the business.
And above all - accept the challenge. You may indeed be too slow. Embrace this fact and work hard to improve. Never challenge without first understanding where the evidence comes from and the reality that you may actually be slow at delivering.
But don't ever accept the slur on your effectiveness if unfounded. It will lead to process change and targets that degrade the value of your service and make it harder for you to deliver value.
Face the claim, prove it right or wrong, but above all else - set in motion a culture of relentless improvement. Speed isn't everything. Perceptions are usually wrong. Don't allow others in the business to dictate programs of change based on hot air, rumours, perception and arbitrary numbers. Do the right thing as managers - go and see for yourself, study what is going on, accept what the study reveals and improve based on the evidence.
If you do that you will indeed become smoother at flowing work through your process. And smooth is very much fast.
Here's some final thoughts.
Slow is smooth. Smooth is fast.
Move quickly but move carefully.
If you don't have time to do it right now, when will you have time to redo it?
Book of the week
I'm still reading it. It's epic. It's long. It heavyweight. It's all about debt. I'll let you know once I've finished it.
Until next time. Go faster :)
Rob..