The Different Management Styles
Why the way you think about results might be wrong?
I don’t think I’ve been unlucky to work in many companies where work management was inadequate. This makes me believe that adequate work management is the exception, not the rule, let’s see if you agree with me.
According to the book “Outcomes Over Output” by Josh Seiden, there are different ways to manage teams:
- You can manage a team by telling them what to do: this is called output management. It’s a problem because deliverables don’t always add value.
- You can manage a team by asking them to create some high-level value, like increasing revenue. This is called impact management. It’s a problem because it’s not specific enough.
- What you want is to manage with outcomes: ask teams to create a specific customer behavior that drives business results. This allows them to find the right solution and keeps them focused on delivering value.
During my more than 20 years of career, I’ve mainly experienced output management. We focus on when the scope will be ready, without questioning the desired outcome. However, in software, what does ‘ready’ mean? The book highlights:
In the old days of engineering, setting project goals wasn’t that hard. If you’re building a bridge, for example, you know you’re done when the bridge is built and people are crossing it safely. If you’re making cars, you’re done when they roll off the assembly line. But when you’re making software products, done is less obvious. When is Microsoft Word done? When is Google done? Or Facebook? In reality, software systems are never done.
Does this mean we shouldn’t have deadlines? Of course not! But instead of committing to a fixed deadline and scope, we should be concerned with achieving a certain outcome within a certain period (a quarter, for example — it’s worth noting that this works more for products than projects).
The Difference Between Outcome and Impact
The value we seek is outcomes, but outcomes can be too broad. For example, reducing costs is a high-level outcome, and we must define which more specific outcomes can drive this high-level outcome (impact). The book defines this as follows:
“Outcomes, or the human behaviors that drive business results, are what happen when you deliver the right features.”
In other words, the right features are those that measurably change customer behavior and contribute to the business impact we are seeking. For example, enhanced usability of confusing features is a deliverable that results in fewer people calling for support (outcome) and drives cost reduction (impact).
It’s important to emphasize that not only this initiative drives cost reduction, other changes in customer behavior can contribute to generating the same impact. And that’s precisely why we should be able to break down “initiatives” into smaller packages. To see if our work is really making a difference, we need smaller, measurable checkpoints more connected to the work we are doing.
I have been involved with various teams that worked hard, but for distant management, it seemed like people were doing nothing because the focus on deliverables had lost its connection with the desired impact. It usually leads to micromanagement.
How to Define and Validate the Outcomes We Are Seeking?
To define and validate the outcomes we are seeking, the book suggests an approach based on magical questions:
- What are the user and customer behaviors that generate business outcomes? (This is the outcome we are trying to create.)
What’s powerful about this question is that it shifts the focus of your planning — instead of focusing on what you intend to do, you are focusing on the people you are trying to serve. It’s a big step to take if you’re trying to make your company customer-centric. - How can we get people to have more of these behaviors?
(These are the resources, policy changes, promotions, etc., that we will make to try to create the outcomes.)
We can change policy or prices. We can change how we position our product. We can change employee behavior when interacting with our customers. This question opens our solution space to a much broader range of possibilities. - How do we know we are right? (This reveals the system dynamics, as well as the tests and metrics we use to measure our progress.)
To know if we are right, we must be able to observe the cause-and-effect relationship between the deliverable and the outcomes.
The book gives an example of how to specify the hypothesis tests:
“We believe that if we increase the meeting rate of buyers and sellers at the start of the process, it will result in more successful transactions (as measured by X) and greater user satisfaction (as measured by NPS). “
I highlighted some words above because I believe this could very well work as a model for defining hypotheses to be tested.
The Challenge of Shifting from Controlling Deadlines and Deliverables to Monitoring Outcomes
All of this is very beautiful and indeed makes A LOT of sense, but in practice, it’s not so easy.
Jeff Levy, Director of Consumer Marketing for HBR, explained it to me like this: “It’s a big fundamental shift, and letting go of control. The team can’t just go out and do this on their own. It requires a close working relationship.”
To facilitate the change, we must be clear about the relationship between the benefit to the customer and the outcome for the business.
In outcome-based work, teams need to be really clear about the value they are trying to create and do this by specifying two critical outcomes of the work: the outcome they are seeking for the customer or user and the outcome they are seeking for the business. These two outcomes should be linked.
Model:
If we create this outcome for the user, it will deliver this outcome for the business.
Example:
If we reduce the bounce rate (the rate at which users become frustrated and give up during the subscription payment flow), users will complete their purchases at a higher rate.
However, in the end, the basis of all this is still trust, perhaps the hardest part: how to build a trust relationship between the different layers of management and execution to make this mindset shift? Maybe here I can return to the theme of psychological safety.
And as for what I said at the beginning, did I really have such bad luck working in many companies where work management was not adequate? I would love to find that out!
