How I Work
I'm not an advisor who sends a PDF. I join your team, write code, review PRs, and make architectural decisions with skin in the game. The engagement is temporary by design. Here's what it looks like.
The Engagement Model
Diagnostic (Week 1)
Before I commit to anything, I need to understand what's actually happening. The first week is spent reading code, talking to engineers, mapping the delivery pipeline, and identifying the real bottlenecks. These are frequently not what you originally described.
At the end of the week, you get an honest assessment: what I found, what I recommend, and whether I'm the right person to help. Sometimes the answer is no. I'll tell you that too.
Embedded Delivery (4 weeks – 2 years)
I join your team as a working engineer. Daily standups. PR reviews. Architecture sessions. Pair programming when it's useful. I make decisions, write code, and establish the patterns your team will build on after I'm gone.
What I don't do: sit in steering committees, produce slide decks, or attend meetings that should have been messages. My time is spent on the work that actually moves the needle.
Engagement length depends on the scope. Some run a few months, others extend to a year or more when the problem is genuinely complex. My longest engagements have run up to three years. We'll know the likely timeline by the end of the diagnostic.
Handoff & Exit (Final 2 weeks)
The exit is planned from the start. During the final phase, I shift from doing to teaching. Documenting decisions, pairing with the person who'll own the architecture after me, and making sure the patterns I've established are understood, not just implemented.
The test is simple: can the team continue at the same velocity without me? If yes, the engagement was successful. If no, I haven't done my job.
What You Get
- An honest diagnostic that tells you what's actually wrong, not what you want to hear
- Architectural decisions made by someone who's seen what works and what fails at scale
- Patterns and processes that outlast the engagement
- A team that's stronger, more confident, and fully equipped to continue without me
- Knowledge transfer that sticks. I train the people I work with so they own the architecture, not just inherit it
- A clean exit with no dependency on me
What I Don't Do
- Slide decks and steering committees
- Staff augmentation or body-shopping
- Open-ended retainers with no exit plan
- Technology recommendations without implementation
- Engagements where I can't write code
Typical Working Cadence
| Cadence | What it looks like |
|---|---|
| Daily | Standup with the team. Code review. Hands-on work. |
| Weekly | Architecture session, decisions documented as ADRs. Progress check with the engagement sponsor. |
| Bi-weekly | Broader update with leadership if needed. Honest assessment of where we are vs. where we need to be. |
| End of engagement | Written handoff document. Knowledge transfer sessions. Clear ownership map. |
Collaboration Principles
I have opinions. I hold them loosely.
I'll tell you what I think the right call is and why. If you have a better argument, I'll change my mind. What I won't do is hedge. "It depends" is only useful if I explain what it depends on.
I optimise for the team that stays, not the one I'm on.
Every decision is made with the question: "Will this make sense when I'm gone?" If a pattern requires my presence to work, it's the wrong pattern.
I'm direct about problems.
If something is broken, I'll say it's broken. If a decision was wrong, I'll say that too, including my own. Polite disagreement is fine. Silence when something's going wrong is not.
Common Questions
What does the first week look like?
The first week is a diagnostic. I read the code, talk to engineers, map the delivery pipeline, and identify the real bottlenecks. At the end of the week, you get an honest assessment: what I found, what I recommend, and whether I'm the right person to help.
How do you integrate with an existing team?
I join as a working member. Daily standups, PR reviews, architecture sessions, pair programming when it's useful. I make decisions with skin in the game, not from the sidelines. Most teams tell me after the first week that it feels like I've been there for months.
What happens after you leave?
The exit is planned from the start. I document decisions, pair with the person who'll own the architecture after me, and ensure the patterns I've established are understood, not just implemented. The test is simple: can the team continue at the same velocity without me?
What if we need you longer?
Extensions happen when the scope genuinely requires it. But I'll be honest about whether extending is solving a real problem or creating a dependency. The goal is always a self-sustaining team, not a permanent consultant.
Interested?
The first step is a conversation. Usually 30 minutes, no prep required on your side. Tell me what's going on and I'll tell you whether I can help.