The ticket is clear. The problem is not.
“Can you build a dashboard for me?”
I can build a dashboard. But what decision will it help someone make? Who will act differently because it exists?
I’ve learned to ask those questions before discussing implementation. Sometimes the answer leads to a smaller feature. Sometimes it reveals a problem nobody had mentioned.
A spreadsheet copied between three departments might look like a software problem. Then you discover that each department defines the same number differently. Automating that gives you a faster disagreement.
I like to see how people work today: the workarounds, the repeated steps, the things they stopped reporting because “it’s always been like that.”
That’s usually where the conversation gets interesting.
“We need it” deserves a follow-up question. Maybe more than just one!
A requirement can survive several meetings without anyone asking why it exists.
I question things that sound settled: the integration, the approval step, the feature that “every competitor has.” I also question my own favourite solutions, although I’m considerably less enthusiastic about that part.
Every assumption we implement becomes something someone must use, maintain and eventually change. So I want to know: Who needs this? What evidence do we have? What happens if we leave it out?
Sometimes there’s an excellent reason. Sometimes the person who originally requested it left two years ago, and we’re still designing around their preferences.
The demo worked. Now give it to someone else.
I like prototypes because they interrupt convincing conversations with something we can actually try.
Then I watch someone use it—ideally without explaining where to click. That part can be uncomfortable. Especially when they ignore the feature I spent the most time polishing.
Their hesitation often tells me more than their compliments. What did they expect? Where did they lose confidence? Did they understand the result?
I try to decide what we need to learn before building the prototype. A sketch may answer a navigation question. A technical experiment may reveal an integration problem. Neither necessarily needs a login page, a settings panel and our final choice of font.
Although choosing the font is an excellent way to avoid the difficult questions.
Someone has to live with that diagram.
I’ve worked close enough to cables, code, products and teams to distrust architecture discussed entirely in boxes and arrows.
Who needs this capability? What happens when it fails? Who will maintain it? Those questions connect technical decisions to everyday consequences.
A service that looks independent on a diagram may require three teams to coordinate every release. A flexible data model may make a simple product change surprisingly difficult. These details eventually turn up in someone’s calendar.
I enjoy an elegant design. I also want to understand what it costs to operate and change.
Having started with physical infrastructure, I still occasionally look at a cloud architecture and wonder how many things we’ve found a more sophisticated way to unplug.
Generating more code wasn’t my problem.
I can now ask agents to explore options, implement changes and check work across the development lifecycle.
The temptation is to keep them busy. There’s something satisfying about watching several tasks progress while I’m still drinking my coffee.
Then the results arrive, and someone has to understand how they fit together.
I use agents where I can define a useful task, provide enough context and inspect the outcome. Sometimes that means implementation. Sometimes it means investigating a failure, questioning a design or finding gaps in a test strategy.
Thirty years ago, I was connecting machines. Later, I coordinated teams. Today, I also coordinate agents... and still spend a surprising amount of time checking whether everyone understood the same request.
My machine is a very small market.
I still enjoy the moment something finally works. After enough debugging, even an unremarkable screen can look beautiful.
To get there I already asked myself: Can someone else use it? Can I deploy it again? Will I know when it fails? Can I recover?
Delivery exposes assumptions that development can hide. Real users bring different habits, unexpected data and devices I apparently should have tested.
I want the first release to be useful and manageable, with enough visibility to understand what happens next. That includes errors, support questions and the features people quietly ignore.
I’m particularly interested when someone exports the data and finishes the job in a spreadsheet. There’s usually a conversation worth having there, once I’ve recovered from my initial disappointment.
And that's why before implementing anything I think as much as possible where can that lead.