When Tools Are Asked to Do Human Work

There is a pattern I’ve seen in technology decisions that becomes particularly visible when organisations are under pressure to demonstrate progress. A problem is identified, a new platform is proposed and the discussion quickly turns to features, architecture and delivery timescales. What receives less attention is whether the problem was ever primarily technical.

It’s an understandable response. Buying or building a tool gives a problem a tangible shape. It creates a plan, a budget and something that can be shown to stakeholders. Resolving disagreements about ownership, priorities or how a business process should operate is often much less straightforward.

When the solution arrives before the question

I don’t think organisations usually make these choices through carelessness. Leaders are expected to improve performance while managing limited resources and competing demands. Technology offers the possibility of progress without having to revisit every difficult organisational conversation.

The difficulty is that software tends to reflect the decisions and assumptions surrounding it. If two teams disagree about what a measure means, putting the measure into a new reporting platform doesn’t resolve the disagreement. If nobody has authority to approve changes to a process, automating that process may simply make the uncertainty less visible. The system can appear to be functioning while the original problem remains.

Infrastructure decisions can follow a similar pattern. An organisation may adopt a more elaborate architecture because it signals resilience or maturity, without first establishing which failures it needs to withstand and who will be responsible for responding to them. The resulting system can be sophisticated and still difficult to understand or support.

The work technology cannot do for us

Some of the most valuable questions in a project are also the least glamorous. What are we actually trying to improve? Who experiences the problem? Why does the current process work the way it does? What would a better outcome look like, and who gets to decide?

Answering those questions can expose disagreements that a technology project would otherwise allow us to avoid. That may feel like a delay, but it is often the point at which the work becomes useful. Once the organisation has established a clearer understanding of the problem, the role of technology becomes much easier to define.

None of this is an argument against modern platforms or automation. Good tools can make an enormous difference, especially when they remove repetitive work and help people act on reliable information. But they are most effective when they support decisions the organisation has taken responsibility for making.

At MycoFlow Systems, I want to remain conscious of that distinction. The temptation to start with an architecture diagram is always there, particularly when the technical possibilities are interesting. Sometimes the more useful contribution is to ask a difficult question before anyone starts drawing the boxes.