Variation itself isn't a problem to solve

A common tension in scaling startups is balancing high-ownership, people-driven approaches with low-ownership, process-driven ways of operating.

Early in a company you don’t have much process, and you just trust people to do the right thing and figure it out. As you grow, this inevitably leads to variance in how things are done – and pressure to “standardize” everything to make it consistent.

While understandable, I believe this push for standardization is often misguided: the mere existence of variation isn’t necessarily a problem to solve.

This is a common challenge as you hire people transitioning from larger companies. They notice differences in how teams operate and can’t separate where this is a feature, not a bug. Coming from environments where processes and controls drive consistency, they instinctively try to implement those same structures to make things comprehensible and manageable. Without the interpersonal trust or historical context, they interpret bottoms-up variance as something to fix, versus something to celebrate.

This happens across nearly every department, as people push to “standardize” without questioning whether the process solves a real problem, or genuinely adds value.

To be clear, there are absolutely cases where standardization is valuable. When something must happen the same way every time or when consistent measurement matters, processes are helpful.

For instance, as your Sales team scales, implementing standard playbooks can be really valuable to help new reps understand your sales motions, and give you visibility into the deal pipeline. Delaying this too long will hurt you.

But there are many other examples where implementing process to standardize can sound good, but needs to be carefully scrutinized.

Finance might want to standardize expense policies to eliminate any variation – for example, putting tight controls on how much can be spent per person at team dinners, or approval flows for new tools. But is the variance actually causing real issues? And if you’re seeing waste and fraud, is that really best solved through process, versus holding people accountable?

Product may push for standardized feature development cycles, with specs, checklists, and status reports. That’s “how it’s done,” but what problem is it solving? Is it really the variation in approach that’s driving quality issues? Or is the root problem issues on the team?

HR might advocate for standardizing hiring and performance management processes. While this can sound reasonable, is lack of process truly the source of bad hires or underperformance? Or is it a matter of having the wrong hiring managers in place?

And where some process does make sense, it’s important to not to over-shoot the mark. You don't need to solve for every possible edge case up-front. It's better to put in a minimal process that solves the problem today, and iterate from there where you actually need more.

As a recent example, at Hex we had a recent debate around “internal mobility”. We’ve had a few cases of folks moving between roles and teams (which is awesome!) but those were done in slightly different ways: some folks had to interview against external candidates, others did “rotations”, others demonstrated their fitness for the job in other ways. Someone flagged this as a problem deserving a standardization effort – but what was the actual harm? These moves all seem to be working well – is the fact that they took different paths really an issue? After scrutinizing this, we wound up with a very brief doc that creates some guardrails and embraces – rather than stifles – ownership.

Ultimately, these questions come down to the kind of culture you want to build. Is consistency more important than creativity? Is standardization more valuable than streamlining? Are you willing to sacrifice autonomy to reduce variance?

I’m figuring out how to navigate this tension myself, but my n-of-1 advice is to push hard to the first-principles problem beyond “things are being done differently”; really force folks to articulate the actual pain they’re trying to solve for. And where you do put in a process, keep it as minimal as possible, being careful not to overrotate and try to solve for everything.

In summary:

• Solve real problems, not hypothetical ones.
• Delegate teams context, not process.
• Hold people accountable to outcomes, not conformance.