Work with me / A conversation, first
I build systems.
But I work with people.
I enjoy working with people who see a problem differently from me. I ask questions, challenge assumptions and want to understand what I might be missing.
Curiosity. Directness. Empathy.
A willingness to say “I don’t know.”
How we work
People are part
of the engineering.
A system has to make sense to the people who use it. I want to understand what works in their current process, what frustrates them, and what they are worried about losing.
That matters particularly with AI. Who gave the system authority? Can someone challenge a decision? Does the person affected understand what it is doing? Can we stop it?
I involve people in those questions while we are building. Adoption, trust and the ability to operate a system belong in the design from the beginning.
Where I can contribute
Bring me the messy boundary.
01Infrastructure reliability & observability
Deployments people can trust, recovery they can follow, and monitoring that explains what changed.
Read the Hive story ↗02Identity & access
Lifecycle workflows, SSO, SCIM and permissions that let people work within useful security controls. Clear ownership instead of a process that relies on somebody remembering twelve steps.
Read about my professional work ↗03Practical automation
Repeatable workflows with clear ownership, failure handling and a manual escape route. Removing effort while keeping the process understandable.
04Accountable AI
Model and provider choices, data boundaries, authority, evidence and human responsibility. Designing the conditions under which an action may happen.
Read the APEX and Guard story ↗05Product-to-operations integration
Software meeting customers, payments, administrators and messy operational reality.
Read the AnySeller story ↗From conversation to something useful
Understand the reality.
Who experiences the problem? What has been tried? What does each team see that the others might miss?
Make the dependencies clear.
Data, authority, failure modes and the decisions that need a person involved.
Test the important assumptions.
Start small. Learn with the people affected. Leave something another person can operate and recover.
Start with the problem
You don’t need
an architecture diagram.
Whether you are considering me for a role or exploring a collaboration, tell me what is happening, who it affects, what you want to change and what constraints exist.
“Tell me what you think I might not understand yet.”
Explore my projects and the professional links on my GitHub profile.
Find me on GitHub