Month: May 2025

I read something yesterday that got me thinking – it said that a particular approach was “a simple framework to solve complex problems”.

I’m not sure that’s the right way to look at it.

The real world is messy. Everyone knows this.

If you have a complex problem-situation – one that has people with different, perhaps incompatible views, and options with different costs and benefits – surely it doesn’t make sense that some simple framework can address such complexity.

Wouldn’t you need an approach that’s capable of at least as much complexity as the situation? Just to match up the situation and options for resolution.

It’s like consultants who come in with a four-box framework and think they can apply it to any client.

And, if you’ve been on the receiving end, you know that this usually ends poorly.

Simple approaches are fine for simple problems.

That’s why the promise of bait and switch approaches are that here’s an easy button, this is a simple solution, buy this and things will get better.

They probably won’t.

Some people go the other way.

They use complex approaches to address simple problems.

That’s just a waste of resources.

The pragmatic way is to accept that the real world is messy and complex and engage with it – to learn, understand and figure out an appropriate approach.

That’s where value hides.

If I had to pick one thing that’s changed the way I work it would be understanding the difference between variation and variety.

I used to believe that the way to do better work was standardisation.

You improved quality and productivity by using tools like 5S – sort, set in order, shine, standardise, sustain.

I’d bet you’ve listened to someone suggest that the answer to a problem was standardisation – we need a standard for this.

And that’s because standardisation works, in a particular context – that of factory work.

If you’re in the business of making cars then you want to have standards – every piece of glass for a particular model of car has to be the same – as close as possible.

You’re trying to make lots of copies of a particular type of thing – you want to remove any variation in the product.

It takes effort to reduce variation. Try drawing nine squares that are exactly the same and you’ll quickly find out how much.

But most of us don’t work in factories. A lot of us are engaged in information work.

And with information work, no two situations are exactly the same.

Trying to use a standardised approach doesn’t work. One approach may work with one client, but the minute you try and apply the same approach with the next one, new and interesting ways to derail your plan come into existence.

But it’s more complicated than that.

As Robert Pirsig said, no two people are in the same situation and have the same problems.

But, in contradiction, in some ways everyone is in the same situation and has identical problems.

What makes the difference is that situations contain variety.

Learning how to deal with variety is the first step to building solutions that work for more than one client.

It’s much easier operating in a startup in the early days.

The team is working in a messy, complicated space where there are no right answers and you have the freedom to explore the problem-situation and create solutions that wrap around a customer.

As you get bigger, this gets harder to do.

In large corporate organisations you come under pressure from people in roles that are more about risk reduction than value creation.

You’ve created the value in the earlier stages, now the challenge is to keep that value.

The pressure often ends up squeezing some people into a box – perhaps squeezing others out altogether.

It’s probably inevitable that as a company gets bigger it focuses more on internal power dynamics than customers.

More companies go under, I remember reading, because of internal problems than because of competitors or customer behaviour.

Technogists think they are far more important to a manager than they really are.

A typical manager has to operate within an organisational hierarchy.

The overt hierarchy is in the org chart. The real hierarchy is in the power relationships between the people that work in the organisation and managers spend a lot of time understanding and navigating implicit currents of power.

They have to plan courses of action and get approvals – which requires being tuned into the politics and culture and how things work around here.

They have to juggle resources, manage teams and research options.

When it comes to systems, then, they’re usually not interested in learning everything about every feature and having to deal with technology folk.

They just want it to work.

Good technology is like plumbing.

You should never have to worry about it.

Systems and processes should just chug along reliably and regularly in the background – letting managers get on with their real work.

Dealing with people.

Managers won’t be able to delegate to generative AI until they can rely on what it produces.

We need proof that it works.

I’m not seeing that yet.

I’m not anti-technology – as an engineer I’m trying these new tools out and running several experiments.

But as an engineer, I also want solutions that work, that are reliable, and that can be left alone to do what they’re supposed to do.

Software that comes with a warning that its outputs may be wrong and need checking are not particularly helpful.

