Ten hours a week is the median for fractional work. That makes the famous first 90 days about 129 hours, and the first 30 days about 43. A full time executive walking into the same job gets roughly 480.
So when a founder asks me in week one what I think is wrong with his engineering organisation, I tell him I do not have a view yet.
That answer has cost me work. I keep giving it, because 43 hours is the entire budget and I will not spend it confirming what the room already believes.
The thesis
The first 30 days of a fractional engagement is not diagnosis. It is instrumentation.
You cannot find a delivery constraint by asking the people inside it. They will report the constraint they personally feel, which is a real thing and a different thing. My job in month one is to leave four instruments running and a dated record of what everyone said before the instruments existed. The diagnosis is what the gap between those two says on day 31.
Why the interviews will lie to you, politely
In July 2025 METR ran the study that should have ended this argument. Sixteen experienced open source developers, 246 real issues on repositories they already maintained, averaging over 22,000 stars and a million lines of code. Screen recorded. Paid $150 an hour. Before starting, the developers forecast that AI tooling would make them 24% faster.
They were 19% slower.
The part that matters for month one is what happened afterwards. Having just been measured, on their own codebases, doing their own work, the same developers still estimated that AI had sped them up by about 20%. That is a 39 point gap between what a room of expert practitioners believed about their own delivery time and what a stopwatch recorded.
Nobody in that study was lying. Self report measures effort. It does not measure duration. Those two came apart in 2025 and they have not come back together.
Now put that against what the industry actually reports. DORA surveyed nearly 5,000 technology professionals for the 2025 State of DevOps report, with more than 100 hours of qualitative work behind it. 90% use AI at work. More than 80% believe it has made them more productive. 30% have little or no confidence in the code it produces. DORA found AI positively related to delivery throughput and still negatively related to delivery stability.
Both of those are true at once, which is precisely why an interview cannot resolve them.
What the telemetry says instead
The 2026 AI Engineering Report from Faros is the closest thing we have to an answer, because it is not a survey. It is two years of telemetry across 22,000 developers and more than 4,000 teams.
At the top of the pipe, the story people tell is correct. Merge rate per developer is up 16.2%. Task throughput per developer is up 33.7%. Epics per developer are up 66%.
At the bottom of the pipe it inverts. Median time in review is up 441.5%. Time to first review is up 156.6%. Merges shipped with no review at all are up 31.3%. Code churn is up 861%. Monthly incidents are up 57.9%, and incidents per pull request are up 242.7%. Bugs per developer are up 54%, against 9% the year before.
Read those two paragraphs again as one sentence. Everything a person can feel got faster. Everything only a system can see got worse. An interview picks up the first list and cannot see the second, and that is the entire reason I refuse to give an opinion in week one.
The four instruments
None of these need a vendor, a budget line, or a steering committee. All four come out of git, the deploy log and the incident channel, and I ask for read only access to all three on day one, before the kickoff deck.
One. Lead time from first commit to production. Not from ticket creation, which measures how a team fills in Jira. First commit to live measures the system. I want the distribution and the long tail, never the average, because the average is where a two week outlier goes to hide.
Two. Review latency and the unreviewed merge rate. This is the surface that broke in 2026 and almost nobody watches it. Two numbers: median hours in review, and the percentage of merges that reached production with no human review at all.
Three. Rework. Churn, restarts, and items stalled more than seven days. This separates shipped from finished. A team can be shipping 33% more and finishing less, and the roadmap will show only the first half.
Four. Incidents per merged change. Not incidents per month. A team reporting incidents up a bit is reporting the numerator while the denominator moved underneath it. In the Faros data the monthly count moved 57.9% and the ratio moved 242.7%. Those are the same organisation described two ways, and only one of them is a measurement.
Three things the instruments say that the room never does
”We are much faster now.” Usually true, and usually true only at merge. The change is real and it stops at the review queue. I have never once heard a team volunteer their unreviewed merge rate, because nobody computes it.
”Quality is holding.” Held against what. Flat incidents against flat volume is stability. Flat incidents against a 16.2% higher merge rate is an improvement worth celebrating. Rising incidents against rising volume is the normal case and it is not a crisis, but it is also not what holding means.
”The bottleneck is the platform team.” Sometimes. It is also the single most reported answer I get, from every seat, in every engagement, and it is exactly the shape of answer METR showed practitioners get wrong about themselves.
I learned this the expensive way on my own product rather than a client’s. I built the extraction engine for D30 first and the articulation gates second, which is the wrong order. The gates went in and immediately caught a share count that was out by 31 units against the store, on a workbook I had already read and believed. I would have signed that. Now the instrument goes in before the opinion, in my own tooling and in other people’s companies.
Where this breaks
Three ways, and I have hit all of them.
The first: not every engagement is diagnostic. If the brief is ship the migration by 30 November, spending 30 days instrumenting is a sophisticated way to miss the date. This rule applies when the brief is we are slow or we do not know why this hurts. When the brief names a deliverable, go and deliver it.
The second: instruments need events. In an organisation deploying quarterly, by hand, with incidents tracked in somebody’s inbox, 30 days of measurement produces almost no data points. There you are back to interviews and a stopwatch, and the honest move is to say so out loud rather than dress up a thin sample as evidence.
The third, and the one that actually bites: a number that lands on day 31 with no relationship behind it reads as an audit. Audited teams optimise the number, and then the instrument is worthless. So the 30 days is also 30 days of earning the right to publish what the instruments found. Skip that and the measurement survives while the mandate does not.
One more limit worth naming. The METR result is 16 developers on mature open source codebases with early 2025 tooling. The coefficient does not transfer to your company. The direction does, and the direction is the only part I use.
What I would do on Monday
Ask for read only access to git, the deploy or CI log, and the incident channel. If that takes more than five working days to arrive, you have your first finding, and it is about the organisation rather than the tooling.
Pull lead time from first commit to production for the last 90 days. Plot the distribution. Look at the slowest decile only.
Compute two numbers nobody has: median hours in review, and the share of merges that shipped unreviewed.
Compute incidents per merged change for the last two quarters. Compare it to incidents per month and see whether they tell the same story.
On day one, write down what the room says the constraint is. Date it. Do not share it. On day 31 put it beside the instruments. That comparison is the deliverable, and it is worth more than either half on its own.
Close
Forty three hours is not enough to fix an engineering organisation. It is exactly enough to stop guessing about one.
The question I refuse in week one is the same question I can answer on day 31 with a number instead of a view. Clients think they are paying for my opinion. What they are actually paying for is the 30 days in which I do not have one.
Most of what I write about here started as a client problem. If you have one, bring it to me.