Outcomes at Work

This is part 2 of a multi-part series focusing on Outcomes, not Output. You can find Part 1 here.

What causes the type of behavior we mentioned in Part 1? Lets dive a bit deeper into work to examine this. I work in the software industry, so this will be a software example, but maybe it applies to your workplace/industry as well.

Lets revisit our scenario: You’re being pressed by your boss to get the next piece of work done. You don’t really know why. You may not even know who or what the work is for, your leadership/management/your boss/product/etc just keeps telling you to get it done.

We know this happens all the time at work, especially in the software industry. But what causes it? I submit it’s a mindset problem. Here’s how most software companies seem to operate these days:

• We have to keep growing our staff or we’re doing something wrong (Growth at all Costs)
• The hardest part of creating value for customers is building the thing, so that’s what we should focus on (Solution vs Outcome Focus)
• We need engineers to build the thing so lets hire a bunch of engineers and nothing else (Incorrect Hiring Ratios)
• We have all these engineers, so we need them all doing something all the time (100% Utilization)
• The only way to grow your career is to become a manager (Too Many Bosses, Not Enough Workers)

Combine these things and what do you get? A bunch of people working really hard, but not really building anything of any substantial impact. You get a ton of managers sharing conflicting messages of what to do. You end up with a bunch of people that aren’t able to work effectively on teams because managers try to make sure each person is busy 100% of the time (to work effectively on a team, individuals will have downtime, as that is what creates flow. But more on that later). You create a system that encourages building “perfect solutions” to problems that you haven’t verified actually exist. The whole mindset flies in the face of what we’re trying to do: Be innovative by creating new products and features people love, and profit from those products…aka focus on Outcomes, not Output.

I saw this play out first hand at a company I joined a few years ago. When I arrived they had 10+ teams of engineers preparing to build a “new, disruptive, game changer of a product”. But that wasn’t enough — they were still hiring more people every week and creating new teams (Growth at all costs). And what was funny is I was seen as a controversial hire (being an Agile Coach). One senior leader literally asked me on my second week: “Why do we need you when I could just hire another engineer?”. (Incorrect Hiring Ratio). (We’ll dive deeper on this point in my next post).

This team had been building and growing for 6 month, but not a single feature was in front of a customer (or “in Production” as we say in the software industry) for feedback. The culprit(s)?

• There were a bunch of managers each telling the engineers a different thing to work on and they always claimed their work was the most valuable (Too Many Bosses).
• When a manager saw someone not working, they pulled them off onto “special projects” to keep them busy to show they were good managers, which killed team productivity (100% Utilization).
• Due to the points above, everyone appeared to be working really hard, but nothing was actually getting done.
• Because nothing was getting done, we kept adding more and more engineers and creating new teams. This made the problem worse as we kept having to stop and train these new people to get them up to speed (Growth at all Costs)
• No one seemed to even care about putting what we had in front of customers and getting some feedback (Solution vs Outcome Focus).

Well after another 6 months we sorted some of this out, and we were able to get enough done to put it in front of potential customers. The irony? They only cared about the work of 2 or 3 out of those 10+ teams. You heard that correctly: Only about 20 of the 100+ people working on this product produced value. Keep in mind engineers are not cheap: We’re talking about millions of lost dollars. Months of work going unused. I wish this was an isolated situation, but I’ve had the opportunity to work at 4 different companies and worked or consulted with 10+ product teams, and this was one of the “better” situations I’ve encountered. So much wasted time, money, and resources on things that don’t matter in the end.

I think we forget there are three main things we need to do to develop products and services that achieve the outcomes we desire.

1. Find a problem that is worth solving
2. Experiment small to figure out if we can actually solve that problem (in a better way than it is already solved)
3. If the answer to step 2 is “yes”, Build a full solution that solves that problem, otherwise go back to step 1
4. (Profit)

Most (tech/software) companies (and people) I encounter skip steps 1 and 2, try to jump straight to step 3, and they assume 4 will come as a result. And this is what causes all the waste I mentioned above.

What if we changed this approach? What if we spent more time and resources on #1 and #2? What would that look like? Isn’t that worth exploring?

This is part 2 of a multi-part series focusing on Outcomes, not Output. You can find Part 1 here.

Originally published at Practical Agile.