I’ve been thinking about my clients who’ve had success moving from a project-based/resource-efficiency organization to a product-based/flow efficiency organization. They had these things in common:
- A senior person made it safe for the managers to create experiments.
- They created very small experiments (either managers or teams, or together).
The senior manager often asked a question like this:
What do you need from me, to move to a product organization, where we optimize for the flow of product to the customers, and the satisfaction of the employees?
That’s a big question. It’s also an inviting question. This question states the desired outcome and doesn’t tell people how to do it.
That means there’s no recipe.
Three Options That Might Not Work for You
My clients have experimented with these options. I don’t know that any of them are right for you, but I offer these as possibilities.
Option 1: Start with measurements driving the changes.
One organization changed what they measured. The measured cycle time, lead time, employee satisfaction (was the work worth it), and customer satisfaction.
As they worked over the next six months (yes, this was not fast), some of the managers asked to become product owners and product managers. Some of the managers asked to be technical leads or architects. Some of the managers left.
They evolved their organization over time to achieve the results they wanted.
Option 2: Start with a reorganization.
In one organization, the managers went directly to the desired end state—a reorganization around the product.
The managers become a self-organizing management team—they reorganized to shepherd the business value of the product and to create a satisfactory environment for the people. Some of the managers chose (from Day 1) to move to various team positions, instead of managers.
The managers, as a team (up, down, sideways) changed the compensation system and what they measured. (Do not underestimate the value and difficulty of this step.)
At the same time, the managers asked the teams to reorganize to become feature-set teams. (The products were all larger than one team.)
They had about three months of total chaos, and then things settled out. When it came time for yearly review and compensation, they had a ton of trouble with the HR VP. The senior manager had to refight the fights. He succeeded because this product line made so much more money that HR acceded to their new ways of compensation.
Option 3: Start with the teams.
One senior manager, a product line manager, decided he would ask the teams to self-organize into feature sets. And, he asked them to choose their manager and product owner/product manager.
The teams were happy. Many managers felt as if their manager had abandoned them. On the other hand, the managers who hadn’t been servant leaders chose other roles fast.
The teams figured out what to do in the first few weeks. They settled into useful patterns of frequent delivery. The managers were in chaos for months, trying to understand how to help the organization. A number of the managers left.
The product line manager realized he had a too-flat organization. He asked the teams for help. They asked for two more managers and offered different dashboards.
The teams had little trouble with this transformation. The senior manager sees results he wants. And, he said, “I’m not sure why things work. I worry I don’t have enough insight. I never thought I could serve 100 people with just seven managers. But, each manager understands how things work. We’re okay for now. ”
Change Takes Time and Challenges Many of Us
Each organization lost some valuable people with valuable information.
When team members left, the teams discovered that they could refactor the code fairly quickly and understand the code better if they collaborated.
When one of the dev managers left (“I’m not a product owner. And, I’m not managing testers. I’m a dev manager”), the flow through the organization increased. Yes, some of the devs missed working with that dev manager. Yet, those people enjoyed their work more.
None of these options were easy for all the people in their organizations. That’s because change is personal, occurs at the pace each person can manage, and is not linear. (See Defining “Scaling” Agile, Part 6: Creating the Agile Organization for a fuller description of the Change Model.)
One organization tried Option 3 and the teams weren’t able to deliver on a regular basis. Their experiment was too big. It wasn’t safe-to-fail. That organization was bought out and by now, most of the people have left.
What Matters to Your Organization?
Becoming a product organization isn’t the goal. The goal is to create more business value, happier customers, and satisfied employees.
If the managers can work as a collaborative team, do you need to change where they sit? They may well need to change what they do, so the architecture doesn’t look like the management structure.
Here is a question that might help:
What is the smallest experiment you can do to gain knowledge and see what might work for you to work for product flow?
I had no idea this series would be this long.
All the posts in this series:
- Project Work vs. Product Work (I didn’t realize I’d started this series.)
- Product Orientation Requires Technical Excellence
- Designing an Organization for a Product Approach, Part 1
- Designing an Organization for a Product Approach, Part 2
- Defining the Manager’s Role for a Product Approach, Part 3
- Possible Changes for a Product Approach, Part 4
- Possible Organization Changes for a Product Approach, Part 5
- Starting a Product Organization Transformation, Part 6
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Starting a Product Organization Transformation, Part 6 Opinions expressed by Java Code Geeks contributors are their own. |
