Managing by Outcomes

There wasn't really anything I disagreed with in this. At the same time, there was nothing here that made me have an "aha" moment about how a company could really use this to improve, and worse, it avoided most of the "in the trenches" difficulties that make managing by outcomes instead of outputs (sometimes) very difficult in practice, especially in software.

In any moderately complex software product in a medium-to-large company, you're talking about teams, not just a singular team. You want folks to have as much freedom as possible, but at the same time, there needs to be a high degree of coordination and planning between teams, especially when it comes to software. You want to "change the balloon from red to blue" to use an example from the article? But what about the marketing team that already sent out the teaser video with the red balloon?

Honestly, one of the most demoralizing things I've seen affect software teams is not micromanagement, but what I call "whiplash" management, where priorities and directions change so frequently that teams feel like they have to spend more time replanning that actually building outputs.

I think there's a specific problem in here; outputs are concrete, outcomes are more abstract. All of the decision-making on how to achieve the outcome needs to sit low-down in the team doing the work, which is going to be fine (and ideal) in some situations, but terrible in others. Decisions should definitely be taken at the lowest point possible in the organisation, but they also need:

- pretty complete domain knowledge

- all the relevant information

- to not conflict with decisions being taken elsewhere.

As an obvious example, if you task the team who "own" the login page with an outcome of "50% fewer account lock-outs due to forgotten password", there are good ways and bad ways of achieving that outcome. Crucially, do they have enough knowledge / information / decision-making power to decide that a "reset password link sent by email" type feature is OK from a security perspective? That it won't conflict with the registration team's outcome to increase sign-ups (because they're thinking of doing away with requesting email)? What about an opportunity to allow people to sign-in on the web via the app (via QR code, a la many challenger banks) - this team doesn't "own" the app, how do they do that?

Having small teams is wonderful if the teams can be autonomous. If they suddenly need lots of outside co-ordination and discussion to ensure that their deliverables for outcomes don't tread on the toes of other teams, then they're coupled up again like a larger team and effectively lose the autonomy.

The role of management is exactly to provide this autonomy by pre-supplying the co-ordination and ensuring the work requested from the various teams makes sense as a cohesive whole. You generally can't delegate high-level business outcomes like "increase profits by 10%" to a single team, or multiple teams, without that level of agreement or co-ordination.

In every real-world organization, of any size at all, that I have ever worked in or been close enough to see into, this would mean: 1) the the output I want, and 2) if this doesn't give the outcome I want, because I asked for the wrong thing, you get dinged for that

There is a reason for management by output: it's honest. The manager decides what the output is, which is what's going to happen anyway, and if the direct labor made that happen, then the outcome is on the management, not the direct labor.

Pretending otherwise, will not result in the direct labor determining how to get to the outcome, it will just result in: 1) determine, through an elaborate game of corporate charades, what output I want, and pretend you chose that 2) deliver that output 3) insure that output results in the correct outcome

Managing by output is far more honest, and only judges the employee by what they are in fact actually allowed to have any control over.

As an agile, okr, lean, and pragmatic product guy... we still aren't here yet.

Tell dev teams 'why' and they complain about not having 'what.' tell them 'what' and they complain about not having 'how.' tell them 'how' and they complain about not having 'what' and tell you to mind your own business.

The problem is that it's too much for one person to define. i think the solution is having technical ux people (yikes) work on the 'how' with the devs and users.

A great read "Corps Business: The 30 Management Principles of the U.S. Marines" ( https://www.amazon.com/Corps-Business-Management-Principles-... ) and where it talks about communicating the "End State" of a mission instead of the steps required to reach that state. This encourages decentralised decision making, so that those "on the ground" - those actually building a product - are able to take the best decisions given the circumstances they encourage.

To me this is why OKRs work more effectively (so long as you take the metrics with a pinch of salt) than traditional roadmaps. You're focused on achieving a business state rather than chasing a set of arbitrary deadlines for "Feature X". Smart people suddenly have space to use their brains.

In fact typical product roadmaps end up a source of toxicity in most organisations I've worked in...

- Out-of-date the moment they are published.

- Tying down product managers with moving little boxes around PowerPoint; people who'd be better off getting out of the building and talking to customers or working with engineers

- Causing a blame culture around missed deadlines, sapping everyone's morale

- Needing multiple versions depending on the audience; low granularity for top level management, high granularity for engineers, carefully worded for customers and users e.g. "Add ad tracker" or "Fix bug causing data loss" may not be what you want sales people to present

- Always subject to (mis)interpretation

- Based on wild estimates of how long things will take 3 quarters ahead through the year

- Too focused on shiny deliverables and ignoring things like "We need to have to this quarter for re-writing a major component that blocks everything else"

- Often unread or poorly reviewed

- Bad at visualising dependencies between things being worked on

- A source of silliness like "Why are wasting time doing X when we know we need to be doing Y?" ... "Because it's on the roadmap"

... and probably loads more.

I've always thought as this more in terms of strategies and tactics. Theory of Constraints talks about this. The Strategy is what you want to be true, and the Tactic is how you do it. Strategies are best communicated as SMART goals, which is compatible with the OKR part. As far as managing, if I'm a manager, I give my subordinate a strategy, and trust them to come up with a tactic that is sufficient to make the strategy true (and I'll be a resource for them and work to keep them unblocked).

If a tactic isn't actionable, then it might have several substrategies. This can map well to an org structure.

I was totally with the presentation until about 40% of the way in. My objections with these kinds of "more agency for the team" approaches are as follows:

1) We are assuming dev teams want to do the extra work of defining what to make, or put another way, are happy with being responsible for it. Also for the people that do think that way, it assumes their teammates are likewise motivated.

2) In my experience, developers are not people-oriented and therefore will naturally resist collaboration at some level, especially with with customers.

3) Does any developer really think their time is well-spent participating in investigatory market research, advocated in this presentation?

Thoughts?

Disclaimer: I am a developer. I can get enthused about these approaches, but often gravitate back to the hermit-like mentality that drove me to programming in the first place. I can't help but think that a lot of this non-programming activity would be better served if organisations today just embraced the Business Analyst role more.

This garbage works for sales losers.