How do we move from a project-based organization towards a product organization?
There are at least two systems of work we need to change:
- The management system and the culture of management
- How the teams work and their team culture.
I’m not sure it’s that simple to explain. There might be more systems I don’t see yet.
I’ve noticed these challenges in companies who want to move to a more product-oriented approach:
- The reward system rewards resource efficiency, not flow efficiency.
- The company has a lot of managers: people managers, project managers, technical leads, architects. All of these people tell the teams what to do.
- The company doesn’t have enough product people (product managers, product owners, people who can make decisions about what a team needs to deliver and in what order.
That looks like a big deal, right? It is. I think it’s similar to the Big Ball of Mud antipattern in software.
We need to change behaviors in teams and in managers. And, we need to start slow so we can help people experiment with new behaviors and habits. That way, people can learn early. (Forget this fail fast nonsense. No one likes to fail. We like to learn.)
Work Toward the Product Organization with Team Behaviors
I wonder if the first thing is to understand the essential complexity of our current system. If so, we can take a piece of work as an example. We write down a sticky with the name of that work on the right-hand side of the wall or board. Now, working from the right back to the left, we identify all the steps that created that work. See Unearthing Your Project’s Delays for a specific walkthrough of how to do this.
The manager’s first service step is to break the reliance on other teams to release.
If we get all the people in the room who contributed to that deliverable, they can rethink component teams for flow. They can see decision lag times. They can create the team(s) they need.
You might want to check out the Scaling series I wrote a while ago. It has more specifics for how to do this.
Offer Managers New Behaviors
How do we reduce management complexity? Reframe a manager’s role to that of stewarding/shepherding interpersonal skills in the teams, product business value, and continual learning through communities of practice. Managers move from “control” to “service.”
Managers (functional managers, project managers, Scrum Masters, you name it) can’t be responsible for the team’s results. The manager helps the team’s process. This is why the manager can’t be this team’s product owner (see Who Should be Your Product Owner?).
This means we must change the reward mechanism for managers. If we “hold managers to account” for deliverables, they will rarely take the long-term view.
When we change reward mechanisms for managers, they can collaborate with each other. When we change the career ladder, people who prefer a more technical role can do that and not lose money. When we explain we need more product ownership (and reward that role properly), people who are interested will move there.
Break the Centralization of Support Services
Here are questions I like to ask when people are thinking about moving to a product organization:
- How can we sell, produce, support the product?
- How can we hire, retain, integrate the people?
This is the essence:
How can we optimize everything we do for product orientation?
One of the answers is to break the centralization of functions.
If you review the product organization image (at the top of this post), you’ll see that a product organization has its own Customer Support, Sales, HR, Finance, Marketing functions in the product line. No one needs to go to another VP to fix problems.
I do think of these functions as supporting the product development activities. They are all still critically important. If we don’t have a product, we can’t sell it. If we don’t have salespeople (or whatever), it doesn’t matter what we build. It’s the same for all the other functions. We’re optimizing for the product that we sell, ship, and support for our customers.
Change the Measures
Too often, managers are measured by how well their teams meet a specific date. The problem is the dates are often arbitrary. The dates might have been set without thinking about Cost of Delay for the releases.
Instead, here are some possibly multi-dimension measurements that might help people think in flow efficiency:
- Cost of Delay for features, feature sets, projects. (Yes, we might still have projects in a product organization.) If we understand the Cost of Delay, we might not need dates for anything.
- Cycle time for features. If a team has a cycle time of more than a day for anything, that’s a symptom: too-large stories, messy code, insufficient tests, insufficient team members, etc. If managers help teams resolve this issue, the project lead time decreases and the customers receive product faster.
- Lead time for features, feature sets, projects. The longer the lead time, the more the organization is not working together. Either the managers added more stuff than the organization can reasonably achieve (too much WIP in planning), or the teams aren’t collaborating (for any number of reasons), or there are still problems with the code base, test base, cycle time, and more. This is where looking at the system of work can help.
I’m not sure that these are the only necessary measures. I worry that I don’t have something specific about quality in here. To me, that’s part of cycle time, but it’s not for everyone else. I also don’t have anything about accounting in here.
I’ll do a summary in the final post.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Possible Organization Changes for a Product Approach, Part 5 Opinions expressed by Java Code Geeks contributors are their own. |
