Category: Rich Pictures

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.