
Managing by Outcomes - laurex
https://www.producttalk.org/2019/10/managing-outcomes/
======
hn_throwaway_99
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.

~~~
bryanmgreen
Whiplash management is extremely real and I've seen it take chunks out of
company growth and revenue.

Seems to me that the best way to combat it is to provide leadership with as
much feedback as possible from both internal and external sources so they can
evaluate options rather than jumping to the first "solution" or "next best
thing" they think of.

What do you think?

~~~
johnm
That's presuming that the drivers for management have product/customer reality
as a high priority. In big companies, "managing up" and corporate politics
strongly dominate. Those are the fundamental drivers of whiplash management.

------
ealexhudson
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.

------
rossdavidh
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.

------
RocketSyntax
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.

~~~
kthejoker2
I guess I don't understand if you've got a good why it's so hard to arrive at
some reasonable approximation of what. You can so quickly prototype and test a
bunch of whats. You can draw things on paper, you can spend a week luxuriating
in all the whats if you have a good why.

And if you don't have a good why, no amount of design or development will save
you.

------
harryf
A great read "Corps Business: The 30 Management Principles of the U.S.
Marines" ( [https://www.amazon.com/Corps-Business-Management-
Principles-...](https://www.amazon.com/Corps-Business-Management-Principles-
Marines/dp/0066619793) ) 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.

------
tunesmith
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.

------
trilinearnz
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.

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

The best developers I've worked with have proactively requested to be involved
in user research and feedback sessions. They want to know the customer. They
understand why they are building what they are building, and provide valuable
feedback when they encounter issues during development that weren't accounted
for during the design phase. They behave as partners rather than line workers.
Anecdotally, these have been the developers that are most respected internally
and promoted to leadership as well.

------
foobar_
This garbage works for sales losers.

