You Can Remove the Role. You Can't Remove the Responsibility.

Why organizational simplification sometimes just moves complexity around

When an organization is under pressure, questions naturally arise about which roles are actually needed. Can the team operate without a dedicated team lead? Can developers take more responsibility for architecture? Do we need dedicated roles for security or testing? Could someone else simply take on those tasks?

These are good questions. Roles should be challenged, and organizations should not preserve structures simply because they have always been there.

The problem begins when we confuse removing a role with removing the responsibility that role exists to carry.

A person can leave. A position can be removed. A role can be distributed across several people. But if the underlying need still exists, someone still has to do the work.

In that case, we have not necessarily removed complexity. We have moved it.

Being Able to Do the Task Is Not the Same as Carrying the Responsibility

Architecture is a good example.

Many experienced developers can produce a good solution design. But Solution Architecture is not primarily about being able to draw a solution. An experienced Solution Architect needs to understand how that solution fits into the wider context, what it depends on, and what consequences the choices may have for data, security, integrations and other parts of the system landscape.

The value therefore lies not only in being able to create the solution, but in being able to understand its consequences. That requires knowledge, but also experience.

The same distinction exists between a Solution Architect and a Lead Architect.

A Lead Architect is not simply a more senior Solution Architect. The system boundary changes.

Where the Solution Architect sees the solution in the context of the wider system landscape, the Lead Architect sees the entire product area as the system. Technology and architecture are still part of the picture, but so are strategy, products, roadmaps, organizational design, governance, principles and external dependencies.

A decision that looks right within the boundaries of one solution may therefore be wrong when viewed in the context of the product area as a whole.

But the principle extends far beyond architecture:

Being able to perform a task is not necessarily the same as being able to carry the responsibility.

Where Did the Responsibility Go?

When we move a responsibility to someone else, we often ask:

Can this person do it?

But there is another question that is at least as important:

What will this person stop doing?

Capacity does not increase simply because another role disappears.

When new responsibilities are assigned to people who already have other responsibilities, prioritization will happen. Architecture may receive less attention. Strategic work may lose out to operational needs. Testing or documentation may be postponed. Coordination may only happen once something has already become a problem.

Nobody necessarily decided that any of these things should happen. They become consequences of another decision.

The organization may therefore look simpler on the organizational chart while the complexity has merely become less visible.

The Decision We Never Made

This is where the issue becomes interesting from a Decision Architecture perspective.

Imagine removing a role related to architecture, security or quality. Nobody has necessarily decided that architecture, security or quality should matter less. The expectation is simply that the responsibility will be picked up by someone else.

Some of it probably will be. Some of it may receive less attention. Some of it may eventually stop happening altogether.

The visible decision was to remove the role.

But hidden inside that decision are several other questions: Who owns the responsibility now? How much capacity should be spent on it? What should the new owner deprioritize? And what risk are we willing to accept?

If we never answer those questions, we have made a decision about organizational structure without really making the decisions about its consequences.

It is a variation of what I call The Decision That Was Never Made.

The organization never decided that a responsibility should disappear. It simply stopped creating the conditions necessary for someone to carry it.

Simplification Must Be Real

This is not an argument for more roles.

On the contrary, roles should be removable, responsibilities should be distributable, and product teams should be able to gain greater autonomy. Sometimes a need really has disappeared. In other cases, competence has become distributed enough that a specialist role is no longer necessary.

But then we should be able to explain what has actually become simpler.

If the responsibility, workload, dependencies and decisions still exist, we have not necessarily reduced complexity. We may simply have moved it.

That is why "Do we still need this role?" is often the wrong place to start.

A better question is:

Do we still need the responsibility this role represents?

If the answer is no, we can remove it deliberately.

If the answer is yes, we need to decide who should own it, what competence and capacity it requires, and what may need to be deprioritized as a consequence.

Responsibility should move through a decision, not as an unintended consequence of another decision.

Otherwise, we may end up removing a box from the organizational chart without removing any of the complexity.

And then we may simply have created another Decision That Was Never Made.