I got asked recently how I think about processes changing with AI-enabled teams. I wrote about how I saw roles shifting over a year ago now (wow) and touched on this, but it’s time to revisit and go deeper.
I now think of process as infrastructure in service of two things: the outcome your customer actually gets, and whether your team is pointed at the same target. Everything else, no matter how official it looks on a slide, becomes ceremony.
Why this question is suddenly everywhere
There’s a reason companies are reaching for more senior people right now. Judgment, taste, pattern recognition should come built-in after enough reps. You’ve already seen the failures and successes, so you should have developed taste and the ability to make sound judgments quickly.
A newer, highly productive person can absolutely develop that same judgment over time. But it takes reps, and it takes a company willing to absorb the mistakes along the way. You can (and should) work to lower the cost of failure, but optimizing for getting things right first is still a better bet overall for most companies, products and teams.
This gets at something people miss about process: a lot of times process exists to compensate for judgment the team didn’t have natively yet. That said, the amount of process you need isn’t really a function of company size or stage. It’s a function of how much pattern recognition is already present versus how much has to be manufactured through review gates, sign-offs, and checklists instead.
Two failure modes of process
Too much process creates a drag: approvals, sign-offs, etc. often with little focus on the customer and more about internal optics. To much process can also teach smart people to self-censor. The moment flagging a problem early costs more socially than staying quiet and letting it surface later, the process has failed at its intention.
But too little process is its own failure and can mean unclear priorities, duplicated work and decisions quietly re-litigated because nobody wrote down why they were made the first time. The best teams find a way to manage alignment without overburdening with process, and this is a constant iteration to strike the right balance. It doesn’t have to be massively time consuming, but it does have to be considered and intentionally managed.
Process has a stage, not just a size
Pre-product-market-fit, pre-real-revenue: the right amount of process can be close to none. A solo builder or a tiny team can hold the whole picture in their heads and stay aligned more easily.
Things change as customers and change management emerge, which is a function of success, not failure. Teams that were genuinely fast pre-PMF often keep moving at the exact same speed afterward but may fail to navigate the fact that more people (including customers) have to keep up now. These teams may remain fast in silos. Everyone’s shipping, nothing’s hitting production in coordination, and the thing that made speed valuable in the first place (impact) disappears while activity stays high.
Fixing this is often seen as slowing things down, but when done well becomes an accelerator to the team and restores the coordination that speed was supposed to produce all along.
How to actually do this
Saying “align the team” is easy. However, in order to do it means designing the team to work asynchronously by default. Get alignment up front, before the work starts, not in the call after the call. Build rapid prototypes, write documentation succinct enough that both the humans on the team and the agents the team now works alongside can pick it up and act on it correctly.
Done well, this is how a team stays fast, coordinated, and collaborative even as headcount and customer count grow.
Why this shows up at every scale, not just big companies
This isn’t a large-company problem only. A founder with a small team pulling ideas out of their head and into Claude Code may hit a similar failure mode a 400-person org hits, although it will feel different. Their marketer can’t market what they don’t understand. Their salesperson can’t sell what wasn’t communicated clearly enough to land. A larger company runs into the same problem at a different scale: some customers have a high tolerance for change and want everything now, some don’t and can’t absorb it, and you need an operating structure that serves both without slowing to the pace of your ability to innovate, but matching your customers ability to consume that innovation.