Process vs. outcome

I’ve had a few conversations recently about the right balance between process and outcome. I’ve been involved with a group that’s been very (very) process focused- which has lead to some great discussion, but has hampered action/outcome and it’s got me thinking about where the balance lies between the two.

When I was younger (and apparently somewhat more patient)  I was much more process oriented. Outcome alone as the measure of success wasn’t enough  – there needed to be a solid process behind it. I’m reminded of my days at a Quaker camp in Vermont where we’d hold lengthy “town meetings” to make decisions. All decisions were made by consensus and often discussions on relatively mundane topics extended for hours. But it was truly the process that mattered the most –the outcome was secondary.

I’ve also been in organizations where the opposite was true. Often there was no process at all – or only a process that was specifically designed to get to a single outcome (and worse – make us feel like we somehow had input). That was efficient in decision making, but mercurial and very few voices actually were heard (and a a result, while decisions were made quickly, they weren’t always the best decision and certainly didn’t reflect the collective expertise of the group).

But I don’t think the balance is in the middle. To me, outcome is more important and should be weighted higher. The process should support decision making (although not be designed to reach only one conclusion – there’s no benefit in that) but shouldn’t take over. Not everyone needs to be heard on every decision and there needn’t’ be “process checks” every 30 minutes.  Everyone should understand going in what the process is going to look like and consistency and adherence to what you say your going to do is probably the most important aspect of making a process work.

I’m curious your experience with this.

  • Andy Blackstone

    Seth, process is what makes outcomes repeatable…. if you define process as the steps that lead to an outcome rather than just the process of coming to a decision.

  • I think you know my answer but I’ll put it up here anyway. Minimize process and focus on outcomes. You need to have some process, but your goal should be to continually minimize it relative to what you are trying to accomplish.

    • TL;DR; version – implementing process typically is used to change/increase internal value. Pre-Product/Market fit should focus more on delivering the most value to the customer through simplified/minimized Build Measure Learn iterations.

      Long version:

      I’m replying to Brad’s comment because Brad’s an awesome dude, but more importantly I strongly agree on minimizing process. Especially for trying to reach goals that have unknown or varying outcomes.

      I’ve been thinking a lot about this lately as the organization I’ve been working for has been struggling with process overload. We’ve adopted agile methodologies (scrum & kanban).

      The problem in my organization is that when our goals are unmet, we scramble to figure out what went wrong. Unfortunately the team’s assessment has been myopic and we only review the team & process as faults for not reaching our goals. This typically creates a discussion on how to amend the process and results in adding steps for checks in balances to avoid the failure. After a few months of this we’ve added so much to our process that we are doing more work to satisfy the process than we are for our customers/audience. I feel it’s the worst thing that can have happened with “process” as it’s hindering the team from delivering any external value for the customer (this pains me the most).

      I’m now trying to convince our stakeholders to throw away the process and let us focus on the external value for the customers. To replace the process I want to let the team executing the work discover how to be self-organizing through accountability. This in itself has it’s own challenges as I’m pushing up against escalation of commitment to the process (“we’ve spent a lot of money on trying to get to where we are and even though it’s failing, we’ll continue to do so.”).

      When it comes to delivering value to our customers I want to get to a place where we shorten our iterations for Build/Measure/Learn and keep that as fluid as possible. The more rigid that is, the more I feel we’ll miss opportunities. The challenges there are to keep us from rationalizing our learnings and keeping the same myopic view when re-evaluating our product & strategy through iterations.

  • In my best Yoda voice – “process – outcome it can be”

  • I’ve implemented/improved software development process at a bunch of cos. over the past 15 years.

    The best process your team can have is the one that makes it easier to get stuff done. Sounds obvious, right? I’ve thrown out tons of unnecessary procedural steps (meetings, reviews, commit blocking etc) that either slowed down actual work or simply created ceremony (busy work) around an otherwise simple step.

    Unsurprisingly, the larger a co is, the greater the degree (+ irrelevance) of all the process fluff. Imagine concentric circles where the inner circle is composed of the engineers developing stuff, and each circle outward contains more ‘junk’ that has less + less to do with producing software, and more to do with… well, something else.

  • Speaking from a Quaker perspective, Quaker Business Meetings need not necessarily be run in the manner you experienced in Quaker Camp. It depends on how well they are ‘Clerked’. However, it is important to note that part of the focus in Quaker Business Meetings is to produce consensus as an outcome. That might sound un-businessy but it’s actually quite closely allied to certain Agile practices to do with self-organisation and team commitment. I’ll be writing something longer elsewhere about the parallels between Agile and Quaker business practices for anyone who’s interested.

    I certainly agree with you that “Not everyone needs to be heard on every decision and there needn’t’ be “process checks” every 30 minutes.” Of course, I could ask what the people are doing at the meeting in the first place if they don’t need to be heard? Indeed, I could also ask why a single topic in a meeting is taking so long to discuss that you *can* check the process every 30 minutes? Perhaps the organisations where this happens have fallen into the trap of having meetings to “discuss things” instead of “to make decisions”?

    Finally, my own answer to your question is that outcomes are generally more important than process but bad outcomes are more likely if you use a bad process to get there.

  • Process is valuable as long as it helps us arrive at a good outcome. All too often we see a process being followed simply for the sake of it. Going through the motions is meaningless so there should be a greater focus on outcome.

  • In my opinion, there is no one right answer. It depends on what you are trying to accomplish. The more that you are going to repeat something, the more that it pays to really focus on the process. I’m an accountant, which involves quite a bit of repetition, such as monthly, quarterly, and annual financial statements, annual budgets, etc. When I don’t invest a little effort in improving the process for these things, I regret it over and over again due to the extra work and worse results that I get forever and ever and ever.

    However, when I’m preparing some ad hoc analysis, I minimize the process and just “git er done.” 🙂

  • Teddy Weverka

    There is no best decision.
    When you have a great team, you will have a multitude of good ideas. More than one of these will work well for you, if everybody is on board. Your task is to pick a path and get buy-in from your team. It is more important that everyone is pulling in the same direction than that you have an optimal target. It is better to achieve a really good outcome efficiently, than to have a slightly better outcome.
    Give the process time up front. Put everything on the table. Let everyone know that this decision process is about buy-in as much as choosing a path. Before completing the process, ask for commitment to the decision and ask all to drive hard to make it work. Design a closed-ended process. With this you’ll have a good path and an efficient execution.

  • The danger that comes with the attitude “not everyone has to be heard all the time” is that you could miss some great ideas from the team, and secondly, it diminishes other people’s stake in the process. When they get disenfranchised, it can affect their drive and commitment because they feel there’s nothing at stake for them.

  • Adam Smith