Find the real constraint.
A slow release is often a symptom. The real issue may be unclear ownership, a decision trapped in a meeting, or a safety check that happens too late. I want to fix the constraint, not automate the symptom.
How I build
The problem is rarely just the code.
I like the work where product decisions, architecture, and team design meet. These are the ideas I use to keep that work practical.
Working principles
What I come back to.
These are not slogans. They are checks I use when a program is getting complicated or a team is moving more slowly than it should.
Make the paved road worth taking.
A platform should make the safe path the fast path. If teams need a mandate to use it, the platform has not earned its place yet.
Put ownership near the problem.
Strong teams understand the user, the system, and the outcome. They should be able to make most decisions without waiting for a chain of approvals.
Make the system explain itself.
In healthcare, finance, and AI, a correct answer is not enough. People need to see the source, the boundary, and what happens next.
Use AI where judgment already lives.
The useful starting point is not a chatbot. It is the decision people are trying to make, the evidence they use, and the point where a human should stay in control.
Build the organization with the platform.
Architecture and team design shape each other. A reusable capability without an owner fades; a team without a clear system boundary spends its time negotiating handoffs.
An illustrative pattern
What a useful platform changes
Before
The team waits for the system
Every change crosses a queue. Knowledge lives with a few specialists, so delivery slows as the organization grows.
- 01Request
- 02Queue
- 03Specialist
- 04Handoff
- 05Release
Ownership is split across the handoffs.
This is a general operating pattern, not the internal architecture of any company where I have worked.
Ideas I am developing
Writing and conversation topics.
I would rather publish a few useful pieces than maintain a feed. These are the subjects I am working through and happy to discuss with engineering and product teams.
Agent-first product design
Start with data, decisions, and boundaries—then decide whether chat is even the right interface.
Platform teams without toll booths
How to give teams useful shared capabilities without turning a central team into everyone else’s approval queue.
What the org chart cannot fix
Why ownership, interfaces, and operating habits matter more than moving boxes on a slide.
Explainability as architecture
Designing evidence, uncertainty, and human review into systems where the outcome matters.
A useful room
I’m open to talks, working sessions, and honest conversations.
Especially with teams building platforms, introducing AI into real operations, or trying to grow without adding another layer of process.
Start a conversation →