What you’d actually be getting
I am CTO and founding engineer at Lium AI, and that is where my day goes. Alongside it I advise a small number of teams through Monster Orange. This page exists so anyone considering that conversation knows exactly what they’d be getting — and what they wouldn’t.
What drives me
I bring heart to technology. That isn’t a slogan I picked because it sounded warm — it’s the shortest true summary of a career spent noticing that the hard part is never the machine.
The work I want is the work where a real person’s day gets measurably better because a system finally understood what they meant. Aerospace engineers at Boeing. Pickers on the AmazonFresh floor. Someone in a therapy chat at two in the morning. That’s the through-line, and it hasn’t moved in thirty years.
How an engagement actually runs
We start with the problem, not the proposal
A conversation, free, no deck. If I don’t think I’m the right person you’ll hear that in the first call rather than the fourth. I would rather lose the work than take work I can’t move.
I go find the truth myself
I read the code, sit in the standups, and talk to the people doing the job. I don’t accept a summary of a system as a description of it. This is usually where the actual problem turns out to be a different problem.
I write something that runs
Not a recommendation deck — a working thing, or a working proof of the thing. I have never been able to advise credibly on a system I haven’t had my hands inside, and the agentic SDLC means there is no longer any excuse for stopping at advice.
I hand it over on purpose
The goal is a team that no longer needs me, holding a system they understand and can change without fear. Dependency is a failure mode, not a business model.
Where I’m most useful
- You have an idea that you need brought to market, and fast.
- You’re putting AI into the product or the process for real, and you want someone who has actually shipped it rather than summarized it.
- You’re scaling past the point where the founding team can hold it in their heads, and the architecture needs to grow up before it breaks.
- You’re building a distributed team and want it to be genuinely good, not merely tolerated.
- You have a strong technical leader who needs a thinking partner rather than a supervisor.
- Something is quietly wrong and nobody can name it yet.
What I avoid
I have taken most of these on at some point in my career, and I regret every one. Naming them saves us both a quarter.
Rooms without psychological safety
If people cannot say the thing that is actually wrong, nothing I build will survive contact with the organization. I’ve spent a career on celebration of errors and I won’t spend a month pretending it’s optional.
Theatre instead of delivery
Status reporting that exists to be reported. Roadmaps whose purpose is the roadmap. Lean has one question — would the customer pay for this step? — and I intend to keep asking it out loud.
AI as a press release
If the goal is to be able to say the word rather than to change what the product does, I’m the wrong person. I’ll cost you more than an agency and disappoint you faster.
Hero culture and the always-on team
Sustained crunch is a leadership failure being paid for by other people’s families. I’ve made that mistake myself. I won’t help anyone institutionalize it.
Remote in name only
Distributed teams that are really an office plus some exiles. If the important conversations happen in a room some of the team can’t enter, the remote people are being set up to fail — and I’ll say so, repeatedly, until it changes or I leave.
Advice without accountability
Engagements where I’m asked to recommend but never to build, and therefore never to be wrong in public. If I can’t be measured by whether it worked, I don’t want the seat.
Start a conversation
If you read “what I avoid” and recognised your own company, that is worth talking about too — I have helped fix several of them. The first conversation costs nothing and I will tell you plainly if I am the wrong person.