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

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 the article:

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

Now we are to understand further development that is likely as the organization keeps growing:

• (Horizontal) Component development.
• (Overcomplicated) Project development.
• (Side) Satellite development.
• (Vertical) Product development.

(Horizontal) Component Development

Component development - formation of functional engineering groups around technology layers (databases, backend systems, various layers of integrations, frontend channels).

With the growth of the IT department, it will eventually split into groups owning "their own" parts of the architectural layer (architectural segregation). In such a model correspondence between the "software component" and the "selected group of people" will become almost unambiguous. So, there will be a "core", "backend", "frontend" component with their corresponding specialist groups, as well as "test" and "operation" functional groups - all with their line managers.

So, we come to what is often called "component development" - this is a logical development of the previous model, which gets intensified and crystallized with the increase in the complexity of systems and the number of engineers. In this kind of organization, the design of the software system and the design of the organization itself become mirror images of each other. This phenomenon is sometimes called Conway's Law and works both ways, where one reinforces the other.

"Components" can be called differently in your domain - "platforms", "core layers", "data buses", "systems", "software complexes"... Yet they have the same essence. But no matter how they are called, they describe the architecture of the system, the internal properties of the product, but not the use of it by users. This is the techies' jargon and not the product/business one. That is why the involvement of business stakeholders in such organizational design is complicated as there is a certain mental barrier between the business needs (functionality for the client) and what engineers and their groups work with (architecture layers). "Why do I need to know about the bloody business needs, give us tasks for the backend!" - says a hypothetical programmer working full-time with the backend internals of the system.

This is how the split between the two worlds of business and IT intensifies, they begin to speak different languages and wield different metaphors. Remember the startup model above (in part one of this article) - then we all used to speak in one common language, how did it become that we so quickly forgot that we were able to communicate?

And now there are two ways to approach further organizational design - transition to product development through the transformation of teams (more on this below in the corresponding chapter of the article) or introduction of translators (through the adding layers of project managers, analysts, and architects)...

If you use the second approach: imagine that a business request for development comes, and you have 5 component groups, each of which owns its own part of the system. They all have to do something in the code to implement this business request. How to manage it? You obviously need a group of people who will be able to analyze and stratify a business request for engineering tasks, formulate and deliver them to performers. Then you need some people to regularly make sure that these works are being done, resolve conflicts and dependencies between them, and that "at the end" it works. Congratulations, you've just designed a more complex org system that lacks transparency, low adaptability, long queues, slow feedback loops, and with a different focus for different groups. This is getting even more difficult to manage.

But the important thing to note is this added complexity. It is not caused by the inherent complexity of digital development. It is caused by your org design decisions. It all could have been different if you hadn't started looking at your organization as a mirror of your IT systems and started building departments around the layers of the system. Now, what engineers are working on and what the business needs are orthogonal things. And that world cannot hold without translators, analysts, managers, pushers and controllers...

(Overcomplicated) Project Development

... because this complexity needs to be managed.

Despite the constant communication between parts of the organization and the scooping of water from holes (which is why such an organization is still afloat), business goals are being met in one way or another, the number of business stakeholders continues to grow, and the number of diverse requests, of course, also.

If earlier directors and line managers inside R&D managed to keep the offensive and dam of requests, now they are simply not able to cope with this anymore. By the way, everything is aggravated by the growth in the number of IT heads, there are already 70+ engineers in the company (and the level of the chaos of processes is growing exponentially) and the constant increase in the complexity of systems. Ironically, hiring is growing as compensation for low development performance, and the growth in development performance gets worse the more the IT department grows.

We see the next (second) management crisis - the difficulty of managing dependencies between parts of an organization and a process. Solutions? Project management and matrix structure!

The PMO gets institutionalized. And corresponding jargon gets introduced. Typically, the development processes are practically no different from the previous phase, except that the work is now clustered into fictitious entities called "projects", each of which is assigned a project pusher (project manager). But where the projects are pushed to remains unchanged - it is the IT department, the same as before, with all the same approaches and issues of release and neglected quality.

The number of projects is growing. In order to understand at least something, project projects are set up - "programs" and "project portfolios". Internal workflow and the level of hierarchical reporting are growing. Program and portfolio managers appear, respectively.

This is a mental add-on, overhead. And it doesn’t help business and development communicate more effectively. Despite all the redundant reporting, project management tools, reporting automation, and attempts to clean up the mess, the PMO is not becoming an effective communication interface between business and R&D. It is an outgrowth of an organization, an appendix, a world of illusion that dulls organizational pain. After all, you must admit that when there are projects there is a feeling of control.

On the good side, such a structure can withstand tens of hundreds of engineers (and even thousands), and unlike the previous two approaches (Startup and IT development), it is scalable, so the next crisis is very long to come...

So, unlike the previous stages of crises and the further development of companies, this stage is very stable and can last for years (in some cases, even decades) even if a company keeps growing. In particular, the stability of this phase of development is also associated with the lack of new views on organizational design at the highest level of management - everyone is familiar with project management even from the cradle, so everything that happens seems to be "common sense without alternatives". And the presence of such volumes as PMBOK and such stable organizations behind them as PMI gives confidence in the chosen path.

An example of companies that are at this level are businesses that need a significant amount of software (for example, banks, telecoms), but they have a utilitarian attitude towards software, it is not [yet] placed at the head of the business model [possibly due to the slowness of realizing the level of digitalization of the world by middle-aged managers] and is only needed as a service for solving business problems.

Stay tuned, as the next chapter will guide you through the rest of the models:

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