Build vs Run
Stanislas Polu
Build vs Run and zero-sumness: a simple framework to reason about how to scale teams post artificial intelligence abundance. Will AI annihilate all head-counts? We posit in this article that it may not quite be the case especially for run functions that are inherently a zero-sum game in the market.
An interesting distinction to consider when approaching organization building is the mix of build vs run involved in the different parts of it. Typically, software engineers are 80% build if not more. They build systems that attract usage and scale with minimal additional human work required as an input (the 20% run part: monitoring, incident handling, bug fixing which all scale sub-linearly wrt usage). Conversely, account executives are 90% run. They fight for clients, jumping through meetings, mapping accounts one after another. The industry even standardized around offloading the build part of the job off of their plate to revops or GTM engineering teams. The closer jobs are to the revenue, the more run-heavy they generally are. Once again tech internalized this pretty well with typical compensation frameworks demonstrating a clear gradient of revenue related incentives from pre-sales to post-sales all the way to 0 direct cash incentive for ops, marketing, HR, or EPD (engineering, product and design).
I posit here that the build/run ratio is a fundamental constant of jobs that dominated many aspects of how we compensated and scaled them within companies in the past decades, and that can be used to reason about how we should scale the human vs machine part of it post artificial intelligence abundance.
While this post is mostly designed with SaaS enterprise sales companies in mind, the framework proposed can be easily ported to different breeds of companies such as services or consumer companies as an exercise left to the reader.
Build vs Run
Let's define more precisely what we mean by build vs run:
- Build: the job to be done is a system. Some systems are made of code (engineering), others are made of documents or spreadsheets (rev-ops, HR). Their nature doesn't matter. What matters is that the system then operates. Good examples are software, compensation frameworks, brand positioning, ad campaigns, operating principles. The main compensation component for the build part of a job is equity.
- Run: the job to be done is a repeatable measurable outcome. Some outcomes are external (closing deals, answering a user ticket) and others are internal (re-stocking the kitchen fridge, filing an expense). The main compensation component for the run part of a job is cash.
Anyone would love to have only builders within their companies. The access to artificial intelligence is rapidly shifting the boundaries between build and run but some externalities simply prevent a full transition. For all things internal, companies should strive to automate as many repeatable measurable outcomes as possible but, even internally, some things remain irreducibly human-centric. Coaching and performance review are great examples. We can create agents that provide solid hyper-personalized feedback perfectly mapped on company operating principles on a daily basis but, being social beasts, some aspects of running an organization have to remain inherently human. The picture externally is similar. Enterprise sales remains inherently a human first activity in our current market equilibrium.
Zero-sumness
Building an AI-first company is not about removing all human aspects of running a business, it is about being deliberate about where humans are core and where we can accelerate them or shift their build/run ratio. This requires organizations to reinvent how they scale teams. If I can make an AE 2x more efficient? Should I continue scaling the sales team the same way? What about engineers or other roles in the company? The answer to this question cannot be answered by considering companies as closed systems. It depends on how competitors will act and how it will impact the dynamics in the markets they fight for.
Selling is quite obviously a zero-sum game. Sales are fighting for the same resources in the market, any productivity gain achieved by a company will have direct negative impact on its competitors. If you can make AEs 2x more efficient this is a net positive you want to capture and if you reduce your AE team growth as a consequence you leave potential energy on the table that will be captured by competitors. Equivalently, if you're not augmenting your AEs with AI today, you're paying an efficiency tax that will slow you down in the market.
While the picture is clear for functions that are close to the revenue, is it the same for other jobs? The build/run ratio is again an interesting lens:
- Run part of jobs is zero-sum game. The more you do, the more value you capture out of the market. The market is vast but each meaningful pocket of value it contains is under competitive pressure. The more you run the more you cover and the more value you extract.
- Build part of jobs is not zero-sum game. Building a bad system is just bad. More bad efforts at building systems are just bad for the company. A bad system can have an outsized negative impact on the team. And the probability of bad systems being built increases with the size of the team building them (inevitable regression to the mean).
Before AI, the build/run ratio already had a direct impact on teams scaling. Revenue generating functions would generally scale as aggressively as the market would allow the systems of the company to capture. The standard cash predominance in the financial incentives designed to shape sales teams are exactly aligned with that objective. It completely disincentivize the build part of the job, delegated to another function and allow dynamic and flexible piloting of the run capacity of the sales organization. Conversely engineering functions, at the other end of the build/run ratio, and despite generally being a limiting factor for the company as a whole, would typically scale following market independent dynamics. As an example, we generally hear the rule of thumbs that 2x/year is the fastest you can go scaling an engineering team properly.
Post AI, build jobs will continue to not be zero-sum game. It is not about how much you build but rather about what and how well you build it. Even more importantly the build/run ratio of build jobs will shift even more towards building. Even in engineering, as companies grew, we used to have a growing pocket of mundane tasks that still required engineers. Organization had no choice but to scale their teams, generally accepting a fair amount of mediocrity doing so, to cover them. These mundane engineering tasks are a great example of the AI build/run ratio amplification. Machines can now handle most of them, reducing run impact on engineers and shifting even more their focus on building. But AI also increases their blast radius (imagine how much harm a few bad engineers working together can do to a codebase when equipped with dozens of agents), reinforcing the absolute criticality for insanely high talent density. This effect is reinforced when we consider companies not as closed systems but open systems exposed to a market, this time the hiring market, talent density having a substantial impact on the profiles a company can hire.
The Rules of Thumb
From this analysis we can extract simple heuristics or premises for how to think about scaling different functions post AI.
- High build/run ratio implies sub-linear head-count scaling compared to existing rules of thumb. Compensation mostly stems from equity.
- High run/build ratio implies preserved (maximal) head-count scaling. Compensation mostly stems from cash incentives.
The Consequence for GTM Orgs
GTM from an Enterprise sales perspective is mostly run (many caveats apply to PLG/consumer). It's therefore, based on the hypotheses we exposed above, a zero-sum game. AI is even more critical than elsewhere as a consequence. If you're not AI-pilled in engineering yet you can still compensate with humans and a good product management organization. It will cost more and expose you to degeneration effects but you won't get systematically distanced in the current market conditions (yet). But in GTM, given zero-sumness, any advance in AI implemented at competitors will directly impact your capability to extract value from the market. You need to not only be at the forefront of what is possible but also scaling the organization as aggressively as possible given the inherent human components of the job. More AI and more humans at the same time.
The conclusion we can draw for GTM orgs from the hypotheses of our build/run ratio framework is that companies need to over-invest on AI acceleration of revenue generating functions and at the same time continue maximally scaling their head-counts; however counter-intuitive or controversial it might seem at first given how educated we've been to believe that AI will replace all functions especially GTM ones.
At Dust, our sales team now prepares for meetings using agents that synthesize account health statistics, prior interactions, and market context into pre-meeting briefs generated automatically. For every pilot, agents generate internal mini-apps that offer one-click drafts generation for every internal stakeholders from founders to AEs to engineers to get in touch with key account people or pre-existing connections. Our sales calls have transformed thanks to AI-notetakers that capture everything and feed back into our systems. The posture of sales during calls changed completely: instead of note-taking and trying to remember details, they're fully present in the conversation. They get automated feedback against our internal documentation and objection handling. The humans remain essential. The mundane work around them gets automated. They run faster and better and we have aggressive plans to scale the head-counts this year.
The Consequence for EPD Orgs
While the urgency is lower than in GTM given the non-zero-sumness identified, it's also critical to internalize what the future holds. There are two extremes and every company falls on that spectrum:
- Your EPD org is still young and you have a chance to build an AI-first engineering organization. It's risky as it's different from what has been optimized in tech for the past 20 years but it's a unique opportunity to push the envelope, creating the future of EPD work.
- You've already scaled using pre-AI recipes and while your high 2000-2020 SaaS margins will absorb the drag incurred by the fat that built around the muscles, you will have to reinvent yourself entirely over time, better start now.
Building post intelligence abundance is a matter of taste and a question of talent. Mundane tasks are delegatable to the machine. Talent density becomes the gold metric. It's literally better to be 20 jedis than 200 clones. And soon enough we'll gain another order of magnitude in that ratio as models and agent harnesses get better.
Applying this framework to EPD orgs, the new rule of thumb for scaling EPD might not be 2x (or whatever it was for your industry) anymore. Unclear where the optimum is, but it's likely below pre AI comparables.
At Dust, we are currently pushing in two directions in engineering in particular:
- I've been spending a lot of cycles with the engineering team on making sure we're building a post-AI organization, not a pre-AI one. Our current engineering organization while young (20 engineers), is built with too many recipes from the past. The working document that defines how we will organize in 2026 is called EngOS 2026. A lot of it is inspired by the build/run ratio analysis exposed here. Most of it should be in effect in the weeks to come. If successful, many principles from it will likely get extended to the build part of every functions at the company.
- The tools matter as much as the organizational principles. We have a clear objective to make our development setup optimized for agentic use and we built dust-hive for that. 2026 really is the year we (as an ecosystem) kill vibe-coding with fire and move to serious scalable AI-driven engineering. Engineers are enabled with tools to manage dozens of agents with competency, taste and know-how. They produce much more code, but manage to maintain quality at the bar they achieved with manual crafting.
The cautionary tale here is that mediocrity sees its usefulness substantially decreased at the same time it sees its associated risks on the organization substantially increased. Mediocrity becomes the #1 enemy to combat in eng orgs in ways never seen before.
The Consequence for Operations Orgs
This one falls right in the middle. Parts of operations are build-focused and other parts scale with the rest of the team (HR, hiring). Being at the rupture line between build and run, operations is likely the part of the organization that will be most disrupted in terms of perception from the rest of the org and compensation. We'll likely see a shift from a run/cash position to a build/equity position for many operational roles. This is where the frontier sits, so adaptability and flexibility are likely the most important dimensions to consider as the building blocks of the organization get transmuted.
Conclusion
The consequence on culture is fundamental: many run functions will continue to scale head-counts maximally while many build functions will likely see their head-counts scale sub-linearly compared to the typical dynamics we observed in the market so far. The culture equilibrium within companies will inevitably shift and be subject to new forces.
If true, it is crucial to meditate and anticipate how it will impact our organizations, compensation frameworks, and ways of operating as tech companies.
The build/run ratio is a lens that can be used to audit organizations in the age of AI. For each function ask: what's the build/run split? What's the zero-sumness? While you want AI infusion all around the answers will tell you where to double down on scaling head-counts vs where not to.
What's exciting is that 2026 is likely the year these strategic moves will start having outsized impact on companies as they start directly affecting their dynamics in the markets they are interfaced with. The companies that thrive in the next decade will be those that got deliberate about this split early.