Some news: First, I wanted to invite everyone to a talk I will be giving about Drivers, Constraints, and Floats (see 2021 TBM 43/52) on October 14. I originally encountered the idea in Johanna Rothman's book Manage It! (2007). I've used it ever since and have made some enhancements and modifications. We send out the recording to anyone who signs up.
Take it a step further--assume "inspiration" is a substitute for not only knowing what to do, but how to figure out what to do. So if you have to deploy "inspiration" as defined here, by default you don't know how to reduce uncertainty in a more effective way.
A good researcher will be useless at optimizing algorithms, refactoring the code base, and deciding what button colors to use. All they do is significantly reduce uncertainty about what to build, when to build it, and why you should build it. Bonus feature: they'll make teams smarter by showing that most of what you think you know about customers, behavior, etc. is not as right as it could be. Like reducing technical debt, this reduces the assumption debt that looms like a cliff over most software teams. And unlike reducing technical debt, reducing assumption debt is the only way to build a true virtuous cycle.
Clarity is needed when the team is producing working software. That software has to look and act a certain way. That level of clarity and certainty suggests a corresponding level of certainty regarding what users will do with the software when it's done. That's the paradox, right? We're certain about what we're delivering, while being uncertain about what users will do with it once it's in their hands. But we have to proceed with a level of certainty in order to find out. That's why it's important all members of the team are involved in shaping hypotheses and experiments. All members of the team want to find out. All are invested in the experiment and learning from it. All the brains are needed to evaluate results, add their interpretation, discuss alternative next steps, and then take them. All are invested in achieving desired outcomes.
Does needing to inspire perhaps bias some product managers to certainty theater?
Lean into the uncertainty, but make decisions based on successful patterns.
How much inspiration? Is it fair to expect everyone to be 100% inspired? Can you be too inspired?
Not everyone is going to be 100% all the time. My capacity is not my team's, but you can never be too inspired. Sometimes it takes that one person to get everyone going.
Do we only seek clarity when forced?
We drive to solve a problem when we are forced to, otherwise we go down the path of least resistance. At the same time, an ever evolving world requires constant adjustment and pivoting. Sometimes clarity can be strategic.
What leeway does engineering have in your company to push back if they find a strategy lacking? What might that indicate if they can push back but don't?
That they need to see a connecting purpose behind the strategy. They need to be inspired by the potential end result, and the potential reach, and be reminded of the goal kindly, in different ways that remind them they have a purpose.
This assumes a single owner for clarity/strategy and a single owner for execution. Is that the only way to run things?
The more necessary transparency there is, the better everyone can contribute or feel like they have an opportunity to contribute in different ways. Sometimes I start a new strategy or a system and my team makes it better than I thought it could be. It's easy to see this when there are dead ends, or frustrations that keep repeating themselves, until someone points something out I didn't see before.
An empire is not built over night. And it especially isn't built alone. Trust in your team, be intuitive with their limits, and challenge them in a way that inspires them.
What does "inspiration" mean in this instance, and what does it look like?
Take it a step further--assume "inspiration" is a substitute for not only knowing what to do, but how to figure out what to do. So if you have to deploy "inspiration" as defined here, by default you don't know how to reduce uncertainty in a more effective way.
A good researcher will be useless at optimizing algorithms, refactoring the code base, and deciding what button colors to use. All they do is significantly reduce uncertainty about what to build, when to build it, and why you should build it. Bonus feature: they'll make teams smarter by showing that most of what you think you know about customers, behavior, etc. is not as right as it could be. Like reducing technical debt, this reduces the assumption debt that looms like a cliff over most software teams. And unlike reducing technical debt, reducing assumption debt is the only way to build a true virtuous cycle.
Clarity is needed when the team is producing working software. That software has to look and act a certain way. That level of clarity and certainty suggests a corresponding level of certainty regarding what users will do with the software when it's done. That's the paradox, right? We're certain about what we're delivering, while being uncertain about what users will do with it once it's in their hands. But we have to proceed with a level of certainty in order to find out. That's why it's important all members of the team are involved in shaping hypotheses and experiments. All members of the team want to find out. All are invested in the experiment and learning from it. All the brains are needed to evaluate results, add their interpretation, discuss alternative next steps, and then take them. All are invested in achieving desired outcomes.
Does needing to inspire perhaps bias some product managers to certainty theater?
Lean into the uncertainty, but make decisions based on successful patterns.
How much inspiration? Is it fair to expect everyone to be 100% inspired? Can you be too inspired?
Not everyone is going to be 100% all the time. My capacity is not my team's, but you can never be too inspired. Sometimes it takes that one person to get everyone going.
Do we only seek clarity when forced?
We drive to solve a problem when we are forced to, otherwise we go down the path of least resistance. At the same time, an ever evolving world requires constant adjustment and pivoting. Sometimes clarity can be strategic.
What leeway does engineering have in your company to push back if they find a strategy lacking? What might that indicate if they can push back but don't?
That they need to see a connecting purpose behind the strategy. They need to be inspired by the potential end result, and the potential reach, and be reminded of the goal kindly, in different ways that remind them they have a purpose.
This assumes a single owner for clarity/strategy and a single owner for execution. Is that the only way to run things?
The more necessary transparency there is, the better everyone can contribute or feel like they have an opportunity to contribute in different ways. Sometimes I start a new strategy or a system and my team makes it better than I thought it could be. It's easy to see this when there are dead ends, or frustrations that keep repeating themselves, until someone points something out I didn't see before.
An empire is not built over night. And it especially isn't built alone. Trust in your team, be intuitive with their limits, and challenge them in a way that inspires them.