Author: grahamchastney

My grandma loved this saying and repeated it often. Whenever something went wrong with her latest piece of knitting, or needlework, she’d chide herself under her breath – “less haste, more speed.”

I was recently on a day out with a friend in his canal boat. Canals in the UK are a construct of the Industrial Revolution that have, in recent years, been reclaimed for leisure purposes. The one we were traveling on dates from 1792.

If you are from the UK then you know what I mean when I talk about a canal, if you are from outside the UK the header image and a couple at the end will give you a good idea.

Each of these narrow, relatively shallow, waterways were used to transport heavy goods around the country at the speed of a horse’s walk. This was at a time when the speed of a horse’s walk was a lot faster than any other way of transporting such bulky goods. We were in a small leisure craft enjoying the sunshine at a sedate 4 mph (human walking pace).

My friend doesn’t have a traditional iron/steel narrow boat, but a fiberglass leisure craft known on the canals as a yogurt pot.

I was driving and trying to keep a good pace so that we could make it to the pub for lunch. We’d recently pulled past another slower boat that had kindly pulled over for us (overtaking is not allowed) when I felt the boat veering off to one side. In my haste I over-corrected and the boat swung off to the other side. Still feeling the pressure to act I turned back the other way resulting in the boat leisurely, but forcefully, veering off into a bush on the bank with a firm stop. The strange thing was even at walking pace it all felt like it happened very quickly.

To get out of the bush we needed to reverse, slowly, make sure there wasn’t any damage, manoeuvre to the right part of the canal and then we could continue. Before long the slower boat we’d sped (slowly) past earlier was up behind us and waiting for us to get on our way. It would have all been a lot simpler if I’d driven just a little bit slower and not taken any hasty actions. Even at 4 mph it is quite easy to get yourself somewhere you don’t want to be.

I may know the phrase “less haste, more speed” from my grandma, but it’s really an old Scottish phrase according to the small amount of research I’ve done.

Interestingly I remember the saying this way around, but in the old Scottish it’s the other way around “more haste less speed”, or for those of you who speak old Scottish “of fule haist cummis no speid.”

It is a very old saying. It was documented in the 1600s which means it’s almost certainly much older than that, not too many things were documented before then.

There is a similar saying in the Proverbs of the Old Testament of the Bible making the sentiment much older still:

Enthusiasm without knowledge is no good;
haste makes mistakes.

Proverbs 19:2

It may be an ancient saying, something deeply rooted into our thinking, but it doesn’t stop us needing to repeatedly learn its lesson.

Can you remember a time when someone was criticized for a decision that was too slow?

Can you remember a time when someone was criticized for a decision that was too hasty?

It’s all a matter of perspective.

Fast sounds better than slow.

Measured sounds better than hastily.

Rapid sounds better than protracted.

Deliberate sounds better than reckless.

In my working career I’ve been in many situations where people have been desperate for a swift decision. Looking back, many of these decisions were taken in haste and would have been much better for being more measured.

We sometimes need to sit back, take a deep breath, and resist the need for speed.

Much of the time the impact of hasty decisions is minor but there are many decisions for which a correct answer is vital.

Here’s another very old saying much beloved of makers and decorators alike:

Measure twice, cut one.

(Apparently, if you are Russian, you measure seven times before you cut.)

There are many decisions that don’t involve a “cut”, but the ones that do need to be right.

Organisations can get stuck treating all decisions as the same and expecting all answers to be processed at the same speed – fast. We can do the same in our personal life when we anxiously ponder over a decision that once made can be reversed immediately while blindly rushing into other decisions with long lasting consequences.

Some organisations use a framework popularized by Jeff Bezos and talk about one-way door and two-way door decisions. The decisions with a cut are the one-way doors needing careful consideration because once made, they are made. If there were any decisions around which haste should be avoided, it is these one-way door ones.

There is much in business that is too slow, too pedestrian, but we need to be careful that our relentless drive for speed doesn’t set us on a course where we find ourselves in a bush on the canal bank.

Header and Footer Images: These are some images from the Lancaster Canal on a sunny day making progress at 4 mph.

I’ve worked around corporate IT systems for most of my adult life and what follows is a common, if slightly embellished, history of how organisations get into a mess:

