- Decisions are made in three forums, and none of them writes the decision down.
- A migration is being run by committee, and the committee meets every second week.
- The team has strong engineers but nobody holding the technical thread across teams.
- Delivery dates are set somewhere else, without anyone owning the architecture behind them.
Service
Fractional architecture and delivery leadership
Senior technical direction when a migration or restructure needs someone holding the thread, without adding a permanent role.
When teams call
The situation this fits
This is the engagement for problems that are organisational before they are technical.
How the work runs
Three phases, overlapping
The third phase is the one that takes the time, and the one most engagements skip.
-
01
Read the decision landscape
Who decides what, where decisions actually get made, and which ones keep coming back. Two weeks of interviews and repository reading is usually enough to see the pattern.
-
02
Install the habit
Decision records with a named owner, a written decision log, and a review cadence that fits how the teams already work rather than adding another ceremony.
-
03
Hold the thread
I stay in the reviews, keep the map current, and escalate early when two workstreams are about to disagree. This is the part that does not fit in a document.
Deliverables
What you are left with
Artefacts a permanent architect could pick up on their first day.
- Architecture decision records the team keeps writing after the engagement ends.
- A decision log with one named owner per decision, and the date it was last revisited.
- A current map of the architecture with ownership, not a diagram from eighteen months ago.
- A delivery-critical path with the risks named, so the schedule can be argued with.
- A written recommendation on what to stop doing, which is usually the most useful page.
- Enablement sessions for the engineers who will inherit the decisions.
Engagement shapes
Three ways to bring it in
The difference between these is how much of the delivery you want me inside.
Fractional architecture lead
Two to three days a week for three to six months. I own the technical direction across workstreams and sit in the forums where decisions get made.
Migration oversight
Part-time for the length of a migration. Architecture reviews, decision records and escalation, without taking delivery responsibility away from your leads.
Short intensive
Two to four weeks. An architecture and decision review with a written set of recommendations, for teams that need clarity before committing budget.
Evidence
What it looks like in practice
One anonymized reference from recent work.
Case study
Enterprise retail: a 600,000-user Microsoft-to-Google migration
Questions
Before a first conversation
The three questions I get asked first.
Is this a substitute for hiring an architect?
Sometimes, for a phase. More often it buys time to hire well: the decision records and the architecture map become the brief that a permanent architect can pick up.
Do you take delivery responsibility?
For the parts I build, yes. For the programme as a whole, no. I would rather keep the technical thread and leave accountability with your leads than hold a schedule I cannot control.
How does this differ from the other service pages?
The other engagements are about a system. This one is about the decisions around it, and it is the only one that works when the problem is alignment rather than code.
Start the conversation
Describe the programme and who decides what
A short note with the context, the constraint and the timing is enough for me to say whether this is the right engagement.