Approach
How the work actually goes
Hiring an outside engineer means trusting someone with systems you depend on. The least I can do is be specific about how that tends to go.
The sequence
Four steps, in this order
- 01
Conversation
A free 30-minute call. You describe the situation, and I ask the questions that usually turn out to matter. If I don’t think I’m the right fit, I’d rather say so on that call than take the work — and I’ll point you somewhere better if I can.
- 02
Assessment
A short engagement, usually a fixed fee, to look at what you actually have. You end up with a written findings document and a prioritized list of recommendations. It’s yours to keep and act on, with or without me.
- 03
Execution
I’d rather settle scope, sequence and price before work starts than discover them along the way. Work happens in visible increments, so you can see where things are and change direction without losing what you’ve already paid for.
- 04
Handoff
Documentation, runbooks, and as many screen-share calls as your team needs — over Teams, Slack or Zoom, whichever you already live in. I lean harder on the written material than the meetings, because notes survive and a session on a Tuesday afternoon mostly doesn’t. The measure of a good engagement is that you don’t need me afterward — and call me anyway, because you want to.
Operating principles
How I prefer to work
Plain language
If I can’t explain why something matters in terms of your business, that usually means I don’t understand it well enough yet — not that you need to learn more jargon. You should be able to evaluate every recommendation you get from me.
The boring solution first
Interesting architecture is a cost, not a feature. My instinct is to reach for the least complicated thing that solves the problem, and to say so plainly when the more exciting option looks like the wrong one.
Write it down
Undocumented systems are the most expensive kind. I try to treat documentation as part of the work rather than something tacked on at the end, because what survives after I leave is most of the value.
Avoid lock-in
I’d rather not build things only I can maintain. Wherever I can, credentials, domains and accounts stay in your name and your repositories from the start — you should never need my permission to move on.
Scope honestly
If the work turns out smaller than expected, it should cost less, and I’ll tell you so. If it looks like you’re about to spend money you don’t need to spend, I’d rather lose the engagement than watch that happen quietly.
Leave the team stronger
The best outcome is usually that your people can handle it themselves next time. I’d rather work alongside your team than around them, and rather teach the fix than sell the same fix twice.
Sound like a fit?
The first call is 30 minutes and costs nothing. Worst case, you come away with a second opinion from someone who has no stake in which way you go.