Process Is a Tool, Not a Virtue

Process isn't the enemy of speed, but most leaders get it wrong in predictable ways. Some avoid adding any structure, trying to preserve scrappiness long after the organization has outgrown it. Others swing too far and import heavyweight processes from bigger companies, creating unnecessary gates and approvals that strip teams of autonomy without improving outcomes. Both paths lead to frustration.

The real question isn't "Do we need more process?" It's "What coordination problem are we trying to solve, and what's the lightest-weight way to solve it?" Process exists to solve coordination problems. When there's too little, teams duplicate work, ownership is unclear, and quality varies wildly. But copying another company's process wholesale, or adding controls to feel safer after an incident, kills speed and erodes trust faster than anything else.

Kevin Goldsmith's test is simple: does this process let teams move faster, or does it make them wait on someone else? Code review prevents production issues and enables confident shipping. Mandatory review meetings that require everyone to wait for a calendar slot are a very different thing. Same intent, completely different outcome. His cross-team change example nails this: instead of Team A filing a ticket and waiting weeks for Team B to prioritize their change, Team A makes the change themselves, notifies Team B, submits a pull request, and Team B reviews it. Fewer queues, faster delivery, same accountability.

Process ages. What helped at 50 people slows you down at 200. What worked at 200 creates friction at 500. If you aren't actively removing processes, you're accumulating them. The goal isn't less process. The goal is fit-for-purpose processes that protect autonomy, deliberately added when you see repeated friction across teams (not just between two people), and removed when they stop helping. That's how you scale without losing what made your team effective in the first place.