Ah process, everyone’s favorite word in tech! Right up there with “synergy” and “let’s take this offline”. What can I say, I gotta work that algorithm. Process is an interesting topic though, especially when you have worked long enough in industry to have the new hires be a different generation than you. How did that happen already! I am only 35 for crying out loud!. Someone bring me some soup, and a blanket and a fully funded RRSP.

It happens to all of us

The Process Problem

Process gets a pretty bad rap in tech. It’s often lumped in with bureaucracy, red tape, and that one person who keeps insisting we need to fill out a form in triplicate just to order more coffee pods. This characterization isn’t just unfair - it’s actively harmful to getting stuff done.

What’s particularly frustrating is how this mindset can create a self-fulfilling prophecy. Teams hear “process” and immediately think of their worst experiences with bureaucracy. This leads to resistance against ANY kind of structure, even when it would help them work better and faster.

Here’s the thing though: Process isn’t your enemy. Bad process is. I like to call bad process “con-cess” because:

  1. I love a good pun
  2. It’s literally a con job on your productivity
  3. I needed a catchy title for this blog post

But more importantly, con-cess is what happens when we implement process for process’s sake, rather than to solve actual problems. It’s the difference between “we need a documented deployment checklist because we’ve had incidents from missed steps” and “we need everyone to fill out these forms because someone might ask about them someday.”

The Absence of Process

You know what’s just as bad as too much process? No process at all.

Picture this: You need to get some work done with another team. Simple right? Except… how do you actually do that? Do you:

  • Slack the first person you know on that team?
  • Create a Jira ticket and hope someone notices?
  • Slack your manager and ask them to ask their manager?
  • Send up the Bat-signal?

I can feel the tension headache

Suddenly that “simple” task has turned into a multi-day adventure of trying to figure out who to talk to and how to get their attention. It’s like trying to find the bathroom in a strange house at night - you know it exists, but the journey there is full of stubbed toes and quiet cursing.

This absence of process creates what we can call “shadow processes” - unofficial ways of getting things done that develop organically but aren’t documented anywhere. They usually rely on tribal knowledge and personal relationships, which means:

  1. New team members are completely lost for their first few months
  2. If key people leave, suddenly no one knows how to get anything done
  3. Simple tasks take 10x longer for anyone who isn’t “in the know”
  4. Work gets duplicated because no one knows what’s already been done
  5. The same questions get asked over and over in Slack because there’s no central source of truth

A classic example of this is when deployment processes rely on tribal knowledge. Maybe there’s one person who knows all the undocumented steps and gotchas. What happens when they go on vacation? Best case, deployments slow down. Worst case? Complete deployment freeze until they return.

The Right Amount of Process

The secret isn’t having no process or tons of process - it’s having the right process. Incredible insight here, stick around it probably gets better.

Good process is like a good recipe - it tells you what you need to know to get something done, but it doesn’t dictate exactly how many times you need to stir the pot clockwise vs counterclockwise while humming your company’s mission statement.

When process is working well, it should feel like guard rails, not handcuffs. It should help you:

  1. Move faster by eliminating common decision points
  2. Avoid repeated mistakes
  3. Onboard new team members more quickly
  4. Scale your team’s capabilities
  5. Maintain consistency where it matters

Team documentation is a great example of this. A good process for documentation might be:

  1. The team creates a central library / location for all documents
  2. Every new document has a clear title, status and document type
  3. Anyone can create a new document type

That’s it. Three bullet points. But this kind of lightweight process can make a massive difference in team churn. Questions like “Where should I put this document?” or “Where is that document?” suddenly are eliminated.

Some signs you might have “con-cess” instead of process:

  • The process documentation is longer than the Lord of the Rings trilogy (and not nearly as fun)
  • You need to get approval from someone who needs approval from someone else who needs approval from the first person
  • The process exists because “that’s how we’ve always done it”
  • You spend more time managing the process than doing the actual work
  • The process doesn’t account for exceptions or emergencies
  • People regularly find “creative” ways to bypass the process
  • The process hasn’t been updated since the company was 1/10th its current size

The key difference between process and con-cess often comes down to one question: Does this help us move faster and better, or does it just help us track and control things?

Starting Light (and Staying Right)

The best approach? Start light. Really light. Like, “one sentence on the team page” light. Then gradually add more structure only when you need it. And most importantly - document it somewhere central! Having a process that no one can find is like having no process at all, except now you can feel bad about not following it.

Here’s my tried-and-true approach for implementing new processes:

  1. Identify the actual problem

    • Not “we need better documentation” but “new team members take 3 months to become productive”
    • Not “we need better processes” but “we had three production incidents from missed deployment steps”

  2. Start with the absolute minimum process that could help

    • One-page deployment checklist
    • Simple PR template
    • Basic runbook for common tasks

  3. Lightly enforce the new process

    • Remind people to use it
    • When someone does not follow it, ask why
    • Make it easy to follow (e.g. templates, automation)

  4. Document it in an obvious, central place

    • Not buried in Notion
    • Not in someone’s Google Doc
    • Not in the oral history passed down through generations of developers

  5. Get feedback early and often

    • Ask the team if it’s helping
    • Watch for signs of people bypassing the process
    • Monitor if the original problem is improving

  6. Iterate based on real needs

    • Add steps only when problems actually occur
    • Remove steps that don’t add value
    • Adjust based on team size and complexity

And here’s the real key - regularly ask if you’re still getting value from your processes. Just because something made sense six months ago doesn’t mean it makes sense now.

Remember: Good process grows with your team and adapts to change. Bad process is a fungus that grew out of the uh, crap, you are dealing with.

In Conclusion

Process isn’t inherently good or bad - it’s a tool. Like any tool, it can be used well or poorly. The goal isn’t to eliminate process or to create process for process’s sake. It’s to create just enough structure to help people get their work done efficiently.

Remember: If your process feels like a con, it probably is. And if you find yourself saying “well that’s just the process”, it might be time to take a hard look at why that process exists in the first place.

And if all else fails, just remember: you can always take it offline.

Post Cover Image from: DALL-E by OpenAI