• We had a need for a system to do X.
• Another team had a need to do Y. The managers of team X and Y are in different parts of the organisation that don’t like to collaborate.
• Despite the lack of collaboration we decided that we needed some of the information from Y in X. We built another system, Z to move some of the data between them.
• Y didn’t work very well so we built A, but never decommissioned Y. We had already added some customers to Y and it is always difficult to move customers. One customer who uses Y is particularly difficult.
• People liked to use A so we added some customers to it, but different customers from the ones that use Y.
• Another team in another part of the organisation build B. We then discovered that B was similar to Y but worked differently, so we built C to make them work together in a similar way to Z.
• We then got a new leader who had worked with D in their previous organisation and have spent the last year trying to get D to work like Y, with data from X, A and B. We needed another system, E, to move the data between D and Y as an interim solution while we did the development.
• The leader who was a fan of D has since left the organisation and everyone is unsure of its future. The technical people the leader recruited from their previous organisation have also left to join them at their new venture.
• The team that built Y has since been allocated to other work so no-one in the team knows how it works anymore. We need Y to work, because the difficult customer is still using it.
• We’ve recently experienced problems where we’ve been getting inconsistent results from some of these systems and it’s becoming embarrassing with our customer.
• Given these recent issue there’s a strong tendency for action hanging over everyone and the prefer actions is to add something. “Perhaps we need system F?” says someone “I’ve used it before and it was brilliant.”
• The reality is, though, system D will do everything every team needs and D is already being paid for, but moving everyone over to it will take work. It’s going to be particularly difficult to move the long-term middle managers over who are heavily invested in X, Y, and Z. Each team is convinced that what they do, and how they do it, is unique and vital to the running of the business.
• No one really knows how A, B and C work and are scared of touching them, fearing a catastrophic breakage. That fear includes a fear of shutting them down.
• Another challenge is going to be moving the customers away from Y and A, what’s in it for them? There’s also that difficult customer to worry about.
• Perhaps adding in F isn’t such a bad idea after all?

One addition has lead to another. The result has created further complication and even more technical debt.

There were plans to remove some of the technology, but they were never achieved. The whole thing has become like that tangled box of cables you have stored away somewhere.

I’ve seen the same thing with processes with particularly experience of review processes. The story is almost identical to the above:

• Review A spawns review B and C.
• Review B and C spawn reviews D, E, F, G and H.
• Review H spawns review I and J.

Each of these reviews takes an hour and 5 people (if you are fortunate) – the burden of a simple review is 50 hours without preparation time.

There’s always going to be a noisy middle manager who insists on having their own review meeting and it’s not always easy to resist these demands, but giving in to them has a very high cost.

Before you know it people are spending more time reviewing things than creating things, particularly the poor people presenting.

It is hard to remove in these situations, but the results are way better than adding “system F”. You know that taking everything out of that cable box and throwing half of it in the recycling is a much better answer than trying to wheedle out the one cable that you are looking for. You know that shutting down the spawned reviews is a much better answer than keeping them going and frustrating everyone.

Adding “system F” might feel like a better answer, but it’s a bit like eating another cookie to help you feel better about being unfit.

Header Image: This is St. Mary’s Church, Longsleddale looking down the dale on a recent spring morning.

This post portrays a fiction, a caricature. I have never worked in this organisation, but I have seen parts of it in many organisations.

There’s a much-used management saying that often get mis-attributed to Peter Drucker: “What gets measured get managed” it also exists in the negative form “What doesn’t get measured doesn’t get managed.”

This is a mantra bouncing around inside the head of millions of people and today it will be regurgitated in hundreds of thousands of meetings.

Somewhere in the world, right now, there is a team of people meeting together who have been given a problem to solve and one of their first tasks will be to get the data together.

“How often has this happened?”

“Who has this problem?”

“What is the evidence for this problem?”

Somewhere else a team will be trying to work out how they complete a task, run an operation, define a service level, design a sales campaign, or any one of a thousand scenarios. In each of them somewhere conscious and subconscious will be the phrase “What doesn’t get measured doesn’t get managed.”

To many this is known as the understanding phase, or the problem definition phase, sometimes it’s known as the fact-finding phase. In this time of chaos people need information to help them to make decisions and take actions.

This is where it can all start to go a bit wonky. Somewhere in the mind of one of the meeting participants is another phrase “How are we going to measure success?” This question is followed by an equally wonky question “What are we going to report to the management?”

These two thoughts coalesce together into another thought “We need a metric.”

Not “some metrics”, not “a balanced scorecard”, not “metrics and observations”. That’s all too complicated for “the management”, they are too important and too busy to cope with anything fuzzy or squishy, they need a metric.

Once the team has a metric they can create dashboards, draw charts, create RAG (Red, Amber, Green) status charts. They can show that all of the effort is producing results because the metric says it is. The team is a success because you can’t argue with the metric.

