Start With the Work

One of the strangest realisations I've had over the last few years is that I don't think I work in technology anymore. That probably sounds like an odd thing for somebody who spends most of their time building software to say, but the more I've thought about it, the more convinced I've become that it's true. In fact, I'm not sure I ever really worked in technology. I just thought I did.

For most of my career, if somebody had asked what I did for a living, I would have said, "I work in IT." I implemented systems, managed projects, solved technical problems and joined applications together. It was a reasonable description of the job, although it said very little about the part I enjoyed.

And yet, when I look back at the projects I've enjoyed the most, very few of them were actually about technology. They were about understanding. Understanding why somebody was frustrated. Understanding why a process existed. Understanding why intelligent people had created complicated workarounds around systems that were supposedly designed to make their lives easier. The technology itself was almost always the least interesting part. I don't think I fully appreciated that at the time. Like most people in our industry, I assumed that software was the product. The work taught me that software is often just the visible outcome of understanding something properly. That's quite a different way of looking at the world.

It's also why I increasingly believe that technology changes every year while many human problems remain remarkably familiar. The tools, interfaces and acronyms change, and the hype certainly does, but people are still trying to communicate, organise, make decisions and help one another. We have become extraordinarily inventive about the technology involved in those things without always making the things themselves easier.

Once I started looking at organisations through that lens, something interesting happened. Industries stopped looking quite so different. At first, that felt uncomfortable. After all, a restaurant and a garage don't appear to have much in common. Neither do a care home and a florist. Or a consultant and a physiotherapist. But when you stop looking at what organisations do and start looking at what people inside them are trying to achieve, the similarities become difficult to ignore.

A restaurant isn't really about tables, bookings, orders and payments. It's about people trying to create a great experience for somebody else. A garage isn't really about vehicles, labour rates and job cards. It's about people trying to solve somebody's problem with as little friction as possible. A care home isn't really about assessments, rotas and medication records. It's about people trying to care for other people. Technology isn't the purpose. It's the assistant.

That sounds obvious when you say it out loud, yet plenty of software conversations still begin with "What system do you need?" I find it more useful to ask what people are trying to achieve and what gets in the way. Otherwise, we can agree on a product before we have agreed on the problem.

When somebody asks for software, we've learned to become suspicious. Not because people are wrong, but because people naturally describe the solution they've already imagined. What they're often unable to describe, at least initially, is the problem beneath it. That's why those first conversations tend to look slightly unusual. While traditional software projects begin with features, requirements and specifications, ours begin with curiosity.

What slows you down? What gets copied twice? What do you apologise for? What makes you sigh? What happens every Friday afternoon that nobody enjoys? Those questions sound less professional than a requirements workshop. They're also far more useful.

Because people rarely reveal their problems through requirements documents. They reveal them through stories. Stories are probably the richest source of operational understanding we have. When somebody starts telling you about their day, something remarkable happens. They stop describing systems. They start describing reality. They tell you about the customer who phoned at the wrong moment. The spreadsheet that nobody trusts. The report that always needs adjusting. The process that was meant to be temporary six years ago. The experienced employee who remembers all the exceptions because nobody ever documented them. That is where the useful work begins. Not with software. With curiosity.

And perhaps that's the hardest lesson I've had to learn. Most of my ideas are wrong, including some of the ones I have been most excited about. Some of my best work has emerged because somebody looked at an early prototype and said, "That's not actually how we work." I've learned to love that sentence. Not because it means I've succeeded, but because it means I've stopped guessing. Iteration isn't really a development methodology. It's humility. It's the recognition that understanding emerges through conversation rather than certainty.

Technology didn't get less important along the way. People just turned out to be the part I'd been under-weighting for thirty years. Neil puts it rather more bluntly than that, but this is a book your mother might read.