Org Design Models, Part 2: Component & Project

Where we are in the series

This is a series of articles discussing models of organizations and the mental models of the leaders who design them. The first two models were described in Part 1 of this series:

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

Now we move on to the 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 — the 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 the correspondence between the "software component" and the "selected group of people" becomes almost unambiguous. So there will be a "core", "backend", and "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" — a logical extension 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 it 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 what they are called, they describe the architecture of the system, the internal properties of the product, not the use of it by users. This is the techies' jargon, not the product/business one. That is why the involvement of business stakeholders in such an organizational design is complicated: there is a certain mental barrier between 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 in Part 1? Back then we all used to speak in one common language — how did it become that we so quickly forgot 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 the introduction of "translators" by adding layers of project managers, analysts, and architects.

If you use the second approach: imagine a business request for development comes in, and you have five 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 do you manage it? You obviously need a group of people who can analyze and stratify the business request into engineering tasks, then formulate and deliver them to performers. Then you need some people to regularly make sure that this work is being done, to resolve conflicts and dependencies between groups, and to ensure that "at the end" it works.

Congratulations — you've just designed a more complex org system, one that lacks transparency, has low adaptability, long queues, slow feedback loops, and 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 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 hold the offensive and dam back the flood of requests, now they are simply not able to cope anymore. Everything is aggravated by the growth in the number of IT heads — there are already 70+ engineers in the company (and the level of process chaos is growing exponentially) and the constant increase in the complexity of systems. Ironically, hiring grows as compensation for low development performance, and 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 the process. Solutions? Project management and a matrix structure.

The PMO gets institutionalized. And the 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 keeps growing. In order to understand at least something, "projects of projects" are set up — "programs" and "project portfolios". Internal workflow and the level of hierarchical reporting grow. Program and portfolio managers appear, respectively.

This is a mental add-on, an 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 does not become 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 — 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. The stability of this phase 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: businesses that need a significant amount of software (banks, telecoms, for instance), but treat software utilitarianly — it is not yet placed at the head of the business model (possibly due to the slowness of middle-aged managers in realizing the level of digitalization of the world) and is only needed as a service for solving business problems.

What's next

We've covered four models so far:

• (Simplified) Startup.
• (Centralized) IT development.
• (Horizontal) Component development.
• (Overcomplicated) Project development.

In the next chapter we'll walk through the remaining two:

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