The only time you’ll use that output is when the output doesn’t matter – such proposal filler or a quick email response.

Or if there is a human in the loop with ultimate responsiblility for agreeing with the output – such as checking the results of a medical image diagnosis.

But the messy middle may stay messy.

When something is important and needs to be done right – what are you going to do?

You don’t really want to commit a career limiting or career ending blunder.

Perhaps the approach many managers will take is to outsource tasks to consultancies that use specialists that leverage AI rather than bringing AI in house as a replacement for recruitment or capability building.

After all, it’s always easier to fire a consultant if things go wrong.

Every once in a while I’m reminded why Excel is such a good tool for managers.

I started my career with a toolbox full of programming techniques, a notebook full of perl scripts and python recipes.

But I quickly learned that programs have to be maintained and operated and most managers aren’t programmers and don’t want to manage programs.

Instead, they want something they can understand, use, modify and explain.

And Excel still fits that role as a simple, unpretentious workhorse tool that can do everything from data management to sophisticated modelling.

If you know how to get the most out of it – but most of us are never taught how to use Excel effectively.

One of the best books on the subject, if you’re interested, is – Management Science, the art of modelling with spreadsheets – by Powell and Baker.

I particularly like their use of influence diagrams to build simple but powerful scenario models.

Before you opt for a cloud SaaS product it’s worth asking whether you really need that and if you could instead just use Excel to get 80-90% of the way there.

I was talking to a friend yesterday about how our experience of the sales process has changed over time.

Selling is a critical part of a business – it’s what makes everything else possible.

But too much selling is based on Freudian principles, assuming that the main drivers for buyers is to seek pleasure and/or avoid pain.

Victor Frankl, on the other hand, thought that people’s primary drive is towards finding meaning in their lives.

This is a more nuanced lens that is tricker to pin down.

The idea is that we tell stories to make sense of the world around us.

The stories we tell, especially about how we see problematic situations unfolding in front of us, give others insights into the way in which we structure our understanding and find purpose and meaning.

For example, the way in which you approach sustainability will be different if you are a purpose-driven firm that wants to minimize your environmental impact versus a profit-driven firm that wants to comply in a meaningful but compliance-led way.

Purpose matters.

If we understand purpose then we can build solutions that are fit for purpose.

Interestingly, that’s now the accepted definition of quality.

Juran’s quality handbook defines quality as \”fitness for purpose\”.

But how do you understand purpose from a buyer’s point of view?

That’s where having a good discovery process at the front end of your sales cycle is essential – and that’s the thing that’s changed.

Fewer decks, less pitching.

More listening and more problem structuring.

Will something like vibe coding take off? As an operations manager, should you or I spend more time on this, or will it pass away in a year or so?

I was just thinking about a post by Judah Diament – seen via mastodon, starting on BlueSky – about a computer scientist’s perspective.

As engineers and managers we need things that work.

Success or failure matters.

With a new tool, the promise always is that “this time it’s different”.

The opposition to that starts with a minimal knowledge of history. There have been many tools that aimed to construct complete applications.

But the market wasn’t ovverrun by automatically generated applications.

These tools produced code and documentation and you could understand what was going on.

Their successors live on in frameworks that you can start from and build on – but no one pretends they are ready out of the box.

That’s because any real world application has variety – it needs changes, has complexity, introduces unusual requirements.

At some point, you may need to understand what’s going on to match a client’s needs – and how can you do that if the output is unpredictable and depends on the particular prompt you used?

Then there’s the question of value.

If an entire system can be created from a single prompt, then what’s the value of the output?

It’s probably the cost of the prompt in whichever platform you’re using.

Say you can build an application for ten dollars.

If an operations manager can do the same thing then she might as well use the prompt to create the application too.

The real cost comes over time, in customising and maintaining that application.

The value then comes from the team that delivers the ongoing service to the manager, not the product.

In short, if this approach starts to succeed , the cost of products will fall close to zero.

Managers will instead pay for operations and maintenance teams to understand and keep this pile of code operational.

The SaaS model becomes one where the S for service starts to matter much more than the S for software.