This series is about how you might move to a product-based organization. Part 1 was about how when we organize by function, the recognition and rewards might prevent a successful agile transformation. Part 2 was about one possibility for moving to a product-based organization. Before we get to who moves where, we need to consider the manager roles.
Moving to a product-based organization means we change the way we view and reward managers.
Measure Managers Differently
Our industry has a history of measuring managers badly, if at all. Too often, we measure them by meeting a date for a given project. Or, by managing a customer’s problems. Or with KPIs (Key Performance Indicators) that assume knowledge work is factory work. (See my writing on OKRs and MBOs.)
All those measures are about a manager’s span of control, a sign of resource efficiency. If you measure based on only the date, you release potentially-horrible product. If you measure based on how managers fire-fight problems, you might increase multitasking and you still don’t have any measure of quality.
Product organizations don’t optimize for control. Product organizations optimize for throughput, for flow efficiency. The manager’s role changes from control to serve the teams, so the teams can achieve their flow with technical excellence.
From Control to Service
I’ve tried to think about a term for how we change how we think about managers. It might be moving from “span of control” to “span of service.” Managers provide a service of optimizing for the organization’s throughput. (If the teams maintain their technical excellence, you don’t need to worry as much about customer problems.)
If we optimize for flow and technical excellence, we see managers optimize “up” wherever possible. They manage the flow of work through the organization and help teams manage their flow:
- Instead of “controlling” the date, managers control the flow of work through the organization. This means managers manage the project portfolio. Product managers manage the product roadmaps. Product owners manage a given team’s backlog. (If your organization doesn’t need that many people to do this management, even better.)
- Managers help the teams optimize their flow of work. Managers remove systemic impediments. Those impediments might be lack of a team room or other equipment. For a distributed team, the impediment might be insufficient hours of overlap or helping the team create its virtual workspace.
- Managers help people build their interpersonal skills, those deep skills that create psychological safety and a culture where people want to work.
Since managers manage the flow of work, they pay attention to their decision times.
Project and Team Measures Change
Here’s what managers don’t have to measure or “manage”:
- Any team’s cycle time or velocity. They can explain to a team that a longer cycle time means the teams and therefore, the managers, have unknown risks. Is there a way the manager can remove impediments to help a team achieve a regular or shorter cycle time?
- The end date for a project. The product owners, product managers, and even the project portfolio people are in total control of when a project is done. They might not like the time it takes a team to complete a minimum adoptable feature set. In that case, add another team, or see if there is a different minimum that would work. How could a manager serve the team so they can finish faster?
I still like measuring the features chart and the product backlog burnup chart. (See Velocity is Not Acceleration.) Managers might need to assess their WIP, as well as a project/program WIP. (See When Teams Don’t Finish Work in a Sprint: 3 Tips to Seeing and Finishing Work to see a cumulative flow chart.)
Rethinking Management Compensation
Many organizations reward managers by the scope of their control. We want to reward people and managers for the flow of work instead. How can we reconcile those two opposing forces?
I will freely admit I don’t have all the answers. I do have some ideas about principles. That means we have to change the reward system for managers early enough in an agile transformation to make it easy for the managers to succeed.
Let’s consider how to experiment without changing a manager’s title or compensation.
Some possibilities:
- Frame these changes as experiments and decide on a duration for the experiment. (I can change my behavior once. Making it a habit is much more difficult and requires more time.)
- Stabilize a manager’s expected compensation for several experiments. Consider looking at compensation as a combination of changing habits and experimentation/learning.
- Consider moving the reward system to one of serving teams so the teams can achieve their “best” throughput of finished features and the organization has its best throughput of releasable features or projects.
That means you have to change how you measure the managers, never mind the teams. It also means decentralizing “support services.”
A product line needs full product teams. It also needs its own HR, Finance, MarComm, and possibly other people, other than the product developers. If you have enough people, you can work in flow efficiency at all levels.
This is a non-trivial problem. We understand how agile approaches help teams work better. We don’t have enough ideas about how agile approaches help managers do their job better.
I’ll suggest some ideas in the next part.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Defining the Manager’s Role for a Product Approach, Part 3 Opinions expressed by Java Code Geeks contributors are their own. |
