We Care Too Much — And Too Little — About Process

Article by Nick Walsh — Jun 17, 2025

Software is a game of communication, and communication begets some amount of process. And we add a lot of it. At scale, that tends to become paralysis: flows that feel like they meet the need, but slow progress to a trickle. As an industry, we care too much about performative process and, at the same time, care too little about making sure it actually serves the cause.

Each project is (at least) a little different, each team is (at least) a little different, and each day is (you guessed it: at least) a little different, but we still try to jam every effort into a predetermined set of “best practices.” The prescribed way we do things here for many companies is overwrought, eternal, and not up for questioning.

As a policy, forced communication isn’t a substitute for good communication — but we also can’t just assume that communication is happening in the first place. Or skip it altogether. Let’s work our way through the opposing forces of too much and too little.

Where Did All of This Process Come From?

First up on our tour: How the heck did we wind up with all of these (questionably useful) practices? We usually see companies add net-new processes through:

• Policies with a story attached. Some rules are a thinly-veiled log of everything that’s ever gone wrong at the organization. “Don’t deploy after lunch on Friday,” “summarize and document every one-on-one call,” and “don’t change the configuration file without Sam’s oversight” all come from painful lessons learned.
• Vendors that seem to have it figured out. Third-party vendors add some outside expertise, sure, but they also bring their own set of processes and standards. It’s tempting to co-opt a few of the best ones after seeing them in action.
• Past lives of employees. Similarly, new employees bring new (to you) process wisdom to review and disseminate.
• The last article, book, or conference a manager experienced. Scariest in its potential for large-scale change is the manager who just found something new. Conference trips are a recurring culprit, but books and articles can do the trick too: fresh ideas, and an urgency to implement them.

So, over time, teams accumulate parts and pieces from a number of sources. Some of it works great, some is great in theory, and some… lacks cohesion.

We Bother With Process Too Much

For many, process is a panacea, and praying at the process altar comes with fiddling, poking, prodding, and adding to the approach until it just can’t fail. But there’s trouble in too much, usually manifesting in:

Just Add a New Step

Did something go wrong? Was a requirement lost in the shuffle? Toss a new step in there to make sure it never happens again.

In isolation, the reflex (add steps) isn’t a bad one:

• It’s worthwhile to reflect and make (some) reactive changes to your process
• High-regulation industries and new litigation will naturally spawn more steps
• As a team grows, more steps will also follow

There’s a catch, though: There’s no way to know when you’re done, and it’s easy to ride the slippery slope towards a Rube Goldberg-esque contraption with twenty handoffs to change a lightbulb. Something that no one can keep in working memory. Or explain easily. Or begin to know how to untangle and simplify.

Software is a sack of uncertainties, and there’s (some) magic in the unknown. Progress needs facilitation, but too much process takes agency away from the experts involved. “Steps” have a habit of siphoning away ownership, nuance, and judgement calls that would otherwise smooth over deliverables that are anything but repeatable.

Prioritize Low-Hanging Fruit

Following on with the previous section: At some point, the cobbled-together process behemoth starts actively rejecting large efforts. Estimates on new quarterly goals will make executives’ eyes water, causing those requirements to retreat back towards strategy meetings and circular communication.

To keep some amount of momentum, “quick wins” look really attractive. And achievable. Bugs, updates, maintenance, and small tweaks keep tickets flying, and short-term progress is a dopamine hit for project teams.

At the end of the quarter (or your personal favorite time-related checkpoint), those quick wins start to feel like lost time when everyone realizes the big priorities haven’t moved an inch.

Dedicated Clean Up Time

Designers, developers, and other folks on the implementation team don’t have a sterling reputation for keeping tickets and tasks updated. It’s a stereotype rooted in truth.

Even with that blanket caveat in mind, this one’s pretty easy to see coming: If those same designers, developers, and such have to disappear for hours (or days) to catch up on process-related documentation, it’s a red flag.

Ideally, status updates are a seamless part of the day-to-day. If it takes a bunch of effort beyond that — or if the implementation team routinely procrastinates until it’s a big deal to catch up — the process has probably crossed the too much line.

Conversations Happen on a Schedule

Turnaround time and lost time are directly correlated, and the former often falls victim to gatekeeping. There’s a delicate balance at play: How do decision-makers make themselves available without being overwhelmed or inefficient with their attention? Many a process stumbles on the “standing meeting” trap — we meet every Thursday, so we’ll ask them then. Not a problem if it’s Wednesday; not great if it’s Friday.

