Beyond Headcount: A New Foundation for Workplace Programming

Every workplace program starts with the same question: how many people are we planning for? Increasingly, however, our clients can't answer it – not because they haven't done their homework, but because the question itself has become harder to pin down. AI is changing what work is, who does it, and whether a person does it at all, and it’s advancing fast enough that few organizations can credibly project the size of their future workforce. When that foundational input becomes unstable, something else has to anchor the work: a deeper understanding of what the business needs the workplace to do. That component of programming has always mattered – but it has never mattered more than it does right now.

For decades, the future workforce was knowable enough to plan around. Organizations might grow or contract, teams might reorganize, attendance patterns might shift, but the work itself was legible enough to translate into a planning range. That's what made headcount such a reliable starting point: tomorrow's organization was, more or less, a scaled version of today's. That is no longer the case. Our clients don't know whether their headcount will grow, shrink, or hold steady while the composition of work transforms underneath it. Roles may be eliminated, invented, or redefined faster than any projection can track. And because the timeline from planning to opening often spans roughly five years, clients are being asked to commit to buildings whose future occupants they cannot fully describe.

This is the quiet crisis in workplace programming. Our standard toolkit – headcount projections, growth scenarios, utilization data – is very good at modeling change within a known system, but it is much less useful when the system itself is being rewritten. The inputs aren't wrong; they're just no longer sturdy enough to carry the weight of a program on their own.

Yet even when an organization can't predict its future workforce, it usually knows a great deal about its future business goals. A company may not know how many engineers it will employ in five years, but it knows it will still need to do deeply technical work. It may not know how its teams will be structured, but it knows which relationships – with customers, partners, and its own people – it can’t afford to lose. It may not know what AI will automate, but it knows it will still need places where its value can be seen and understood by the outside world.

Those business needs are far more durable than any headcount projection, and in programming, they have to do more of the heavy lifting now than ever before. This is not a new practice; it is a new center of gravity. Good programming has always involved understanding how the business operates, but when headcount was more reliable, business needs often played a supporting role, adding texture and direction to a program whose scale was already largely established. Now, with that scale genuinely uncertain, business objectives move from context to foundation – not replacing quantitative analysis, but becoming what the program is built on when the numbers alone can’t hold.

This is also where workplace strategy becomes a way through paralysis. Many of our clients are stuck, unable to commit to a building because they can’t commit to a number. Anchoring to business needs gives them a basis for decisions that doesn’t depend on predicting the unpredictable. It turns “we don’t know how many people we’ll have” from a reason to stall into a problem that programming can actually work through. In practice, this is often what gets a project moving again.

We saw this firsthand in our recent programming work for a confidential semiconductor client in Northern California. This company operates in an industry where technology changes faster than almost anywhere else, and future headcount was genuinely unknowable. We still tested growth scenarios – that analytical discipline matters. But the program was ultimately shaped by the needs our client could count on carrying forward: robust infrastructure for deeply technical work, an elevated customer and visitor experience, and the flexibility to adapt as unknowns resolve. The critical shift was treating those needs not as inputs that informed the program, but as the logic that organized it. That reframing didn’t eliminate uncertainty, but it did give our client a stable center to build around and a clear basis for commitment.

This isn't just a semiconductor problem. Nearly every client we work with is facing some version of it, and it changes what they need from us. When clients can't tell us who will be in the building, we have to get much better at understanding what the building must accomplish for the business. Programming still needs data, scenario planning, and quantitative analysis, but those tools can no longer be where the work begins or ends. It has to start with a different question: what the organization needs to remain true to its business objectives as everything around it changes. Get that right, and the building no longer rests on a number that hasn’t yet come into focus. It rests on something firmer: a clear sense of the work it has to make possible.