Leadership

Designing technology systems around the people who use them

Systems fail in the hands of capable people when the design assumed a different organisation than the one that actually exists.

6 min read

Technology projects still fail in a familiar way: the process looked coherent in a workshop, the screens looked coherent in a demonstration, and then the people who do the work could not recognise their day in the system. They kept a side process. The official system became a reporting obligation rather than a tool.

Users are not a testing phase

The people who raise tickets, count stock, train staff or review KPIs already have a model of the work. A system that ignores that model will be ‘correct’ and unused. Designing around them does not mean collecting every preference. It means understanding the constraints they operate under: time, language, connectivity, approval paths, and what they will be blamed for if something goes wrong.

Leadership uses systems too

A second failure mode is designing only for operators and leaving leadership with exports. Executives then recreate the spreadsheet the system was meant to replace. The product needs both surfaces: the operational one that records the work, and the leadership one that makes the work visible without distorting it.

The central discipline is unchanged: understand the business problem, understand the technology, understand the data, and build the solution with the people who will live in it. That is not a softer form of engineering. It is how engineering becomes useful.

This article is a starting point. The page structure is ready for a longer, fully edited version later.

Further reading

Next step

Have a problem worth solving?

Whether you need technology strategy, a data solution, a business application or help transforming an existing process, let's talk.