The Process That Ate Your Team
Who this is for: Engineering managers, team leads, and founders who feel their team is either drowning in firefights or suffocating under process. What you’ll get: A framework for diagnosing which failure mode you’re in, and the smallest possible interventions to fix it.
Imagine two teams. The first: six brilliant engineers, who shipped almost nothing for an entire semester.
They weren’t lazy. They weren’t distracted. They had a roadmap, a project tracker, a weekly planning ceremony, a biweekly retrospective, a definition of done, a review checklist, and a sign-off chain that required three approvals before anything touched production.
They had so much process that the process itself had become the work.
Now, imagine another team. Roughly the same size, roughly the same caliber; was shipping constantly but breaking things just as fast. No documentation. No onboarding guide. The senior engineer who’d built the core system held everything in his head, and when he went on paternity leave, two junior devs stared at his code like archaeologists trying to decipher a dead language.
Two teams. Two opposite problems. And both would tell you, with total sincerity, that they needed “better process.”
They are both right. They are both wrong.
Here’s the thing I’ve come to believe after fifteen years of building and leading engineering teams: the problem is almost never “too much process” or “too little process.”
The problem is that most teams have no idea where they actually sit on the spectrum, with no vocabulary for talking about it.
So let me give you one.
The Question Underneath the Question
When someone says “we need better process,” what are they actually saying?
Sometimes they mean: I’m exhausted from putting out fires, and I want things to be more predictable.
Sometimes they mean: I’m frustrated that I can’t get anything done because there are too many gates between me and shipping.
And sometimes (more often than you’d think) they mean: I don’t trust the people around me to make good decisions, so I want rules that constrain them.
That last one is worth sitting with for a second.
A lot of process gets created not because it solves a real problem, but because someone experienced a bad outcome once and decided the way to prevent it from happening again was to add a checkpoint. A review. An approval. A meeting. A form.
And each individual checkpoint feels reasonable. Each one, on its own, is defensible. But they accumulate. They compound. And eventually you wake up one morning and your team is spending more time talking about work than doing work, and nobody can point to the moment it went wrong because it happened one sensible-sounding decision at a time.
Two Axes, Four Worlds
Picture a two-by-two grid. (I know, I know. Stay with me.)
The horizontal axis is Standardization. This is the degree to which your team has documented, repeatable, automated ways of doing things. Templates, runbooks, CI/CD pipelines, decision criteria, onboarding checklists. The plumbing that lets knowledge compound instead of evaporate.
The vertical axis is Judgment. This is the degree to which people on your team can think critically, adapt to novel situations, make good calls under uncertainty, and exercise real ownership over outcomes. It’s the human layer, the part that no process can replace.
Now look at the four quadrants these axes create:
Top right: Optimal Scaling. High judgment and just enough standardization. People think for themselves but don’t reinvent wheels. Processes exist to capture and share learning, not to control behavior. This is where you want to live. Scaling (growing) is encoded into the mindset and the culture.
Top left: Chaos. High judgment but almost no coordination. Everyone’s smart, and everyone’s going in a different direction. Knowledge is tribal. Success depends on heroes showing up. Nothing compounds. Your team might be individually excellent, but collectively mediocre at best.
Bottom right: Bureaucracy. Lots of standardization, but people have stopped thinking. “That’s not how we do it here” is the most common sentence you hear. Innovation dies not from rejection, but from delay and from a thousand cuts of processes/gates. Your best people are either frustrated or already interviewing somewhere else.
Bottom left: Dysfunction. No process and no judgment. I won’t spend much time here because no team survives in this quadrant for long. If you’re here, you have bigger problems than this post can solve.
The insight that took me years to realize is this: most teams (and organizations!) oscillate between Chaos and Bureaucracy. They swing back and forth like a pendulum, overcorrecting each time.
They start in Chaos: scrappy, fast, unstructured. Something breaks badly. So they add process. A lot of process. They swing into Bureaucracy. Things slow to a crawl. Someone (usually a new leader) comes in and “cuts the red tape.” They swing back to Chaos.
And so on. Forever. Unless you learn to find the edge.
How to Know You’re in Chaos
Here’s the thing about Chaos: it feels exciting. For a while. It feels like velocity. People are moving fast, making decisions, shipping things. There’s an energy to it that’s genuinely intoxicating, especially if you came from a bureaucratic environment.
But there are tells. And if you’re honest with yourself, you already recognize them:
- Fire drills are your operating rhythm, not an exception. You’re constantly reacting. Every week has at least one “drop everything” moment that wasn’t on anyone’s calendar.
- New hires take forever to become productive. Not because they’re slow, but because there’s nothing written down. They learn by osmosis, by watching, by asking the right person the right question at the right time. Which means they’re learning randomly, not systematically.
- You’re solving the same problems on repeat. Someone figured out the best way to handle X six months ago. But they didn’t document it, or the document lives in a Notion page nobody knows about, so someone else is figuring it out from scratch right now.
- The team has heroes, and the heroes are exhausted. There are two or three people who hold everything together. If any of them get sick, go on vacation, or (heaven forbid) quit, whole systems of knowledge walk out the door with them.
- Quality is wildly inconsistent. Some things are beautiful. Some things are held together with duct tape and good intentions. There’s no baseline, just individual standards.
- You can’t take a week off without everything catching fire. This is the acid test. If your absence causes visible disruption, your team is running on you, not on systems. That’s not leadership. That’s a single point of failure.
What’s actually happening underneath all of this is deceptively simple: individual excellence isn’t translating into team performance. You have talented people burning energy on delivery that should be going toward building systems. They’re doing the work and reinventing the infrastructure to do the work, every single time.
I ran a team like this for almost two years early in my career. I was proud of how fast we moved. I bragged about our lack of process. “We’re not bureaucrats,” I’d say. “We just ship.”
What I didn’t see (what I couldn’t see, because I was one of the heroes keeping the whole thing afloat) was how fragile it all was. The moment I got pulled onto a different project for three weeks, two major things broke that never should have broken, because the only reason they hadn’t broken before was that I was personally checking them every day.
That’s when I started to understand: speed without systems isn’t velocity. It’s just motion. It barely works, and definitely won’t scale.
How to Know You’re in Bureaucracy
Bureaucracy is sneakier than Chaos. Chaos announces itself with alarms and fire drills. Bureaucracy creeps in quietly, one reasonable-sounding rule at a time, until one day you realize your team is moving at half speed and nobody can explain exactly why.
The indicators:
- Decisions that should take hours take weeks. Not because the decisions are complex, but because they need to pass through three layers of review and two approval chains. The actual decision-maker has been abstracted away behind a process.
- People ask permission for things they clearly own. An engineer wants to refactor a module they built and maintain. They open a ticket, request a review, wait for approval. Why? Because “that’s the process.” The process has become a proxy for trust — and the implicit message is: we don’t trust you.
- “We’ve always done it this way” is a conversation ender. It shouldn’t be. It should be a conversation starter. If the best justification for a process is its own existence, that’s not a reason. It’s inertia.
- New ideas die from delay, not from deliberate rejection. Nobody says “no.” They say “let’s put it through the review cycle.” And then the review cycle takes eight weeks, and by the time it comes out the other end, the moment has passed, the energy is gone, and the person who proposed it has learned that proposing things isn’t worth the effort.
- Your best performers are visibly frustrated or already gone. High-judgment people have options. When they feel micromanaged or constrained by processes that don’t serve them, they leave. And what you’re left with is a team of people who are comfortable being told what to do. Which means you need even more process to compensate for the judgment you’ve lost. It’s a vicious cycle.
- More time goes to reviews and checks than to actual work. If your team spends more hours per week in approval meetings, code review queues, and documentation reviews than in building, designing, or solving problems, you’ve optimized for control, not for outcomes.
I have a friend who works at a company where deploying a single configuration change required approval from three people across different teams. The change itself took four minutes. The approval process took eleven days. When she asked why, the answer was, “Two years ago, a bad config change caused an outage.” So they built a process to prevent that specific failure from ever happening again. And it worked: that specific failure never recurred. But the cost of preventing it was that every config change, no matter how trivial, now took eleven days. The cure was worse than the disease, but nobody had ever done the math.
Here’s the uncomfortable truth about bureaucracy: it’s often created by well-intentioned people who are trying to prevent real problems. That’s what makes it so challenging to fight. Every rule has a story. Every approval chain has an origin. And telling someone “this process is slowing us down” feels like telling them “that thing you’re worried about doesn’t matter.”
But that’s not what you’re saying. What you’re saying is: “The cost of this prevention has exceeded the cost of the original risk, and we need to recalibrate.”
The Edge: Where Scaling Actually Happens
The edge between Chaos and Bureaucracy is narrow, and it’s not a place you arrive at and stay forever. It’s more like balancing on a surfboard: you’re constantly making small adjustments, leaning one way and then the other, reading the wave.
What does it look like when a team is on the edge?
Clear outcomes, flexible methods. People know what they’re trying to achieve and why, but they have real latitude in how they get there. The goal is specified. The path is not.
Processes that make good decisions easier. A decision framework isn’t an approval gate. It’s a tool. It says: “Here are the criteria that tend to lead to good outcomes in this kind of situation. Use them if they help. Discard them if they don’t.” The difference between a guardrail and a cage is that a guardrail still lets you steer.
People are empowered to edit and delete, not just add. This is one of the most underappreciated indicators of a healthy team. Anyone can create a process. The question is: can anyone remove one? If adding a rule requires a Slack message but removing one requires a committee review, your process is going to grow like weed.
Principles instead of policies. “We deploy with confidence” is a principle. “All deployments require sign-off from a senior engineer, a QA lead, and the team manager” is a policy. Principles scale. Policies calcify. Principles require judgment. Policies replace it.
Automation that frees people to think, not automation that replaces thinking. The best automation handles the mechanical parts: running tests, checking formatting, deploying to staging, and sending notifications. It doesn’t make decisions. It clears the runway so humans can focus on the decisions that actually need a brain.
The underlying idea is Minimum Viable Process. Just enough structure to trigger compounding. Just enough coordination to prevent repeated failures. Nothing more.
It sounds too simple to work. And in a way, that’s the point. The instinct when something goes wrong is always to add. Add a review. Add a check. Add a step. The discipline of Minimum Viable Process is in asking: “What is the least we can add that solves this problem?” And then actually stopping there.
Getting Out of Chaos
If you’ve read the indicators above and recognized your team in the Chaos column, here’s where to start. And I want to emphasize start, because the biggest mistake I see managers make is trying to fix everything at once, which ironically just creates a different kind of chaos.
1. Document the decisions you make most often.
Pick the three to five decisions your team makes repeatedly — the ones that come up every week or every sprint. Deployment criteria. Incident response priorities. Feature scoping trade-offs. Whatever your recurring decisions are.
Now write down the criteria you actually use when making those decisions. Not the criteria you think you should use. The real ones. The messy, intuitive heuristics that live in your head.
This alone is transformative. Not because the document is magic, but because it makes implicit knowledge explicit. It means the next time someone faces that decision and you’re not in the room, they have something to work with.
2. Create templates for recurring work, but treat them as starting points, not mandates.
A template that says “here’s a good structure for a design doc” is a gift. A template that says “every design doc must follow this exact structure or it won’t be reviewed” is a cage. The difference is in how you frame it and enforce it. Frame it as: “This is what we’ve found works. Start here. Adapt as needed.”
3. Establish one single source of truth for key information.
Doesn’t matter if it’s Notion, Confluence, a Google Doc, or a text file in your repo. Pick one place where the important stuff lives. Architecture decisions. Team norms. Onboarding steps. Who owns what.
The format doesn’t matter. The singularity matters. One place. Not five. Not “check Slack and also the wiki and also that doc Sarah wrote last quarter.”
4. Run a short weekly sync to align on priorities, and actually use it.
Fifteen minutes. What are the top three things this week? What’s blocked? What changed since last week? That’s it. Not a status report. Not a performance review. Just alignment.
The key to all of this: add the minimum structure that prevents your most repeated problems. Then stop. Resist the urge to systematize everything. You’re not building a machine. You’re building a team that has just enough shared infrastructure to work together effectively.
Shifting Out of Bureaucracy
If your team is in the Bureaucracy quadrant, the prescription is the opposite. And it’s scarier. Adding process feels safe. Removing it feels dangerous. What if we take away the guardrail and someone drives off a cliff?
Here’s what I’ve learned: they almost never do.
1. Audit every process that exists “because we’ve always done it.”
Set aside a day (I’m serious, block an actual day!) and walk through your team’s processes with one question: “If we removed this tomorrow, what specifically would break?” Not “what could break” in some hypothetical worst case. What would break, based on what we know about how the team actually works TODAY.
You’ll find that a surprising number of processes exist to prevent problems that haven’t occurred in years, or that were caused by people who no longer work there, or that are already prevented by something else you built later.
2. Replace approval chains with clear decision rights.
Instead of “this needs to be approved by three people,” try “this decision belongs to [specific person or role]. They inform these other people when it’s made.”
The shift from “approve” to “inform and proceed” is massive. It says: we trust you to make this call. We want to know about it, but we’re not going to gate it. This single change, in my experience, has a bigger impact on team speed than almost any other intervention.
(For a more full-fledged solution, create a Responsibility assignment matrix)
3. Turn reviews into feedback loops, not gates.
Code review should make code better. Design review should make designs better. If a review process doesn’t materially alter the outcome at least 30% of the time, it’s probably not earning its keep. It’s a ritual, not a tool.
Ask yourself: what percentage of reviews actually change the work? If the answer is low, you might be running reviews for compliance, not for quality.
4. Make a recurring appointment to prune.
This is the one that makes the biggest long-term difference. Every six to eight weeks, block a half-day for the team to ask: “What process is no longer serving us?” Make it safe to challenge existing systems. Celebrate deletion as much as creation.
The mantra: Remove steps until something breaks. Then take one step back. Not two. Not five. One.
Why This Is Harder Than It Sounds
I’ve presented this as a fairly clean framework: diagnose your quadrant, apply the corresponding interventions, adjust as needed. And at the conceptual level, it is that simple.
But in practice, it’s hard. And I want to be honest about why.
People have emotional attachments to process. If someone designed the current review workflow, telling them it’s unnecessary feels personal. If a team survived a brutal outage and built an extensive post-incident process in response, suggesting that process is now overkill feels like dismissing the trauma of the outage. You’re not just editing a Confluence page. You’re navigating people’s identities and fears.
Different parts of your team may be in different quadrants. Your infrastructure team might be in Bureaucracy while your product team is in Chaos. Applying the same intervention everywhere will overcorrect one while undercorrecting the other. You need to diagnose at the team level, sometimes even at the sub-team level.
The optimal point shifts over time. As your team grows or your business changes, the right amount of process changes. What worked for eight people won’t work for thirty. What worked when everyone was in the same room won’t work when you’re distributed across three time zones. If you enter a highly regulated market, you will need more compliance. The edge is a moving target, and the only way to stay on it is to keep checking.
Leaders often are the process problem. This was the hardest lesson for me. I realized, embarrassingly late, that I was personally the bottleneck in several decision chains. Not because the process required it, but because I hadn’t let go. I said I wanted the team to be autonomous. But I also wanted to be consulted on everything. Those two desires are incompatible, and the team was paying the tax for my inability to reconcile them.
If you’re a leader reading this, the most productive thing you might do today is ask your team: “What decisions are you waiting on me for that you shouldn’t have to?” And then actually listen to the answer.
The Smallest Possible Step
I’ve given you a lot to think about. So let me end with something small and concrete.
This week, do one thing:
If you see chaos indicators on your team: pick the one problem that keeps recurring and create the minimum process to prevent it. A short checklist. A documented decision criterion. A template. Something lightweight that takes less than an hour to create and saves more than an hour next time the problem comes up.
If you see bureaucracy indicators: pick one approval, one review, or one gate and remove it. Just delete it. See what happens over the next two weeks. (Prediction: nothing bad will happen. And something good might.)
The goal isn’t perfect process. Perfect process is a myth - a destination that keeps receding as you approach it.
The goal is optimal process. Just enough to coordinate. Just enough to compound. Not enough to control.
That narrow edge, that uncomfortable, exhilarating, constantly shifting balance between too little and too much — is where high-performing teams actually live.
It’s not a place you get to. It’s a practice.
And the practice starts with seeing clearly where you are right now.
If you found this useful, I’d appreciate you sharing it with another leader who’s wrestling with the same tension. The best process insights I’ve ever gotten came from someone who was one step ahead of me in solving the same problem.