Organizational design models in the evolution of managerial thinking (final part 4)

The previous part of the article series concluded that if the choice of organizational design is product-centric, then there are at least 5 sub-models at your choice which you can use to approach "slicing" your product organization:

1. Functional slicing
2. Sales funnel slicing
3. Cutting along business lines
4. One business = one product
5. Adaptive product areas

One word of caution - if you can avoid slicing altogether - you're the winner. Nothing beats adaptability of a product company that is guided by just one (overall) Product Backlog. In such an 180-degree organization a change of business strategy is just a reprioritization exercise on the Product Backlog. Can you imagine that level of agility?

But if you believe you're too big, and you need to "divide and concur", then the described 5 models are at your disposal (not of them though are leading to the same level of adaptability, so read on to learn the details).

Organizational Design Options in (Vertical) Product Development

Functional slicing

Does the product have one feature related to payments, another with messaging functions between users, and a third with exporting complex data into some sort of reports? You can fall for the "feature equals products" bait and build a product organization of three teams, each of which deals with its own features. And many companies do - because it looks simple.

Most often, in such an org design, each team is assigned its own "product owner" (I write in quotes and with lowercase - read on to understand why), which each have their own "backlog" (also in quotes and in lowercase) and control development priorities within their feature -areas. In total, we have three product owners and three backlogs in a blueprint of such an organization.

The advantages of such a system are the strong focus of the teams. And no one has ever been fired in the history of IT for introducing more focus. Everyone seems to love that. Here the teams have a focus on functionality and code behavior as likely different teams will be working on different codebase pieces.

Disadvantages are hard to spot from first sight. But they have long-term consequences on the organizational ability to learn and adapt:

1) low adaptability towards changes of org strategy and/or market needs;

2) local optimizations happening at the team level.

Let me introduce this with an extreme example. Imagine that from the next quarter, the company's strategy changes significantly and the features of complex data export, which are gradually growing into a complex user's workflow, become 10 times more important than all other product features altogether. That is, each item of the "workflow backlog" (even the lowest ones) is more important than the topmost item of other "backlogs". Yet every PO continues to massage her own "backlog" and feed their team from it. So each backlog is optimized but locally.

If we'd only had the single common true Product Backlog for all (here with a capital letter and without quotes), then it would have become transparent what's important and what's not so. But there is no such thing as a Product Backlog, but instead, such a company lives in the area of feudalism and internecine wars for their small land plots.

How adaptive is such a company? Will the "product owner" of the "messaging product" give her team to the "workflow product owner"? That a rhetorical question.

In my experience - no way she would do it. The thirst for status, the fear of losing a job, the ability to invent features, and politics playing skills - all of this will work contrary to the common sense, which shouts: "everyone should work on the workflow and nothing else!" So nothing will change and the company will be slowly doing what is so important, while simultaneously spending resources on what is not important at all. That drastically reduces adaptability. Yet increases the local focus.

Can we stop choosing and strive for the focus AND adaptability?

Sales funnel slicing

If feature-based slicing does not stand up to serious criticism, then conversion-based slicing is more difficult to dispute, it sounds serious and business-like. No one has been fired for trying to optimize the sales funnel (or doing some good lip service to it)!

Imagine a company has come up with a three-part funnel: one focuses on converting guests into leads, the second part is for leads-to-payers conversion, and the third one is for returning users and repetitive sales.

"Let's divide our product organization into three verticals", - oh, that sounds reasonable.

"How about growth hacking then? All competitors have one.", - ask someone who is rather fashionable.

"Oh, let's add a fourth stream then. It will be more adaptive and more flexible. They could use Kanban too."

