User manual

How I operate.

A short note on how I think, communicate, and work with other people.

I prefer writing over meetings, clear scope over ambiguity, and direct communication over endless politeness. If something is not working, I would rather say it early than waste time pretending otherwise.

I like fast iterations, documented decisions, and explanations that survive being repeated plainly. I do not like performative process, status theatre, or dragging out obvious calls.

Principles

Boring choices are usually right. I trust proven tools over fashionable ones.
Design for failure. Failure modes, observability, and maintainability matter more than clever demos.
Technical decisions are business decisions. Architecture is inseparable from economics, speed, and control.
Start from the real problem. Solve the underlying issue, not only the request sitting on top of it.
Own what matters. Control more of the stack when it creates meaningful independence.

Working together

Communication is async-first. Writing creates a better record and usually better decisions.
Meetings are short and rare. A call should have a purpose that writing cannot serve.
Expect directness. I will say what I think, including when the simplest answer is to stop.
I optimize for useful iterations. Ship, observe, and adjust rather than defend a perfect plan.
No lock-in. Systems should remain understandable and operable without their original builder.

Limits

I have a family and protect my time with them. I do not want work that depends on constant availability, daily status theatre, or avoidable urgency. These constraints make the work better.

Read my writing, see what I’m doing now, or visit Prodmake for product engineering.