About
Organised around the problem, not the org chart.
Most agencies are structured as departments that hand work between them. That structure is why a search problem gets solved by someone who is not allowed to change the architecture.
The studio in numbers
- 6
- Disciplines under one roof
- 18
- People, no subcontracted delivery
- 3
- Costed options per decision
- 1
- Business day to a reply
Sample company data.
One team that can change any layer of the thing it is looking at.
We hold six disciplines because the problems do not respect the boundaries between them. A conversion rate is decided partly by copy, partly by page weight, partly by a database query, and partly by a decision someone made about a third-party platform two years ago. A team that can only reach one of those will find the problem there.
That is the whole organising idea and it has a cost: we are not the cheapest way to buy any single one of these disciplines, and we will say so if that is what you actually need. We are the right answer when the problem crosses lines.
50 capabilities are listed by discipline on the services index. Most engagements use six or seven of them.
Positions
Six things we will argue for.
Stated here because it is fairer than surprising you with them in week three. If any of these read as a problem, that is useful information for both of us.
- 01
Constraints before ideas
Any idea is good in the absence of a budget, a deadline and an existing system. The constraints are what make one of them correct.
- 02
Write the decision down
Most technical debt is not bad code. It is a good decision whose reasons were never recorded, inherited by someone who cannot tell it from a mistake.
- 03
Say the unwelcome thing early
A concern raised in week two is a conversation. The same concern raised in month six is an invoice.
- 04
Prefer the boring mechanism
Novelty is a cost paid by whoever maintains it. We spend it where it buys something and nowhere else.
- 05
Measure what you claimed
If a number was worth putting in a proposal, it is worth reporting against - including when it did not move.
- 06
Leave people able to continue
The best outcome is a team that no longer needs us for the thing we were brought in for.
How work runs
Five stages, and the first is not building.
- 01Diagnose
Find out what is actually wrong
The brief describes the symptom. We spend the first weeks on the cause, because the two are different often enough that starting on the brief is a real risk.
Systems auditConstraint mapThe problem, restated - 02Decide
Put the real options side by side
Three costed options, each with its failure mode stated, including the one where nothing changes. Whatever is chosen, the reason gets written down.
Costed optionsDecision recordSequenced roadmap - 03Build
Ship the risky part first
The uncertain work comes forward, not back. A plan that defers its hardest question until month five is a plan to find out in month five.
Working incrementsPerformance budgetTest coverage - 04Prove
Measure it against the original claim
The numbers agreed at the start are the numbers reported at the end, whether or not they flatter us. Anything else is marketing.
Instrumented metricsBefore and afterKnown gaps - 05Hand over
Leave you able to run it
Runbooks, documented decisions, and a team that has operated the system before we stop being available. Dependency is not a business model we want.
RunbooksArchitecture notesOperating handover
Disciplines
Where to go next.
- 01Web DevelopmentInterfaces engineered as systems, not pages.
- 02Full Stack DevelopmentFrom the interface down to the infrastructure it runs on.
- 03SEOSearch visibility built into the architecture, not bolted on.
- 04Digital MarketingAttention measured all the way to a qualified action.
- 05Technology ConsultingDecisions made before complexity compounds.
- 06CybersecurityThe system tested the way an attacker would read it.