(Noticed how we've now switched the discussion to operate in streams of work, rather than customer value? That is so common.)

If we ignore the Growth-thing for a moment, the problem with such a funnel-cutting is that the optimization of one conversion (for example, guests-to-leads) can potentially have a negative effect on the next one. How come? I've seen companies buying customer email databases or partnering with other resources, generating many fake leads that were never destined to become paying users. You can be creative here! That's probably an advantage of such org design - it promotes creativity.

But creativity, as well as focus, are only good if applied to value creation. (C) I guess me.

So here we too can easily fall for the trap of fast local optimization. After all, in fact, intermediate (partial) conversion rates are only good for analyzing conversion losses. Yet in order to optimize business income, one needs to look and work across the entire value chain.

Again, in different periods of a product's life, different funnels may have different development priorities. And here we are no more flexible than when slicing by functionality. So adaptability here is too very low.

Cutting along business lines

Now, this is more interesting. The business lines are not fictional entities. They are hard-coded in the P&L. So we're dealing here with real stuff that can (and shall be) optimized.

In Russian, we have a saying: "the one who pays bills, calls the tunes". So business lines (however you define them) are legible entities to get to decide on development investments.

An example of organizations where this fits perfectly into their modus operandi is service organizations, like banks. Here, for example, the credit-and-risk department can quite legally be developing a custom IT solution for its needs, it is an internal product. The question of leadership can also be managed here quite reasonably, as each department has its head.

The bottleneck of such a design will be the eternal questions, such as "who is responsible for shared libraries and common infrastructure?.." So establishing a separate horizontal entity, such as a "platform or a "core" team, is not as rare as we would like to see.

Sigh... While those centralized components will be the source of many incoming dependencies. Hence, one could decide for its own "platform backlog" with a "platform product owner" (noted the quotes and lowercase here?).

What considerations would this so-called "product owner" take when prioritizing her backlog? ROI? No. Business needs? No. She doesn't operate with those terms. She will be prioritizing based on internal yet understood things, for example, the availability of a back-end Java developer. That guy will pull all the 'ready' Java tasks into his dashboard to focus on in the next month (have we discussed the evil side of focus yet?)

Sadly, a business-oriented org design, that we've started with, has been now totally undermined and compromised. In the end, the louder-screaming business owner will be getting her things faster. Yet we say a 'sound org design' we mean something different.

One business = one product

This list of produce slicing models that we're going through is ordered by decreasing usage frequency. That is, the lion's share of the cases that you are likely to see are already described above. And they are full of flaws if you've been following my analysis.

It's a pity since this option "one business = one product" is devoid of the above-mentioned disadvantages of local optimization traps and low adaptability. In this regard, everything is very good here - there is one common Product Backlog for the entire organization, and it is controlled by one powerful Product Owner.

Criticism of this approach often rests against the lack of understanding of its implementation - how can one Product Owner work with all the development teams that are in the organization? Can she be driving dozens of developers at the same time? How does the process look like? How do you manage the staff, workload, teams, processes?

The answer here is yes! This can be learned. It is not simple, but it can be mastered. And you likely need mega-experienced process experts, AKA facilitators and Scrum Masters who are real Scrum and Large-Scale Scrum practitioners. Fortunately, all the information is open, described in books and case studies of real companies that work this way.

And you can do it too.. unless you have reached the limit of mental overload of the Product Owner (that is at around 7-10 teams).

Dynamic product areas

This is an extension of the previous case, only you have dozens of teams. In this case, whether you like it or not, you have to chop the ideal "one business = one product" idea into subproducts, or what we sometimes call "product areas". And, obviously, it is important to do this without falling into the traps of the "slicing by functionality", "sales funnel" or "business lines" described above.

But how? Dynamic product areas are here to solve this dilemma for you. Yes, people need focus and some more or less unchanging domain area - so that the engineers become experts in it. Therefore, product areas can be seen as boundaries of various sets of domain knowledge within your business. For example, working with large clients differs so much from working with smaller ones that it takes months for engineers to enter this domain. Then, naturally, we want those who already figured it out to stay in this area (at least for a while), developing the product for the benefit of these users. But this is not to be confused with a business line approach described above. This is all - one business, we just cannot know everything, and entering a domain requires investment, so we're creating these domain knowledge pockets to ease the pain of needing to learning too much to be minimally productive. It is a healthy balance between the need for learning and being highly productive.

Importantly, there is still the single common Product Backlog guiding all the areas and all the teams. But its items have different domain colors, and some teams are comfortable with only a few colors. The presence of the single common Product Backlog keeps adaptability high at all times. The world is changing, so is the product strategy as the product must adapt to reality. How does this organization cope with this? Dynamic domain areas can grow, shrink (meaning teams can switch between them), and got their goals adjusted - that increases the instance need for learning. That later will result in the ability to deliver more value.

Then we get a pure adaptive organization that constantly learns to seek and deliver customer value. At the same time, it has a clear structure and does not need transformations and reorganizations to change the course - the change of the strategy is made by the Product Owner constantly as the elements of a single common Product Backlog get reprioritized.

Sounds like a phantasmagoria or maybe, like a path of development?

Summary

We looked at six completely different org design models. We walked through a modern history of a company and observed in time how structures, processes, and managerial thinking typically develop.

It is worth noting that there is always some kind of org design. But it is not always thoughtful of and does not always have the right fit to the needs of the business. So the essential task of management, as I see it, is to form meaningful structures and processes, regularly review them, watching and noticing growth crises.

It is also important not to be led by fashion and "management schools", but to look critically at the current org design and radically revise it as the company grows, exploring alternatives and experimenting.

And without the involvement of employees who understand the real problems on the ground, and without the managers deepening into the realities of the company (practice "Go See", Gemba), meaningful org design is impossible.

---

Big thanks to Yaroslav Novoselov and Dmitry Nezabytovsky for helping to improve this article.