In Part 1, I suggested that when we organize by function, the recognition and rewards might prevent a successful agile transformation. In this part, I’ll discuss an option for a product-oriented organization.
Consider a Product-Oriented Organization
Instead of organizing by function, consider a product-oriented organization. Again, I am not saying this is the only way a product organization would look, but this is a possibility.
The senior manager has P&L (Profit and Loss) responsibility for the entire product line, including Product Management (for this product line), Customer Support, Training, etc.
Why? So that the senior manager can decide on the mix of products and services as a product line. Should the senior manager work across the organization to manage the organization’s project portfolio? Of course. However, note that this organization (via the middle managers) can manage its own project portfolio because the organization has everyone it needs.
Notice that each team has all the skills and capabilities it needs. That includes product ownership.
Not only does each team have all the skills and capabilities it needs, but the product line has all the skills and capabilities it needs to manage the culture. Note that Marketing, Finance, HR, are all part of this product line. There might be a “centralized” function for these groups, but all the people developing and supporting this product are in the product line.
How Many Managers Do You Need?
If the middle managers can serve just one team, they might not need another layer between the people doing the work and the senior manager. It depends on how many feature sets and product teams the manager serves.
In my experience, functional management requires more managers. That’s because the functional managers have to assign people to teams. If the manager doesn’t have enough people, the manager is supposed to “split” the person in some way.
Product lines use flow efficiency thinking. With product lines, it’s much easier to see when you don’t have enough people. What do you do? You decide how to manage the risks of the team not having the capabilities and skills it needs. You might hire. The team might work differently. You might stop work on that or a different feature set for now, until you can create a full team.
You don’t fool yourself into thinking you can do “more with less.” That’s never been true and I don’t know that it ever can be true.
I’ll talk about what people can do in a later part if they are no longer functional managers. (I’m still drafting, so I’m not committing to which part!)
How Do Your Managers Serve the People and the Products?
I am using the word serve as in servant leadership. I have found agile managers can succeed when they ask questions such as these:
- How can I make it easier for the people to do the right thing?
- How can I make it easier to deliver high-quality product faster?
You might need more questions.
I was in this position years ago. I was a Director. I didn’t know anything about agile approaches then. Instead, the projects used a staged-delivery life cycle, an incremental approach with cross-functional teams and monthly demos. (Not quite an agile approach, but much closer than waterfall.)
I wanted to make it easy for people to do the right things, as in the rank of the work and the technical excellence needed for the work.
The only reason I had P&L responsibility for a given product line was that the company wanted to phase out this product line and replace it with a different set of products. I was supposed to manage this sunset gracefully as the new product line ramped up.
That was fine. We all knew what we had to do.
Except, the new development was delayed. I was no longer supposed to ramp down. Instead, I was supposed to be in a holding pattern.
The problem with holding patterns is that they don’t hold. If you don’t improve your product, your customers start to wait for the new product, and they don’t buy more of the old one. If you do improve your product with new releases, you can continue with sales and increase support contracts. In project portfolio terms, these are the “continue with current direction” projects.
We didn’t set the world on fire. We were still working on older products that only had several years of life remaining. However, I noticed our throughput was much higher than when we’d had the more typical functional organization.
We all had the same goal: make this product line successful. We had all the people we needed. And, we had Marketing and Customer Support people close to us. (Customer Support was not collocated, but they had an affinity with us. We were one large “team,” working together for the good of the products.)
We released several small new products over the next year. We increased the percentage of customer support contracts and dramatically increased revenue from new products and support. Our customers were thrilled. We had a 25% increase in revenue over the previous year.
How? We managed the project portfolio so we had small projects that we could complete and move to the next one.
We worked by feature with teams who had worked together to learn the internals of their feature sets. Every so often—when our ranking changed—a team moved as a team to help out another project.
We integrated customer support into our demos, so they understood what their challenges would be when we released. We weren’t perfect. We were pretty good.
The new-product people were stuck. Even though they only had 3 teams, they all reported into different managers. They did not have one goal as a product development organization. The middle managers and senior technical staff couldn’t agree on an architecture for the product. Because the people weren’t working by features sets, they didn’t finish anything. It was a disaster.
Recognition and Rewards Didn’t Help the Situation
I did a “bad” thing: I increased revenue on a product line we were supposed to sunset. I didn’t do this alone. My entire product line succeeded because we had everyone we needed and no barriers to working together. We had a clear goal. We had teams who took responsibility for their work. And, we didn’t have too many managers with different agendas.
My colleagues on the new product line? They didn’t have our advantages of flow efficiency. Their problems were quite difficult. And, they had a lot of managers for the number of technical people.
Why was I “bad”? Because I “showed up” the other managers. I discussed this with my manager: didn’t he want the revenue? Well, yes. But not at the risk of other people’s egos. My company had baked resource-efficiency thinking into recognition and rewards.
I’ll talk about how you might start with a product-line approach in part 3. And, if you’ve seen other organizing principles that have worked for you, let me know.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Designing an Organization for a Product Approach, Part 2 Opinions expressed by Java Code Geeks contributors are their own. |
