Engineering effectiveness and iteration health
Your team is not slow. Your loop is.
A four-hour build, a 40% DDC hit rate and a two-day PR queue are not a people problem. They are a measurable, fixable tax on every hour your engineers work — and nobody inside the studio has time to measure them.
Fixed-scope review
Seven consulting days, usually spread across two to three calendar weeks.
Technical directors and studio CTOs.
Usually somebody who already suspects the answer, needs it measured rather than argued, and needs it to come from outside so it can be acted on without becoming a political question.
The arithmetic
What the loop is actually costing.
A 60-engineer team losing 45 minutes a day to builds, syncs, editor startup and shader compilation is losing something close to seven full-time engineers. That number is never in the plan, and it compounds every sprint until somebody measures it.
Typical finding
Cook times
Full cook, iterative cook and the gap between them. Where the cook is bound — CPU, IO, DDC misses, or shader compilation nobody has budgeted.
Typical finding
DDC hit rates
Shared DDC hit rate by role and location. A remote team on a 40% hit rate is paying for the same shaders repeatedly, on every machine.
Typical finding
Sync-to-playable
The wall-clock time from “get latest” to standing in the level. Measured on real machines, for each discipline, not just for programmers.
Typical finding
PR and CI turnaround
Queue time, run time, flake rate, and how often a red build stays red. The gap between a 12-minute and a 90-minute CI cycle changes how people work, not just how long they wait.
Scope
What the review covers
Build, cook, editor startup, shader compilation, DDC, sync-to-playable and hot reload — measured on the machines your team actually uses, per discipline.
Pipeline structure, queue and run times, flake rate, red-build recovery, PR review latency, branch and stream strategy, merge pain.
Whether a performance or memory regression is caught by automation or by a person noticing. Automated capture, budgets, alerting and who owns the response.
What the team builds by hand that should be automated, what is automated but untrusted, and which internal tools are one departure away from being unmaintained.
Who owns the build, the pipeline and the platform. Interrupt load, on-call rotation, bus factor, and how much of the week is spent unblocking other people.
Where the working day goes, from the team's own accounts and from the record: feature work, firefighting, support, meetings, review, and rework.
Devkit availability and contention, console iteration cost, and how often work is validated on the platform it ships on rather than on a workstation.
How your figures sit against teams of comparable size and engine version. Not a maturity model — specific numbers, and which of them are genuinely worth moving.
Method
Measured, not surveyed.
Nobody is asked to rate their satisfaction with the pipeline on a scale of one to five. The figures come from your build logs, your CI history, your DDC statistics and a stopwatch.
Build and cook logs, CI history, DDC statistics and PR data, pulled from your systems for a representative period.
Timed cold and warm sync-to-playable runs on real machines, in each discipline, including the ones nobody thinks to time.
Confidential conversations with engineers, artists, designers and leads about where the day actually goes. See the confidentiality position.
Findings with numbers against them, ranked by hours returned per engineering week, with effort and owner for each.
What a finding looks like when it lands
Hours returned, per engineering week.
Every finding carries a before figure, an expected after and the arithmetic between them. The shape looks like this.
−68%Prewarmed DDC on the shared share, and the editor no longer recompiling on every sync.
Illustrative shape, not a client result.
+52 ptsRemote staff were silently missing the shared cache entirely and paying for every shader twice.
Illustrative shape, not a client result.
−71%CI split so the slow platform job stopped gating review, and the flakiest three tests fixed.
Illustrative shape, not a client result.
Worked examples showing the format of a finding. The sample reports show the format used to turn operational evidence into a decision.
The political problem
Introducing this to your team.
A technical director cannot commission an effectiveness review without somebody reading it as a prelude to layoffs. That reaction is reasonable, it is common, and pretending otherwise makes it worse.
Individual interviews are confidential from management, and that is a term of the engagement rather than a courtesy. Nothing an individual says is attributed to them, in the report or in conversation. Where a finding can only be described in a way that identifies its source, it is either aggregated until it cannot be, or it is raised with that person first and included only with their agreement.
The review assesses the system people work inside: the build, the pipeline, the tooling, the ownership model and the interrupt load. It does not rate individuals, does not produce a ranking, and is not an input to a performance or headcount process. If that is what is wanted, this is the wrong supplier.
What tends to defuse it fastest is telling the team what is being measured before it starts, and sharing the findings with them at the same time as with the leadership. Both are offered as standard.
Deliverables
Numbers you can put in a plan
Baseline
Your current figures for every measure above, with the method written down so your team can re-run them in six months and see whether anything moved.
Ranked findings
Each with evidence, cause, estimated engineering hours returned per week, rough effort and a named owner. Sorted by return, not by severity theatre.
Readout
A 90-minute session for the people who will act on it, and a second one for the team if you want the findings shared openly.
How is this different from the performance review?
Do you need repository access?
Will you tell us to adopt a methodology?
Our build is fine. Is this still useful?
Can this run alongside a performance review?
Know roughly what the answer is, but not the number?
That is the usual starting position. Twenty minutes, free, no pitch.