Profile
I don't fit neatly into a single technical role, and I never really have. Not because I lack depth, but because I tend to look at problems from above rather than from inside one narrow discipline.
In simple terms, I'm like a Dr. House for engineering and technology. I focus on diagnostics first. Questioning assumptions. Understanding what's actually going on before jumping to solutions.
What that usually means in practice is that I spend more time thinking than doing, since once the problem is understood, execution rarely needs my particular skill set. I'm not wired for grinding through the same task over and over. By the time something is clear enough to execute, I'm already thinking about what comes next. I'm most at home before answers exist, when there's uncertainty, half-formed ideas, and the sense that something important hasn't been said out loud yet.
How I think about technical problems
I don't see technical domains as separate worlds. To me, they all follow the same underlying rules.
I don't particularly care whether I'm looking at a 30-ton excavator or a small Python script. One moves hydraulic fluid through steel lines, the other moves data through lines of code. The form is different, but the thinking required to understand them is the same.
What matters is understanding what the system is meant to do, how its parts depend on each other, where its limits are, and what happens when things stop behaving as expected.
If a system can be understood logically, it can be reasoned about. And if it can be reasoned about, it can usually be fixed, simplified, or improved.
Where I'm most effective
I tend to be most useful at the beginning of things, or at the point where something has gone off track.
- When a problem is still vague.
- When there are too many possible directions.
- When complexity has accumulated without anyone stopping to question it.
- When people are busy building, but no longer certain they're building the right thing.
These situations often feel difficult not because they're inherently complex, but because it isn't yet clear what actually matters. Sometimes that's a system that doesn't behave as expected. Sometimes it's a decision that feels important but strangely hard to make.
Once that clarity exists, progress usually follows.
What you get
Depending on the situation, my work typically results in one or more of the following:
- A clear explanation of what's actually happening in a system, problem, or setup
- A simplified mental model that replaces scattered or conflicting assumptions
- A concrete recommendation for how to proceed, including trade-offs and risks
- Identification of the underlying cause when something isn't working as expected
- A practical plan for fixing, stabilizing, or redesigning a system
Sometimes the outcome is a plan. Sometimes it’s a decision. Sometimes it’s simply understanding why something keeps failing. In all cases, the goal is the same: remove uncertainty and replace it with clarity about what to do next.
How I work
I start by understanding the system as it actually exists, not how it was intended to work or how it's described in documentation.
That usually means asking direct questions, questioning assumptions that have quietly solidified over time, and reducing the situation to something that can be reasoned about clearly.
You can expect clarity over comfort, and reasoning over activity. I'm not interested in looking busy or being clever for its own sake. If something is uncertain, I'll say so, and I'll explain what would need to be known to remove that uncertainty.
This isn't about replacing your team or taking over execution. Most of the time, the work ends once direction is clear. My role is to help ensure that effort is applied in the right place, on the right problem, before decisions become expensive to undo.
Example situations
This kind of work is often triggered by moments like these:
These situations are rarely blocked by a lack of effort or intelligence. More often, something essential hasn't been made explicit yet.
Contact
If you're facing a technical decision that feels high-stakes, messy, or oddly stuck, that's usually a good place to start a conversation.
