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

This is a series of articles discussing models of organizations and mental models of its leaders that design such organizations.

The first two models were described in the 1st part of this article:

• (Simplified) Startup.
• (Centralized) IT development.

Further development and complications were discussed in the 2nd part:

• (Horizontal) Component development.
• (Overcomplicated) Project development.

Now we are to understand ways to actually start taking things in real (not illusionary) control:

• (Side) Satellite development.
• (Vertical) Product development.

(Side) Satellite development

Everything was good (for years) in terms of operational efficiency until competitors (damn them!) started to release those new modern "apps" and compete with us with new unprecedented business models.

This is an innovation crisis. As you know, the optimization of operational activities is contrary to the level of innovation, creativity, and freedom of creativity: more focus on predictability reduces the capability to innovate. See if you can agree with me here - striving for creativity is challenging if you have three levels of programs in a project portfolio with five-year budgeting cycles...

But then a garage-level-company of "two friends and a dog" enters the market and begins to gnaw off loyal customers from our stable business. What is really unclear is why are they leaving us? So what if there is an app, so what if mobile traffic in the country is now 70%, so what if everyone uses Netflix, Zoom, Airbnb, and Miro... Well, maybe there is something in these weird new business models?.. And then the first-minute doubt about the correctness and steadiness of the chosen development path creeps into the heads of the management (but the suddenly remembered amount of cash on the bank accounts and a number of the client emails in the database quickly relieves the uncomfortable tension).

"Well, OK. To change so to change - let's put together a team of 5 people, quickly release the app and forget it. By the way, in this case, we can add Scrum to the list of project management tools, our PMO has been talking about this for a long time. Let's Scrum! And yes, we will of course use our current "Redmine" project tool to reduce costs" - an internal dialogue in the head of the CIO).

This is how what I call satellite development is born. It's like product development, but not at all! This is a development of something on the side, and unfortunately, this something at first (and for a while) seems like a real product.

This is an attempt to escape from the inevitable transformation, an attempt to procrastinate. It is a pilot without the possibility of scaling and accordingly to learn something. Since it is one thing to write an app on the sidelines, and another is to transform your view and learn to look at your "core solution" as a product, and not as a set of software systems, services, and components... This is a wasted chance with good intentions.

Remember some pages up at the beginning of the article series (about 5-10 years ago in the life of the organization), when, being a startup, all its software was a product that solved all the business problems? It was maybe hard to say what it was - but it was one thing that was developed and run for the sake of the potential business opportunity...

That was not only forgotten but even people who remembered that were also forgotten. And the presence of engineering groups who individually own the "components", "systems" and "platforms" plus the fat layer of project mythology [my copyright here] does not allow looking at this whole thing as a product (or at least a family of products), not to mention finding the real owner of this product from the business side.

So the only possible experiment here really is to play on the sidelines with something new and in new ways ("oh sweet innovations!"), and the existing legacy, on which the operating business is based, shall continue to do as before (after all, it is already being done highly operationally efficiently). And it's just scary to break something that works!

But it is important to understand that the iOS App is not a product. Pause to think of this. It is a channel, an interface, an "additional keyboard" for the customer to access the value your business offers. This is not the product itself. This is essentially another frontend layer. Nothing more.

With all the seeming benefits of piloting a new app on the side without breaking the existing functioning organization, the company will just see how many dependencies such an app will have on its core systems. And later even more dependencies upon trying to reach the feature parity - requests for features that are in the old product, but they are not yet in the app, which breaks the user journey.

It should be worth noting that such Satellite Development is not a new model, it is still the same Project Development paradigm since for a project organization, writing an app is just another project. So do it is not to expect that in this approach the company will learn something radically new about itself, except perhaps how "everything is tightly connected and complicated", and that "we have not been even able to release a simple app for a year now!"

(Vertical) Product Development

A product is everything that an interface provides access to, plus the very same interface. And if the word product does not seem large enough or is overloaded in your industry with other definitions (for example, "banking product" is not what I mean), then you can try using the term "business product".

The choice between operational efficiency and innovation is what one calls a "false dichotomy" - it is a false choice. A healthy organization that understands the dynamism of the world needs both and at the same time. As you can't be successful long-term if you can't be keep innovating and at the same time you can't be successful long-term if you can't operationalize your innovations.

Remember above I wrote about a "seesaw" of organizations that are swinging from being a startup to wanting to be enterprise and back. Embracing product development is a turn towards the startup field - being adaptive, innovative and hungry for more cool stuff. With such an organizational design, each product vertical (and ideally there is only one for the entire corporation, since most of all business in fact have just one business line) is a startup in its essence - a product organization encapsulating all the functions required for success of a business case.

Transitioning to a vertical organization structure by building product (à la startup) groups within a corporation, in my experience, does not happen naturally or evolutionarily. A revolution is required that is driven by a reformer from within. This is a transformation of the organizational structure through rejection of everything unnecessary and wasteful that has been accumulated over the history of the company. It is simplification of the structures and processes. It is difficult, slow, thoughtful and expensive work. But at the same time, it can be done without any special risks and also gradually. For example, one recommended strategy is forming product groups one by one, gradually melting down the centralized IT department and forming new permanent cross-functional and cross-component teams with a business focus with volunteers - being who believe in success. [This is undoubtedly a topic for a separate article and this is what my colleagues and myself in Scrum Ukraine are getting our hands dirty with - helping to prepare and coaching product transformations of large organizations].

But only experienced consultants are not enough here - for such radical changes in the organization's structure, a managerial will is required. And a prerequisite to this is a desire to deeply understand the causes of excessive complexity and the reasons for aging and slowing down of the organization. According to my observations, 2% of organizations are capable of such feats. But, as Deming said, "You don't have to change. Survival is optional." The dinosaurs need to die out. I'm sorry.

But, if you are thinking about product development, then it is important to understand the entire palette of options and traps of thinking. Defining and dividing product verticals is a separate big topic, which also greatly influences future org design. The most common models are the following:

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

The next and final chapter of this series will explain these five options of (vertical) product slicing.