How I Work
Hands-on. In the codebase. From day one. The first week is a diagnostic: I read the codebase, sit with engineers, designers, product owners, and business leads, and come back with a clear view of what will fight you next. Then I write code with your team, design the architecture, and make the decisions that determine the next 12 to 18 months. I work fluently across product, design, engineering, and operations because the hardest scaling problems live at the seams between them. The engagement is temporary by design and the exit is planned from day zero. Here is what it looks like.
The Engagement Model
Analyse (2 days)
The diagnostic. I read the codebase, talk to engineers, designers, product owners, and business leads, and map the workflows. I look at what is working today, what scaling will actually require, and where the architecture, the team, or the operating mode will fight you next.
You get three deliverables: a prioritised view of the friction points that will block scaling, a recommendation on what to fix first and why, and an honest call on whether further work makes sense. Sometimes the answer is "do not build this yet," and I will tell you that up front.
Validate (2 to 4 weeks)
A focused sprint on the highest-priority decision from the diagnostic. That can be a proof of concept against real data and real constraints, a technical spike on an architectural bet, or a small slice of production code that proves the new shape of the system works.
The goal is evidence for a go, change, or kill decision, not a demo. If the concept does not hold up, that finding just saved you months of building the wrong thing.
Build (Weeks to months)
Hands-on. In the codebase. With your team. I join as a working engineer. Daily standups. PR reviews. Architecture sessions. Pair programming when it is useful. I make decisions, write code, and establish the patterns your team will build on after I am gone.
The work spans whatever the engagement actually needs: module boundaries and build system, frontend architecture and design system integration, data pipelines and integration points, AI components where they belong, governance and documentation. I write the code, not just the recommendations. By mid-engagement your team is reviewing my PRs with the same confidence they bring to any other part of the codebase.
My time goes to the work that moves the needle: code, architecture decisions, and direct collaboration with engineers, designers, and product. Less time in meetings, more time shipping the system that has to scale.
Exit (Final 2 weeks)
I plan my exit from day zero. During the final phase I shift from doing to teaching. Documenting decisions, pairing with the person who will own the architecture after me, and making sure the patterns I have established are understood, not just implemented.
The test is simple: can the team continue at the same quality without me? If yes, the engagement was successful. If no, I have not done my job.
What You Get
- An honest diagnostic that identifies root causes, even when they are not what you expected to hear
- Architectural clarity: module boundaries, ownership model, design system integration, build system, and the working mode that will hold from 10 to 100 developers. Documented, not just noted.
- Decisions informed by 15+ years of seeing what works and what fails at scale across automotive, telecommunications, manufacturing, smart energy, and AI-driven products
- A single technical voice that designers, engineers, product, and operations can all align around
- Patterns and processes that outlast the engagement
- A team that is 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. I'm open to being wrong. If you have a better argument, I want to hear it. 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.
I treat new technology as infrastructure, not magic.
Any new technology, whether an AI model, a platform framework, or a build tool, gets treated like any other external dependency: it has failure modes, it needs monitoring, and it will surprise you at the worst moment. My job is to design systems where that surprise is survivable. That requires the same rigour you would apply to a database schema, not the same optimism you would apply to a shiny new tool.
Working Style
Pragmatic, not dogmatic
I care about what works in your context, not what's trendy. If a "boring" technology is the right fit, that's what I'll recommend.
Collaborative by default
I ask a lot of questions. I assume your team knows things I don't. The best solutions come from combining what I've seen before with what you know about your business.
Direct about problems
I'll tell you when something's off, but I'm not interested in being right. I'm interested in getting it right.
Common Questions
What does the first week look like?
The first week is a diagnostic. I read the code, talk to engineers, designers, product, and business leads, 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 am the right fit for the engagement.
How do you integrate with an existing team?
I join as a working member. Daily standups, PR reviews, architecture sessions, pair programming when it is useful. I make decisions with skin in the game, not from the sidelines. Most engagements integrate smoothly. The collaboration typically feels natural within the first week.
What happens after you leave?
The exit is planned from day zero. I document decisions, pair with the person who will own the architecture after me, and ensure the patterns I have 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 will 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.
Are you an AI specialist?
No. I am a Product Architect. AI is one of the technologies I work with, and it shows up in most engagements today, but it is rarely the headline. The work is scaling product, team, and system together. AI is one decision inside that, not the reason for the engagement.
Typical Engagements
Architecture Triage
Read the codebase, talk to product, design, engineering, and operations, map the friction points that will block scaling. Three deliverables you can act on, with or without me.
Validation Sprint
Focused work on the highest-priority architectural decision: a proof of concept, a technical spike, or a slice of production code that proves the new shape of the system holds up.
Embedded Delivery
Integrated with your team. Architecture decisions, code, design system integration, build system, data pipelines, AI components where they belong, governance. For the move from validated concept to production.
Handoff and Exit
Documentation, knowledge transfer, ownership mapping. Planned from the first conversation. The goal is a self-sustaining team.
Most engagements begin with the Architecture Triage. Scope and commercial terms agreed per engagement.
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.