Problems I enjoy solving
Not a technology list. The stuff underneath it.
Every tool on the projects page started somewhere. Usually it’s one of these, recognised in the wild before it ever became a spec.
Users rarely ask for the thing they actually need.
-
The spreadsheet that became load-bearing
A tracker that started as one person’s personal list and became the system three teams now depend on, that nobody’s allowed to touch.
Why I like it — under the conditional formatting is usually a real, decent data model. It just needs a proper home.
-
Systems that won’t talk to each other
Two platforms that each do their own job well and still can’t agree on a customer record, so someone re-keys it by hand every week.
The interesting part is never the API. It’s working out which system should own the truth.
-
The report that answers the wrong question
Four hours a month to build, and it answers a question nobody asked, twice removed from the decision it was meant to inform.
Half the fix is technical. The other half is sitting with someone until they say what they meant.
-
The process that lives in one person’s head
It only works because one person remembers every exception, and everything stops the week they’re on leave.
That’s not a training problem. That’s an undocumented system wearing a person as its interface.
-
AI without a problem attached
Being asked to “add AI” to something before anyone’s agreed what it’s meant to fix.
The honest answer is usually a smaller, more boring automation. Less exciting in a meeting. Right anyway.
-
The bottleneck everyone’s routed around
A step so slow the whole team has built a workaround, and the workaround is now the process.
Why I like it — workarounds are free user research. Someone already told you exactly where it hurts.
Read on for the full career history or the skill list, more on who I am, or back to the short version and what I build.