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.

implement by feature

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 chart—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:

4 Replies to “Designing an Organization for a Product Approach, Part 1”

  1. I believe there is a conflict between structuring an organization along feature/product lines and business domain lines. To be clear, domain driven organizational structure also suggests cross-functional teams. including front-end, back-end, QA engineers, designers as well as business experts. This is the main tenet of strategic domain driven design. However, a business domain is NOT a product. While there may be some cases when these two patterns are aligned, in most cases a product spans across multiple business domains. How is it possible to reconcile these two approaches?

    1. Thanks, good question. Your note about cross-functional teams is key. I have to admit, I’m trying to think of an example for a business domain that’s not a product. I’m stuck. Maybe you can give me an example.

      Here are some options:
      – Can you (whomever) create either a large team or a program (collection of projects) that solve the problems the business domains have?
      – Is it possible for the business domains to collaborate to define a product? (A product-based organization is not just for the people who create the solutions to the problems. It’s also for the people who have the problems.)
      – I’m going a little meta here: what is the ultimate business goal? How “high up” the organization do we need to go, to find a person with a problem to solve? That problem and solution is the “product.”

      Product-based organizations solve a problem for someone, where the product has an ongoing life, past this project. (I’m not sure if you saw Project Work vs. Product Work.) If the solution to a problem has a need past one project, it’s a product. If the solution is a one-time thing, it’s not. (Even for me, that’s pretty binary. I’ll have to think about that more!)

      If you do have an example to share, I’d love to hear it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.