Even if it’s for a limited run of time, key stakeholders may be needed on a tighter cadence to keep turnaround time from becoming lost time.

Experts Can Weigh In Later

Developers are problem solvers by nature, and they struggle mightily when they’re given a solved problem without context. Processes that wait to “loop” them in until there’s a direction add some complications:

• Developers — especially the good ones — will absolutely be compelled to follow that solution back up the chain of decisions and see how it came about.
• They may not agree with the outcome, and usually have other ideas worth exploring.
• If they feel strongly about a different solution, implementing the “wrong” thing feels like a loss of ownership in their work (which tends to impact quality, too).

It may feel like overkill to keep the full project team in-the-know from kickoff, but that’s the easiest way to sow engagement.

Ownership By Committee

To close out too much, we’ve arrived at the thread that ties all of these woes together. This section’s thesis: If you take ownership away from people and hand it to process, you’re missing out on some of the quality and innovation you can count on ownership to spark. Lacking that responsibility, some folks will do just enough to check a box and pass their deliverable along — detached from how it arrived or how it ultimately ends.

Process is all about finding an equilibrium between agency and guide rails.

We Don’t Bother With Process Enough

So far, we’ve talked a lot about too much process. Caring too little usually slides in as a side effect of that — there’s so much already, how could we possibly bother with what’s missing? Why untangle what everyone’s already used to? Problems pop up when you encounter:

Just Skip a Step

As we explored earlier, teams:

• Like to add steps
• Don’t like removing steps

And on the back of those two truths, you’ll wind up with a process that struggles to achieve big goals — unless there’s an attached executive with the power to ignore whichever steps they don’t like. Suddenly, pet priorities are much easier to achieve. Fires are put out quickly.

It feels like it works (and it does for a bit), but executive skips are a fleeting solution. Eventually, they’ll move on or get pulled away, and the tidal wave of process comes for the team that remains.

Prioritize Today’s Fire

It’s morning, and you absolutely need to go to the grocery store before the end of the day. As you prep, though, you go ahead and toss a pile of clothes in the laundry… which reminds you to fold the towels in the dryer. On the way out, you stop to clear some dishes from the sink. And take out the nearby trash, now smelling a bit and threatening to attract flies. The bag winds up dripping a little on that trip, so you’re compelled to pull out a mop and return the floors to a better state.

In all, you’ve accomplished a lot today — but not the thing you actually needed to.

Just like prioritizing low-hanging fruit, it’s common to struggle with the proper order of operations and get distracted. Reactive decisions over long periods of time curb meaningful progress.

Make the Same Mistake Again

Let’s expand on an earlier point:

• As explored in “Just Add a New Step,” trying to fix every single issue you encounter through process changes doesn’t work.
• At the same time, recurring trends should absolutely be identified and course corrected for the future.

Ideally, process helps you avoid making the same mistakes over and over again. If you’re cyclically having the same conversations, too little process is a culprit worth addressing. Just don’t overdo it.

Never Look Back

How often do you question your process assumptions? Whether they’re busy, or plan for the best, or get used to it, teams have a hard time looking far enough back on concepts like:

• Were handoffs between different disciplines smooth?
• Are we documenting adequately for people downstream to understand what’s up?
• Where do we struggle with each production release?

As in the last section, teams should be ready to conduct an end-to-end review of a given project and seek to challenge incomplete or inadequate steps.

Blockers Belong to the Blocked

We all “get” the crunch of crunch time, but under normal circumstances, you’ll want everyone on the crew feeling informed and productive. Too many times, we’ve seen junior team members stuck twiddling their thumbs and bearing the responsibility of getting unstuck (without the means to do so). Problems with morale, progress, process, mentoring, and learning all rear their head when there’s a hierarchy to who can be blocked by teams, decisions, and deadlines.

It’s leadership’s job to clear the path, not the person who’s stuck due to upstream choices.

“Best Practices” in Process

There’s a bit of reassuring news: Everyone deals with process woes, and they’re untethered from scale. Startups and enterprise organizations of every shape struggle to put the right guide rails in the right places, whether they’re corralling five or five hundred.

We’d all love to find the perfect process, but it’s really easy to disproportionately piece together something that isn’t quite right. “Best practices” here aren’t consistent across teams, projects, organizations, or even a lone sprint.

It’s all about authenticity in communication — fit is the most important process measurement.