Process is dead. Long live process.
The death of process
The spec was followed. The work was delivered. But when it was reviewed, the goalposts had moved.
What was once signed off as the right approach was now "not what we wanted." The team pulled up the documentation. It matched the implementation precisely. But it didn’t matter, because the definition of done was never shared, never stable, and never protected by structure.
This wasn’t a failure of engineering skill. It was a failure of process, because there wasn’t one. Not a real one, anyway.
There were no tickets. No backlog. No incident protocol. Just Slack threads and good intentions. A system of "just ask in chat," "ping the right person," or "somebody should probably look at that." It felt lean. Unencumbered. Agile, even, in the lowercase sense of the word.
But when things broke, nobody knew what should happen next. Because under the hood of this "lightweight" approach was an unacknowledged truth: even anti-process is still a process. It's just one no one agreed on, documented, or maintained.
In place of structure, we had improvisation. In place of shared understanding, we had folklore. And in place of ownership, we had diffusion masked as flexibility.
Process didn’t die because we formalized it too much. It died because we pretended we didn’t need one.
Mythologies of the anti-process culture
Every team has encountered leadership that’s skeptical of formal process. Often brilliant, sometimes battle-hardened by years of shipping under pressure, they’re certain that real work doesn’t need rituals.
They believe in hiring smart people and letting them figure it out. They trust in grit over governance, Slack over systems, and “just get it done” over “let’s make it repeatable.” Their teams are told they’re agile, but without Scrum, Kanban, or any of the artifacts that might imply bureaucracy.
This perspective doesn’t come from negligence, it often comes from experience. They’ve seen process done poorly. They’ve watched teams suffocate under frameworks meant to liberate. So they discard process entirely, assuming that less is more.
On the surface, this looks like empowerment. In practice, it’s mythology.
Myth #1: Process slows us down
The idea here is that structure is the enemy of speed. And it’s true, bad structure does slow things down. But so does chaos. When every deployment relies on tribal knowledge and direct pings, speed becomes luck.
Myth #2: Smart people don’t need process
Smart people especially need process, because they’re the ones solving hard problems. And solving hard problems repeatedly, safely, and collaboratively requires clarity, not just intelligence.
Myth #3: Agile is a scam
Some leaders saw Agile done poorly, boxed creativity, forced ceremonies, outsourced thinking to tooling, and concluded the entire idea was snake oil. But Agile wasn’t meant to be a product. It was a mindset. Rejecting Agile because of Jira is like rejecting music because you hate Spotify playlists.
Myth #4: We’re small, we don’t need it
Small teams especially need scaffolding. Structure doesn’t have to mean overhead, but it does have to exist. Without it, visibility fades and failure detection becomes luck.
Skepticism isn’t the problem. Lack of exposure to healthy process is. Without that exposure, teams keep reinventing the same dysfunctions, and calling them flexibility.
The cult of the living spec
In some teams, process isn’t absent, it just lives entirely in one person’s head.
There’s a document somewhere. Maybe a slide. Maybe a doc link buried in chat. But it’s not a source of truth, it’s a snapshot of what that person believed in that moment. And when that belief shifts, the spec shifts with it. Retroactively.
This isn’t iteration. It’s revisionism.
The danger of pseudo-process isn’t lack of vision, it’s lack of integration. Input happens in silos. Feedback is downstream. Execution becomes a guessing game: not “what did we build wrong?” but “what will they decide it should have been now?”
There are no rituals because the belief is that good people don’t need them. No documentation, because “I already explained it.” No change logs, because “that’s not how I think anymore.”
This kind of system doesn’t just break delivery, it breaks trust. Engineers disengage. They stop investing in quality because it feels temporary. Product managers become crisis mediators. Reviews become defensive instead of collaborative.
The worst part? From the outside, it still looks productive. There’s a spec. There’s Slack activity. There’s something being delivered.
But the product doesn’t evolve. It pivots reactively, led not by insight but by impulse. And the team doesn’t grow, they survive.
Real process isn’t about democratizing every decision. But it is about creating continuity, accountability, and shared understanding, so that what gets built isn’t just a reflection of one person’s current mood.
The aesthetic of productivity
When a team lacks real process, it often compensates with something else: the aesthetic of productivity.
Messages fly. Threads are active. There’s a constant hum of effort. It feels like progress, but it’s motion, not momentum.
Presence becomes performance. Engineers check in frequently, update reactively, context-switch constantly, not because it’s effective, but because it looks like engagement.
Behind the noise, core issues remain:
Ownership is unclear.
Work is duplicated or lost.
Decisions happen in DMs and vanish into ether.
This isn’t agility. It’s latency disguised as alignment.
Real process doesn’t suppress hustle. It removes the need for reactive hustle in the first place. It trades urgency for flow.
What Real Process Looks Like
Real process isn’t a ritual. It’s a system. And it looks like this:
1. Work is visible
Everyone should know what’s being worked on, what’s blocked, and what’s next. A single source of truth beats ten Slack threads.
2. Ownership is explicit
Accountability isn’t about blame, it’s about having the authority to fix what breaks, and the space to do it.
3. Feedback loops exist, and they’re short
Bugs surface quickly. Metrics shift observably. Alerts go somewhere useful. You know when you’re drifting before it becomes an outage.
4. Rituals have a purpose, or they die
If a standup is just a status dump, kill it. If retros change nothing, stop holding them. Process isn’t sacred. Outcomes are.
5. The team can describe how it works
Ask your team how work is prioritized, how releases happen, how bugs escalate. If the answers are inconsistent, you don’t have a process, you have folklore.
Rebuilding from First Principles
Good process isn’t installed. It’s constructed by asking what the team needs to do great work reliably.
Principle 1: Make failure detectable
If your system hides failure, it’s broken by design.
Principle 2: Assign clear ownership
Nothing should depend on memory or influence. Someone must own every critical flow.
Principle 3: Protect deep work
Context switching is a symptom of structural failure. Async over meetings. Prioritization over chaos.
Principle 4: Measure what matters (quietly)
Data isn’t for surveillance. It’s for course correction. Collect real signals, not vanity metrics.
Principle 5: Iterate the process, not just the product
Processes rot when they stop evolving. Schedule the retrospective, for the system, not just the sprint.
Process as a shield
There’s a quieter role process plays, one that doesn’t show up in charts or dashboards: it protects people.
Without structure, teams don’t just inherit ambiguity, they inherit personality. Direction shifts based on emotion. Priorities are driven by influence, not impact. In the absence of clarity, the loudest voice wins.
This isn’t a rare dysfunction. It’s the default state when process is absent or performative. Decisions get made in private. Blame flows downhill. Engineers start optimizing for optics, not outcomes, because what matters most is being on the right side of whoever’s in charge that week.
A real process insulates teams from this.
It defines priorities before pressure can distort them.
It formalizes escalation paths so people don’t get cornered in DMs.
It clarifies ownership so success or failure doesn’t hinge on politics.
It distributes power so accountability is shared, not weaponized.
Without process, every developer becomes a negotiator. Every PM becomes a translator. And every bug becomes a potential battleground.
Good process doesn’t eliminate conflict, but it contains it. It channels disagreement into structured forums. It slows down knee-jerk reactions. It gives individuals the psychological safety to focus on the work, not on surviving the workplace.
In short: process doesn’t just protect delivery. It protects dignity.
When success is silent
The irony of process is that its greatest achievement is often invisibility. When systems work, incidents still happen, but their impact is controlled. When alignment is strong, blockers resolve before they escalate. When ownership is clear, priorities don’t get tangled in politics.
But in many organizations, only failure gets documented. Only outages get retrospectives. Only breakdowns prompt leadership attention. So even if a team quietly ships a feature that saves thousands of users, or recovers thousands of leads, the moment passes without reflection.
Success, without process to capture and amplify it, becomes disposable. Invisible. Forgotten.
This imbalance creates a warped lens: the one failure defines the team, while the hundreds of quiet wins fade into the background. The result? A culture of reactivity, not resilience.
Real process fixes that.
It tracks impact, not just incident count.
It creates feedback loops that capture value, not just damage control.
It forces pause, not just to fix, but to acknowledge.
It builds memory, so future decisions are made with perspective, not panic.
Without this, leadership becomes myopic. The last outage is all that matters. The wins aren’t shared because they weren’t seen. And over time, teams lose their sense of progress, because no one ever stops to say: this worked.
Long Live Process
Process isn’t dead.
What’s dead is the bloated, performative parody of it. The kind that confuses tools for truth, ceremonies for alignment, and frameworks for thinking. What’s dead is the belief that if you just install the right rituals, good software will fall out the other side.
But process, the real kind, the kind that aligns smart people around hard problems, is not just alive. It’s essential.
It’s what lets small teams move quickly without burning out. What lets complex systems evolve without collapsing. What allows organizations to learn without repeating failure.
Process isn’t the enemy of speed. Bad process is. And no process is just invisible bad process.
So we don’t throw away structure, we strip it down. We don’t reject Agile, we reject how it’s been marketed. We don’t resist accountability, we demand clarity.
Good process:
surfaces reality instead of obscuring it,
scales autonomy instead of centralizing control,
reduces risk instead of creating overhead,
and evolves with the team instead of stifling it.
If you’re building something that matters, something that lives beyond a single engineer’s head, then you need process. Not as a cage, but as scaffolding. Not as dogma, but as discipline.
Because when it’s done right, process doesn’t feel like process.
It feels like momentum.
