Designing an Organization for a Product Approach, Part 1

If you're thinking about an Agile transformation, you already know about feature teams. You might even call them/use them as product teams. You might wonder about organizing all the work as product work.

See Your Current Organization

Many organizations use functions to organize people. The "Typical Product Development Organization" shows the kind of organization I see most often. That's why I called it "typical."

There is a senior functional manager, where the function is Engineering or IT or some name like that. In this image, that's the VP/CIO/CTO.

The middle managers — the directors — often reflect layers in the architecture. I added my "implement by feature" image in a 3-tier architecture to the left. The various development directors correspond to the various horizontal layers in the product.

Each of the directors might have several managers and team members "beneath" them. (Yes, the people are literally underneath their names on the org chart. That's one way that our words reflect our culture.)

If you look back up at the typical org chart, there's a QA Director and TechPubs. Maybe you have a Database Director, too.

Here's the interesting part:

Every architectural layer has a middle manager who reports to the senior manager.

When we design organizations around architectural layers, we invite Conway's Law into the work.

Note that the product management and customer support folks have no representation here. Neither do Finance or HR, or other "Admin" functions. That's a relic of how we centralize "support" functions and report profit and loss to the outside world.

Except, in an Agile approach, product management (often via Product Owners) is an integral part of a high-performing Agile team. And, great Agile teams often have HR support near the team, if not part of the team.

"Typical" Organizations Don't Support an Agile Transformation

Can people in a "typical" organization make an Agile approach work for projects? Of course. They matrix people into teams. With any luck, those teams are long-lived, as I suggested in Project Work vs. Product Work.

Can they create an Agile transformation?

Maybe. The organization of the people doesn't create an environment that supports an Agile culture.

I see these problems:

• The middle managers' incentives and the entire way the organization manages career ladders and performance is inverse to what an Agile transformation demands.
• Product Management is not integrated into Product Development.

A "typical" organization uses the ideas of resource efficiency instead of flow efficiency to build the organization. In a real sense, the org char — how the people are organized — works against the goals of a possible Agile transformation. (And, we have Conway's Law, depending on the number of managers.)

We ask the people to collaborate and deliver. The teams can succeed using Agile approaches. Rarely does the transformation succeed because we haven't change the culture, specifically, what we reward.

In my experience, unless you change the rewards and recognition system, you can't have an Agile transformation.

You might get Agile projects and programs. You won't get an Agile culture. (See my "Scaling" Agile series.)

The problem is this: if you want an Agile transformation, you need to change the culture.

What if we designed the organization for fast creation and delivery of products? See Part 2.

All the posts in this series: