8 Process: Outcomes Over Rituals
This chapter is currently in draft form.
Process sits at the bottom of the leverage hierarchy. That makes it useful and dangerous. You can swap ceremonies in a meeting, update templates, ship a new checklist. It’s concrete and safe. Nobody gets hurt, nobody loses their job, nobody’s responsibilities change. They just do things a little differently. So tempting, and that’s exactly why it’s dangerous.
That’s why most technical leaders spend too much time here. Process changes are easy to implement and hard to evaluate. The feedback loops are long and the signal is weak, making process the perfect place to hide from harder decisions.
But process done right becomes a powerful multiplier when aligned with strategy, reinforcing structure, and supporting your people. The key is focusing on outcomes, not rituals.
8.1 Design Your Process
Here’s the most fundamental problem with process in most organizations: nobody designs it. They adopt it.
“We do Scrum.” “We’re a SAFe shop.” “We run two-week sprints.” These aren’t process strategies. They’re substitutes for thinking. You inherit ceremonies, roles, artifacts, and a vocabulary, and you assume the work is done.
But no off-the-shelf process is designed for your team, your context, your constraints. It might work to some extent—most frameworks have something useful in them—but it won’t be optimal. It probably won’t even be good. It’s generic, and generic process solves generic problems. Your problems aren’t generic.
Step one is to actually design your process. What are the real problems your team faces? Where do things go wrong? What feedback loops are missing? What does your team need to deliver reliably? These are engineering questions, and they require engineering thinking. Designing process is system design: inputs, outputs, failure modes, feedback loops, constraints.
This is not a project management problem. Engineers should own the design of their delivery process with the same rigor they’d apply to technical architecture. A PMO can provide patterns that have worked elsewhere and handle organizational coordination. But design authority belongs to the people who understand the work’s failure modes. When project management organizations own engineering process, you get process designed by people who can’t judge tradeoffs they’ve never faced. It’s like having someone who’s never written code design your system architecture.
The pragmatic reality: sometimes you have a PMO and they control some of it. Work within that constraint like any other. But name it as a constraint, not as the natural order of things. If you can push ownership back to the team, push it. If you can’t, contain the damage and own what you can.
8.2 Process Serves the Team
Process exists so that teams can deliver reliably. That’s the organizational goal—consistent, reliable delivery. But the mechanism for achieving that goal is process designed for the team first.
Engineering doesn’t exist in a vacuum. Marketing needs launch dates, sales needs feature commitments, support needs resolution timelines. You’re not aiming for perfect estimates but reliable patterns that stakeholders can plan around. Those organizational dependencies are real and legitimate. But you serve them through process that helps the team, not by designing process for organizational visibility and imposing it on the team.
When you invert this—designing for leadership’s visibility rather than the team’s function—you get compliance without delivery. The ceremonies happen, the reports get filed, but the actual problems stay hidden until they’re expensive.
One of the biggest problems in teams is getting support early. The cultural default is to struggle alone rather than surface blockers. Engineers don’t ask for help—they’re blocked, or they need input from someone, or they have an indecision they can’t resolve alone, or the work turned out to be far bigger than anyone thought. All variations of the same underlying problem: the work has hit something that needs external input. The faster that surfaces, the less time is lost.
Good process creates natural checkpoints where these problems become visible. If a task is timeboxed to a few days rather than a few weeks, you know by day three whether someone needs help—not day fourteen. Small batches aren’t inherently virtuous; they’re a forcing function for signal. A two-week task that goes off the rails at day three doesn’t get help until day fourteen. A three-day task that goes off the rails gets help by day three.
The same principle applies at the project level. A project scoped to two or three weeks, with a maximum of eight, surfaces problems early enough to address them. A six-month project hides problems for months.
The specific numbers aren’t prescriptions. They’re examples of taking the principle seriously: design process to shorten the distance between “I’m stuck” and “help arrives.” Your context will determine your own checkpoints. The judgment is in figuring out what serves your team.
8.3 Delivery Is Probabilistic
Team delivery is probabilistic, not deterministic. There are too many unknowns. People get sick. Work is more complex than expected. Someone in another org you depend on goes on vacation. Requirements shift mid-stream. Things aren’t going to flow nicely. It’s messy, and any process that pretends otherwise is lying.
Good process acknowledges uncertainty rather than pretending it away. One approach I favor is probabilistic estimates: a P5 and a P95 rather than a single point. “There’s a 5% chance we’re done in three days, a 95% chance we’re done in six weeks, and we’re targeting somewhere around the 70th or 80th percentile.” That’s less precise than “two weeks,” but it’s far more accurate.
This is an accuracy over precision problem. A single-point estimate is precise but usually wrong. A range estimate is less precise but actually useful. Organizations resist this because they want the false comfort of a single number. “When will it be done?” “Two weeks.” That feels certain. A range feels uncertain. But the range is honest and the single number is theater.
Story points often fail for the same reason. They become magical fairy points that don’t tell you anything unless you’re extremely disciplined in mapping them to actual wall clock time. And if you’re that disciplined, why not just use time? Ground your process in the things you actually care about. Wall clock time matters. Embrace that.
This is admittedly anti-Scrum, or at least anti-Big-A-Agile orthodoxy. But orthodoxy isn’t the goal. Reliable delivery is the goal. Design your process for what actually works, not for what the framework says should work.
8.4 The Maturity Curve
Teams mature over time, and your process approach should evolve with them. Early teams need scaffolding; mature teams need ownership.
When you inherit a team or start building one from scratch, you’ll often need to design process for them initially. This is the Blub Paradox at work. They don’t know what good looks like until they see it. You have to insert a lever to hoist them up. Once they see what good looks like, they can iterate toward better and great.
But scaffolding is temporary. As teams develop their own rhythms and build trust, they should take increasing ownership of their process. Your job shifts from designing the process to teaching them how to evaluate and evolve it.
This is part of a broader developmental arc. Owning process is second-order work: thinking about how you work, not just working. That’s the same muscle as thinking about the architecture instead of just implementing features, or thinking about team dynamics instead of just collaborating. None of that comes for free. It develops over time with deliberate investment.
Getting there requires deliberate handoff. When teams identify problems, ask them to propose solutions. When they propose changes, let them run experiments. Gradually shift from “here’s how we do things” to “here’s how you evaluate whether things are working.”
The best teams eventually own their process completely. They experiment, measure what works, and adapt based on their specific context. This is the goal: teams that manage their own continuous improvement.
This handoff isn’t just about team autonomy. It’s about your leverage. Every process decision you can successfully delegate is bandwidth you regain for higher-leverage work.
8.5 When Process Becomes a Crutch
The biggest danger with process is using it as a substitute for leadership. When strategy is unclear, leaders add more ceremonies. When structure creates bottlenecks, they add coordination meetings. When people aren’t performing, they add checkpoints and approvals.
You’re solving at the wrong level. Process can’t fix problems that originate at higher levels of the hierarchy. Unclear strategy doesn’t get clearer with better sprint planning. Structural bottlenecks don’t disappear with more standup meetings.
If you find yourself constantly tweaking processes without seeing improvement in delivery outcomes, look up the hierarchy. The real problem is probably one or two levels higher than where you’re applying the fix.
Use process to amplify the leverage you’ve created elsewhere, not as a substitute for creating that leverage in the first place. When process is aligned with strategy, structure, and people, it becomes a powerful multiplier. When it’s trying to compensate for problems at higher levels, it becomes expensive theater.
Your CTO constantly introduces new processes. Sprint planning gets reorganized every quarter. Standup formats change monthly. Teams complain about “process churn” but your CTO insists they’re “continuously improving.” This pattern signals weak leadership, not continuous improvement. Constant process churn usually indicates a leader who’s avoiding harder decisions at higher leverage levels.
Ask your CTO to explain the business case for process changes. Look for clear hypotheses about what outcomes will improve and how success will be measured. If they can’t articulate the connection between process changes and delivery results, you have a leadership problem.
If they can’t justify process changes with business outcomes, impose a moratorium on new processes for six months. Direct them to focus on strategy, structure, and people issues instead. Strong technical leaders make fewer process changes because they’re working at higher leverage levels.
8.6 When Stakeholders Have Process Opinions
Stakeholders often have legitimate organizational goals. They want visibility. They want predictability. They want to be able to plan around engineering timelines. None of that is inherently wrong.
But they don’t do the engineering work, which means they can’t design process for it. When stakeholders impose process, they’re optimizing for what they can see—visible activity, familiar ceremonies, the appearance of responsiveness. They lack the second-order thinking about engineering to understand what actually produces reliable delivery. It’s the same problem as PMO ownership: you can’t design for work you don’t understand.
I once had a team with a solid process. We were predicting dates accurately, signaling problems early, addressing them quickly. We spent time upfront investigating what we needed to do, especially in complex legacy systems. This made our iteration more confident and our dates more reliable.
Leadership saw the upfront investigation differently. To them, it looked like excessive design time. They mandated a leaner process that reduced the technical discovery work enabling our accurate predictions. The new process looked more responsive (less time before coding started) but handled ambiguity poorly.
The outcome was predictable: date accuracy declined significantly. We optimized for perception rather than outcomes. The constraint causing the problem remained invisible to those who imposed it. We worked within the new boundaries as best we could, but never recovered the prediction accuracy we’d had before.
If you face similar constraints, your options are limited. Build the case for why the previous approach worked. Find ways to preserve essential function within the new constraints. Accept the trade-off and manage expectations accordingly. Sometimes none of those options work. You absorb the loss and keep moving.