The team looks around to see what the metric could be. Measuring overall business value is too difficult, too abstract, but there is a metric that can be used. This metric is easy to collect from the systems available and doesn’t require any complicated analysis. If the team focuses on this metric then it’s “guaranteed” to increase the value to the business, isn’t it?

And thus the task is set: the metric will be communicated, a dashboard will be built, the metric will be reported, the metric will be reviewed, the metric will be served. There will be consequences if the metric doesn’t go in the right direction.

Unfortunately, no-one in the team has given any consideration to the law of unintended consequences. The metric has been chosen without any consideration towards the people factors involved in the metric.

The communication of the metric begins “Reducing/increasing the metric is our highest priority.” The organisation has been set a new focus and the new focus will be served.

People’s focus switches to the metric and away from all other metrics. One unintended, but inevitable, consequence of an increase in focus on one area is a decrease in focus on all other areas.

Middle managers suspect that this will be another one of those short-lived initiatives so look at ways in which they can influence the metric without doing too much work. As they analyse the metric they realise that there are several factors involved in its composition.

These middle managers are wily operators who’ve seen this show before, they know that there are things that they can do to manipulate the metric.

They instruct their staff to enter details onto the system early/late so that the next collection of the metric is higher/lower.

They look through the list of things that are included in the metric and reclassify work into/out-of the metric.

They split/join records in the systems so that the metric is again higher/lower.

They start to record some records in an excel spreadsheet away from the corporate system to serve the metric.

They shift their focus away from the big things that only influence the metric a small amount onto the little things that influence it a lot.

They move staff away from work that doesn’t influence the metric and onto metric changing activities.

These middle managers are careful though, they don’t use all these measures from the beginning. They know that the metric and how it is shown on the dashboard will need to continue to change. It’s not enough for the metric to change once, it needs to change every week/month/quarter. The dashboard needs to move from red to amber to green. It can’t suddenly go green no-one will believe that. They sandbag some of their manipulations for the next iteration of the metric.

Steadily the metric begins to move. Everyone involved waves their hands in the air and cheers the success.

The team is seen as a huge success and is moved onto another project/problem/etc. where they again analyse the problem, define a new metric, and develop a new dashboard. No one visits the old dashboard anymore. The senior managers cancel the review meetings for the original metric, it’s still collected but it’s ignored. Everyone’s attention has moved to the new metric, the new dashboard and the new meetings.

Only a few people notice the irony of the attention given to the original metric being the cause of the new problem and the need for the new metric. The new metric, again, ignores the human aspects.

Beware of the metric – cave de metrico.

Header Image: This is a view of the Vatnajokull Glacier as it flows out toward the south of the island. (No, I don’t know how to say that word.)

I have worked with many different organisations, mostly businesses, in many different sectors.

In that time, I have noticed this general rule: businesses think at the pace of their product life cycle, in everything.

Where this applies to me is the knowledge that there isn’t a pace at which organisations think about their IT, organisation think at their pace a pace that is set by their product life cycle.

I first noticed this when I switched projects between two organisations in two completely different sectors. The first organisation was a utility engineering organisation where the product life cycles could be measured in the decades, the second an advertising and marketing organisation where they were launching products all the time and campaigns might only last a few days. One was purposeful and methodical in its adoption of IT and consumption of change, some would say, slow. The other was all about action with quick fire decisions made every day, and the worst thing you could do was not act.

I’ve since observed different organisations in different arenas and found this rule to be generally true (with some exceptions of course).

Manufacturing organisations where the life cycle of the product is 20+ years think at a similar pace to financial services organisations that focus on long life cycle products like pensions.

Consumer insurance companies can be launching new products all the time and think at a similar pace to a consumer technology organisation.

Deep in the back office of these organisation you have the corporate IT team, which itself has a desired life cycle and a desired pace. There is some flexibility in that pace, but there are huge external forces defining the minimum pace. Security compliance demands a rate of patching and updates. Technology vendors demand a pace of upgrades to retain supportability, and profitability. The currency of skills also plays a significant part.

The person stuck in the middle of these mismatched paces is the IT manager who needs to think at two paces. They are a bit like a drummer trying to make music while playing one tempo in their left hand and another one in their right.

The current transformation around AI is, again, highlighting this dilemma.

I am sure there are IT managers in long life cycle organisations who are head down avoiding the bright young things in their own team who want to transform their company by adding AI here or by sprinkling an agent there. Meanwhile, in these more methodical organisations, the IT manager is trying to work out how to get spare parts for the 1980s manufacturing systems that keep the organisation solvent. Or they are trying to work out how much longer they will have the skills available to maintain the pensions application last updated in 1999. Over in the faster-paced organisation the IT manager is trying to work out how they get all of those bright young things to talk to each other and stop the costs ballooning.

