Yesterday we talked about how Alex made two, process-related mistakes.

1. He used process instead of analysis.

2. He focused on process instead of outcomes.

We looked at the first one already. Let’s dive into the second one today.

Process vs outcomes

A few days after Alex launched his process to fix engineering, my team started complaining. They were seeing what I was seeing. Alex’s process was slowing us down.

Trying to be a good captain, I called a meeting with Alex to share my team’s feedback. I told Alex that the process he created was slowing us down instead of helping us ship our OKRs. I also told him we had no trouble shipping our OKRs before and that perhaps he should focus on fixing the teams that couldn’t.

"We need to hold everybody accountable to the same standards" he replied. I told him that I agreed 100% but what I was suggesting was that we should have focused on standards based on what was being delivered as opposed to how.

Alex's process dictated how the work was done rather than enforcing what work was done.

Alex’s mistake was to focus on process instead of outcomes.

The right thing to do

Alex didn’t have a problem with standards around outcomes. We already had those. Each team had clear deliverables (i.e. their committed OKRs). Alex should have kept our outcome-based standards and focused on troubleshooting each team.

But there is another insight to be gathered here.

We humans like freedom and we really don’t like it when external forces limit it. We don’t like it when someone takes our agency away. We feel judged. “You don’t trust my actions? Is that why you are taking away my agency?”

As captains, we should strive to never take people’s agency away. Managers control. Captains empower.

So, whenever we are tempted to introduce a new process we should pause and think. We should ask ourselves: “What outcomes am I trying to achieve with this process?” We should then ask people to commit and deliver on those outcomes and forget about process entirely. The results (i.e. the outcomes) will be the same but people will retain their full agency on how to achieve them.

That said, sometimes process is necessary. Perhaps you want your teammates to write more tests for your codebase. Or, you want to introduce coding guidelines. If we must constrain the how, we should strive to clearly articulate the outcomes the process is trying to achieve. We are all adults, remember? Adults don’t follow instructions blindly. We ask why. Outcomes are “the why” of the process.

Have a great weekend and see you all on Monday! 👋🏻

-Ale

P.S. What did you think about this post? Reply to let me know!