Make Room for Growth: Teams Don't Grow By Hiring
When a team needs to absorb new work, the default move is to hire. This is the wrong move almost every time. Adding people to a team that hasn’t pruned its current workload just creates a larger version of what already exists. If the team is on the critical path and shipping, that’s growth. If not, you’ve just made the hollow harness bigger.
This isn’t a generic anti-hiring take. Engineering teams in stable problem domains genuinely grow by adding capacity to meet maintenance needs. The pattern stops working in research teams for a specific reason: the substrate underneath you is moving fast enough that the work you absorb today may not be the work that matters in eighteen months. Adding headcount against a moving substrate locks in your current shape. It doesn’t make you more adaptive. It makes it harder for you to change.
The room you actually need is not headcount. It’s the unscheduled time and the cleared surface to absorb what’s coming. You can’t get that by adding people. You get it by cutting work.
The five categories of work to cut
-
Cohort dashboards, retention reports, A/B readouts. This work is genuinely useful, and someone needs to do it. It does not need to be done by the team you hired to ship production ML. When does it end up there? Usually, because the team is the only one that can write the queries cleanly? It crowds out the work you actually built the team for. The slide is slow and feels productive while it’s happening. By the time someone asks why the team’s roadmap looks like a BI team’s roadmap, the answer is “because we let it get here”.
-
Retrainings nobody asked for. Eval suites for models that have no production path. Architecture explorations that read and ship like research papers. This is where teams that came up through the research lineage instinctively spend time, because the model is what they trained on. The three-tier frame says model work without a feature attached is tool-tier work that the org doesn’t actually need delivered. Cut it. The people doing it can do feature-attached work just fine, once it’s clear that’s the job.es here
-
Description text goA feature store operating across multiple planes when one would do. Replication mechanisms to Redshift and Snowflake because both got asked for once, and neither got asked to be turned off. A customer-facing feature that predicted the best mechanisms for a chemical reaction ? real ML, working well ? That didn’t earn its place in a platform whose focus is redaction for regulated AI workflows. We cut all of it at VeilData. Less surface area means more reliable systems and more focused teams. Sprawl is the most expensive form of “let’s keep it around just in case” the industry keeps reinventing.es here
-
Most teams have stopped asking whether a task actually needs an LLM. The LLM gets most of the way there on any text task with almost no effort, and the convenience is real. So is the cost ? sophistication compounds into more data, more spend, more failure modes, more on-call surface, more drift to chase. A regex, a small classifier, or a deterministic pipeline frequently outperforms an LLM on a narrow task at a fraction of the price and the surface area. The cut isn’t anti-LLM. It’s the contrarian question that has to be asked before reaching for the biggest tool in the room: is the simpler thing sufficient, and what is it costing us to keep the sophisticated thing around when it isn’t? (Worth its own post: the things LLMs are genuinely exceptional at search and summarization. These are not the things most agent systems are asking them to do. What looks like reasoning is mostly the harness around the LLM. More on that elsewhere.
-
PR-review meetings, weekly status syncs, and standups that exist because nobody trusts the project tracker. Each of these was the right answer when the tool layer couldn’t handle routing. The tool layer can now mostly. Auditing process for “would this exist if AI tooling were five years older” is the cheapest cut available and the one most teams skip because the meetings are familiar.
A diagnostic: tools per person
Count every tool and platform your team actually touches feature stores, warehouses, orchestrators, vendor APIs, observability stacks, deployment pipelines, and dashboards. Divide by the number of people on the team. The ratio is the surface area each person is implicitly carrying: tools they need to understand, debug under failure, and integrate with when something changes. Centralization doesn’t change the math. Somebody still has to know how each tool behaves when it doesn’t. If the number is high, your team is slow, whether anyone has said so out loud or not.
The hardest cut
The same logic applies to people, and most “make room for growth” writing avoids saying so. For an early team still working out which problem it’s solving, a team member who can’t adapt to a substrate shift is costing the team more than they’re contributing ? not because they did anything wrong, but because the team’s job is to absorb shifts, and they cannot. Replacing them is part of the work. Saying so out loud is the part that gets dodged.
The qualifier matters. At a certain level of system maturity, the calculus changes. Systems get harder to swap, the surfaces get load-bearing, and the role shifts from explorer to maintainer. A healthy team needs the maintainer; pretending otherwise is its own kind of mistake. But the AI-era maintainer is not the sit-still maintainer of ten years ago. The bar has moved. A maintainer now has to absorb new tooling, retire old patterns, and explain to the next explorer which parts of the system are actually load-bearing and which were once load-bearing but aren’t anymore. Maintainers who can’t meet that bar become a different kind of sprawl, on a longer timeline.
Why is this genuinely hard?
Cutting work and cutting people both feel like punishing the person who did the work. The dashboards belong to someone, the retraining was someone’s quarterly goal, the chemistry feature shipped because someone fought for it, and the team member who can’t keep pace was working hard until last week. The right counter to the resistance is not “the work was bad” or “the person was bad.” Is it that the work was good, the person was good, and the team can no longer afford to be doing or carrying it ? And the room that opens up is worth more than what’s being lost.
The upside is invisible for twelve to eighteen months. The CFO asking what the cut bought you doesn’t get a clean answer in quarter one or quarter two. The team that did the cutting often can’t draw the line either. The benefit is real. It just doesn’t show up as a metric.
What does this change about how you grow the team?
If cutting is the growth move, the operating cadence shifts. Headcount planning becomes a backstop, not the lead instrument. Quarterly reviews include a question most don’t: what work is this team doing that should be done somewhere else, or not at all.
To grow a well-run ML team in a fast-changing environment, focus on refusing unnecessary work rather than increasing headcount. Success is measured by how much surface the team can avoid, not by the number of people.
Core principle: Adaptive growth in ML and Engineering isn’t about adding capacity. It’s about pruning the work that doesn’t earn the team’s time, in an environment where what matters changes faster than your hiring plan. The cut is the growth. The hire is the best because nothing important is going to change.