This IT manager is the same one who thought they had managed to ride out the same pressures from everyone wanting them to move at the pace of the cloud.

The life cycle correlation is often strongest in organisations where the IT department report to the VP for Finance, so perhaps it’s Finance that sets the pace?

(It’s also worth noting that both the fast-paced and more slow-paced organisations both have a problem with technical debt. One struggles to make decisions fast enough to keep up, the other struggles to give attention to decommissioning things.)

Personally, the lesson here is one of expectation. I set my expectations on pace by the life cycle of the customer product. Expecting a slow-moving, methodical organisation to make decisions fast is a road to frustration. Expecting the fast-paced organisations to consider their decisions leads to a different frustration. Sometimes I am wonderfully surprised, I’d rather be surprised than frustrated.

Header Image: We are in snowdrop season as the first signs of spring start to show. These are on the grounds of a local historic house which is now owned by the local community.

How busy are you? Was your immediate response “too busy”? You aren’t the only one.

Many of us know that frustrating feeling of being asked about an action in a meeting only to realise that we haven’t made any progress because we’ve been in back-to-back meetings since the action was given to us. Why didn’t we make progress on the action? Because we didn’t have any margin.

If we don’t even have margin to complete our actions then how are we going to start new things, more interesting, more fulfilling things.

There’s a relationship here with my previous post Irreplaceable = Unpromotable | Working Principles.

Organisations are littered with activity that is no longer required, things that are being done because they’ve always been done, business that is consuming our margin to do that special something.

When was the last time you looked through your daily activities and asked yourself – why? Why am I doing this? If I stopped doing it would anyone notice, would anything break? If I don’t attend this meeting, will it make a difference to the outcome?

I have occasionally run little experiments where I have quietly stopped doing things. In most of these experiments my lack of activity went entirely unnoticed. A big part of my workday is taken up with meetings and it turns out that there are many meetings that run just fine without me.

If we don’t even bother asking ourselves why we do things when was the last time you contemplated these questions? Is there a better way of doing this? How does Jane/John do this so much quicker than I do? Where can I learn from others? What can I do to simplify and automate this activity?

Remaining curious is a wonderful thing and another great way of ceasing activity, but we need margin to even start to answer these questions.

Another question we should be asking ourselves is, what is all this activity costing? I’m primarily talking here about the missed opportunities. Yes, there’s a cost in the churn of time, but there’s a much bigger and far more significant cost when we consider the things we didn’t do.

What if we had attended that training rather than attend that meeting?

What if we had worked through that difficult problem rather than respond to those 200 emails?

What if we had ignored all those chats and instead taken a walk at lunchtime?

There are all sorts of complex reasons why we don’t do this, it’s not easy. Life is full of competing “what if’s.” What if I don’t attend that meeting and something vital happens? What if I don’t respond to those emails and miss one that is crucial? What if I ignore those chats and one of them is from my boss needing my urgent help? There’s a potential cost to stopping, but there’s already a cost to continuing.

We need to create and guard the margins, the best way to create margin is to stop doing things, but that’s just the first step. Having eked out a margin, we need to protect it. Sadly, not many of us work in organisations where they manage our margin for us, we are going to have to be the watchkeepers of our time and attention.

For me there are a few ways that I try to master my margin. The first way I do it is to use the tools available to me and define Focus Time in Outlook. This is one of those areas where a little bit of AI helps in the form of Viva Insights and the Focus Plan. Rather than booking the same time every day which is impractical for most of us, using Viva Insights my Focus Time is created in the slots without prearranged meetings. The Focus Time is booked with notifications turned off and my status set to “Do not disturb.” There are some people who I need to respond to if they reach-out, so they are defined as “priority contacts.” They know that if they really want me to respond they’ll have to mark the message as urgent.

The other thing that I do is to make sure that my priority list for the day starts with the high-value item that I want to do in my Focus Time. There’s a mental note there that the highest priority is in the highest value, not in the meetings, the messages or the emails.

Even with Focus Time defined I still need to protect my margin from myself. It can be a temptation to regard Focus Time as a great time to go through my inbox which is highly unlikely to result in anything of true value. The curse of urgency over importance.

Another important part of guarding my margin is my morning walk, a time when I try to focus on being present. Margin is as much about mental state than anything else.

Some people have more freedom and flexibility than others. Some people are better at this kind of self-organisation than others. We each need to find our own way but if we don’t create margin we generating huge missed opportunity costs.

Header Image: A recent frosty morning walk sunrise.