In 1967, Gene Amdahl pointed out something about parallel computing that CS students still learn in first year: if 95% of a program can be parallelised and 5% can't, then no matter how many processors you throw at it, that 5% sets a hard ceiling on your speedup. A thousand cores gets you at most 20x. The bottleneck dominates.
The formula that clarifies the hiring question
Every engineer's day splits between core work -- what they were hired for -- and operational overhead -- everything else. Waiting for builds. Debugging deployment configs. Filing tickets. Provisioning infrastructure. Sitting in a queue.
The formula:
A data scientist who is genuinely 10x -- better models, better feature engineering, better intuition -- but who spends 90% of their time on deployment, debugging pipelines, waiting for builds, and filing tickets? They're at 10% capacity. Some data scientists at Bolt claimed around 90% of their time was overhead.
At Bolt, this was made worse by a "TypeScript/JavaScript only" backend policy. Data scientists would build decision tree models in Python, then manually translate them to JavaScript for deployment. The SageMaker-based Python serving prototype -- models served outside the backend, proxied via a gateway service -- already existed when I arrived.
Run the numbers on your team
| Talent | Time on core work | Time wasted | Effective output |
|---|---|---|---|
| 10x | 10% | 90% | 1.0x |
| 5x | 30% | 70% | 1.5x |
| 3x | 90% | 10% | 2.7x |
| 10x | 90% | 10% | 9.0x |
What "wasted time" actually looks like
When I started at Bolt in 2019, data scientists spent most of their time on things that had nothing to do with data science. I wrote about the details elsewhere -- 40-minute Docker builds, deployment tickets that turned 5-minute tasks into 2-week sagas. The pattern was the same everywhere: manual deployment choreography from laptops, environment mismatches, over- or under-provisioned infrastructure per city. Retraining happened quarterly. A week of babysitting. Models stale the day they went live.
What one config change gives back
Concrete example: at Bolt, we built a platform where a data scientist defined their entire pipeline -- including per-city infrastructure overrides -- in a declarative config. London gets an ml.m5.4xlarge, Tallinn gets an ml.m5.large. Without this, data scientists make manual provisioning decisions per city, per retraining cycle. Either wasting money on oversized instances, or cramming London's dataset into a machine that's too small. With the config, they declare what they need. Adding a new city is one line. Their time goes back to building better models.
Why hiring more people often doesn't help
At a previous company, I sat in planning meetings where the answer to low engineering output was "hire two more senior engineers." The team already had good people. Those good people were spending their days fighting deployment scripts and debugging environment mismatches.
Two more senior people in a broken process gives you two more people stuck in the same mud. Salary bill up 40%, output up maybe 15%.
Compare: spend the same budget on one platform engineer who builds self-service tooling for six months. After that, every data scientist gets their time back. 10x people produce at 8-9x instead of 1x. 3x people produce at 2.7x instead of 0.9x. And it doesn't go away when the engineer moves to another project.
The productivity shift was stark.
Teams went from "a team of DS per model" to "multiple models per DS."
An individual data scientist could indulge a curiosity -- a hunch about a new feature, an alternative approach -- and take it all the way to a shadow-traffic endpoint without DE involvement. Before the platform, the widest pipeline trained models for about six cities. More was impractical due to manual processes and failure rates. After: hundreds of cities per pipeline.
During one three-month stretch where I was deep in infrastructure -- not coordinating with data science at all -- ML projects went from 100 to 200. These weren't migrations generating new project entries; migrations were git branches, merged or retired. These were genuinely new experiments -- new alphas, improved strategies on existing ones. Many never hit production, and that was the point. Fail fast, fail often. When the cost of spinning up a new experiment is nearly zero, you test ideas at high frequency.
Diminishing returns (and why you're nowhere near them)
Amdahl's law also tells you about diminishing returns. Going from 90% waste to 50% waste is massive. Going from 10% waste to 5% is marginal.
Most teams are deep in the high-waste zone. If your data scientists spend 70-90% of their time on operational overhead, moving to 30% waste triples their effective output. You don't need perfection. You need to move from terrible to reasonable.
The hard part is proving this to someone who doesn't understand the maths. That's where a north-star metric earns its keep -- it translates "reduce overhead from 70% to 30%" into a euro figure that needs no technical explanation.
A simple diagnostic
One approach: ask data scientists to track one week. What percentage of their time was actual model development versus deployment, debugging, waiting, and coordination? The actual number tends to be worse than anyone's estimate. If build times are over 10 minutes, the ticket queue has more than a day's wait, or deploying a model requires more than "push a PR and merge" -- most of the team's output is probably being left on the table.