dot.research - 7 Patterns in large R&D Organizations

Large R&D organizations invest in frameworks, roles, and processes. And yet, some problems persist. Prioritization decisions are constantly being renegotiated. Risks are known, but no one takes ownership of them. Key personnel are chronically overburdened. What at first glance appears to be a leadership or methodological problem often has a structural cause, based on our observations. In this article, we describe seven patterns that we have repeatedly observed in large R&D organizations. We classify them, propose hypotheses about their causes, and invite you to view your own organization through this lens.

An observation that has been on our minds

In recent years, we have observed similar patterns in several R&D organizations. Similar roadblocks. Similar tensions. Similar dynamics - even though the companies come from different industries, are organized differently, and develop different products.

At the same time, we know of R&D organizations where these patterns occur rarely or not at all. Some of them are even exceptionally well-managed, measured precisely by the dimensions that become sources of friction in other organizations.

What distinguishes one group from the other? We don’t know for sure yet. We have hypotheses. And we have 7 patterns that we can describe.

This article is therefore not a model that claims to be exhaustive. It is an invitation to discussion - an invitation to view your own organization through this lens and to consider whether what we describe feels familiar in any way.

First: Why organizational size matters

To understand why these patterns can emerge, it helps to take a brief look at a model that David Berger described in detail in his post on the “power of five.”

The basic idea: As organizations grow, they change in leaps, not linearly. And these leaps follow a consistent logic.

In a 5^1 organization with up to five people, direct leadership is a given. Everyone knows everyone else. Ten interfaces are manageable. In a 5^3 organization with up to 125 people - roughly Dunbar’s number - people still know each other by name. But the shared view of the organization becomes selective: decisions are no longer visible to everyone, and context becomes increasingly localized. Incidentally, this is one of the reasons for joint planning and the joint resolution of dependencies, as we know it from PI Planning.

Starting at 625 people - a 5^4 organization - the whole becomes abstract. People reorganize themselves into smaller cells. Silos begin to form. The larger organization exists as an organizational chart, as a brand, as an idea - barely as a lived reality. A popular pseudo-solution is the matrix organization. It’s a pseudo-solution because it solves only part of the structural challenges.

For large R&D organizations, which typically operate between 5^4 and 5^6, this has far-reaching consequences. The organization is large enough that leadership through direct contact no longer works. And it is complex enough that structural gaps can remain invisible for a long time. Particularly in the matrix organization mentioned above, we often observe what is referred to as a shadow hierarchy or pseudo-leadership.

We doubt that size alone is sufficient to explain these patterns. More on that later.

What makes R&D Organizations unique

R&D organizations in regulated environments bear a specific structural burden. It is not just the well-known tension between stability and dynamism, but this combined with the context-specific requirements for sustainable documentation, traceable processes, high reproducibility, and all the other aspects that a regulated environment entails. R&D organizations are particularly caught in the following areas of tension:

Innovating and documenting. This is particularly evident in the challenge of how requirements are sustainably identified, documented, coordinated, and managed - especially when the classic V-model - which is indispensable in a regulated environment - is to be combined with agile methods.

Exploring uncharted territory and ensuring traceability. This is linked to the question of when, in the context of innovation, a seamless transition into an existing product family must be ensured, and where in the innovation process proper documentation begins.

Allowing teams to work amid uncertainty while simultaneously ensuring compliance. This raises the question of how to distribute responsibility for regulatory requirements: Should these responsibilities be role-specific, or can they be delegated to a team?

These areas of tension are not pathological. They are part of the context. But they tend to intensify invisibly when the organization is large enough that no one can see the big picture anymore, and when structural questions remain unanswered for a long time.

In such situations, we repeatedly observe certain patterns.

7 Patterns: Observations from practice

What follows are patterns drawn from several engagements in various R&D organizations. None of them necessarily occurs everywhere. And their presence alone does not explain why they arose. That is the real open question this article aims to explore.

The seven patterns can be divided into three groups: visible symptoms, reinforcing dynamics, and structural causes. This classification is a hypothesis, not a proven model.

Symptoms: What Becomes Visible

Pattern 1: Technical expertise without project logic

The technical level is high. Engineers, developers, and specialists know what they’re doing. In R&D organizations, you rarely - if ever - have to explain their jobs to these specialists. Structured project management, systematic risk management, and governance are absent as established practices. Projects run and are delivered. But the logic behind decision-making, how dependencies are managed, and the criteria used for prioritization remain implicit.

The organization relies on the expertise of individuals because a common structural foundation is lacking. This becomes truly apparent when attempts are made to move people from one project to the next. Without clarity in project management, without training and governance, different variations automatically emerge. Best practices, so to speak. And a person from Project A must first learn the terminology, processes, and procedures in Project B before they can perform effectively again.

Pattern 2: Risks are visible, but no one owns them

Risks are identified in retrospectives, project meetings, and informal conversations. “That could become a problem.” “If we go this way, we risk…” “We’ve known that for a while.”

The information circulates. When such risks are addressed directly, everyone agrees. They are rarely formalized, hardly ever assigned, and scarcely tracked. The information lives in the minds of those who had the conversation - until the risk materializes. Then everyone knows it was bound to happen.

In regulated environments, this is particularly problematic. The discrepancy between a known risk and a lack of ownership creates collective paralysis. Everyone knows about it. No one takes ownership of it.

Amplifiers: What keeps the symptoms alive

Pattern 3: Structural complexity is addressed with methods

When problems of a structural nature arise, the most common reaction is methodological. A new framework is introduced. Events are added. Roles are created. We’ve all been there - the successful implementation of SAFe in one’s own organization is well worth reflecting on again from this perspective.

It’s understandable that an organization would resort to such measures. Methods are visible, describable, and implementable. Such “changes” can be planned and implemented in a targeted manner. You can define deadlines and milestones, and - unlike with sustainable change - you get a sense of control. It’s controllable change, change that can be planned. However, sustainably changing structures - including people’s behavior - is a slow, politically charged, and often painful process.

Methods cannot address structural causes. A PI Planning process built on unclear ownership relationships reproduces this ambiguity in a structured format. In organizations that exhibit this pattern, the number of implemented methods is high. And yet, the feeling remains that something fundamental is wrong.

Pattern 4: Role overload and role ambiguity

New roles have been introduced. Old ones remain in place. Managers wear multiple hats at the same time, without any explicit decision ever having been made about which hats those are and what that entails.

This pattern multiplies very quickly, especially in matrix organizations. For example, in several of our engagements, we dealt with people who held up to seven roles simultaneously. In some cases, this went so far that a person would have had to hold regular meetings with themselves to negotiate decisions with themselves.

Key roles absorb structural tensions. They act as a buffer between the operational level, the strategic level, and the market. This works as long as the individuals in question have sufficient energy and a broad overview. When such individuals leave the organization, the informal system collapses along with them.

Pattern 5: Implicit control instead of decision-making logic

Decisions are made through personal networks. This is not done maliciously. A shared governance logic that functions transparently and reliably is lacking. Success goes to whoever has the right connections or happened to be in the right meeting at the time.

Pattern 5 is often closely linked to Pattern 4 - role overload and role ambiguity. Although new roles are introduced, formal power remains with the existing roles. “The old hierarchy still reigns,” the Head of Agile at an R&D organization explained to us. What results are decisions based not on data and expertise, but on position.

Formal structures exist. The actual decisions are made elsewhere. Everyone involved can sense this. Hardly anyone can point it out without coming across as political.

Structural Causes: What repeatedly gives rise to these patterns

Pattern 6: Competing logics without a common framework

Large R&D organizations operate simultaneously within three logics.

Market logic asks: What does the market want? Those who operate according to market logic are closely attuned to trend research, in tune with the pulse of the market, and directly engaged with the customer. Time-to-market is the driving force.

Product logic asks: What strengthens the product without destabilizing it? This is deeply connected to the question of budget. In a growing market, people are eager to invest; with older products, they consider whether further investments are still worthwhile. The lifecycle phase and product maturity are the drivers.

Platform logic asks: What can be changed, and how is that verified? Those who think according to platform logic protect the technical foundation. Variants are minimized, dependencies are documented, and changes are ensured to comply with regulations. Compliance and standardization are the drivers.

These three logics exist in parallel, especially with complex products. The problem arises when no explicit framework defines which logic applies when. Then roles and methods compensate for what is structurally lacking. The decision-making logic changes weekly, depending on who is feeling what kind of pressure at the moment.

In our observation, this is a common reason why prioritization remains chronically difficult in large R&D organizations.

Pattern 7: The Delivery Organization as a mirror image of the Line Organization

The undesirable opposite of a matrix organization. Projects are forced into existing structures. Collaboration models remain undefined. Departments are declared teams without creating the organizational prerequisites for teamwork. Leaders automatically become project managers. Team leaders automatically become product owners.

A department is a function focused on technical specialization and hierarchical control. This makes perfect sense. In this way, a department can practice highly targeted skill management internally without having to react to every change in projects. Strategic workforce management becomes possible within the department. A team - especially a project team - is a unit focused on joint delivery and shared responsibility. Ideally, we’re talking about cross-functional teams with T-shaped people. When a department is labeled “agile” without changing its structure, the result is a hybrid that combines the drawbacks of both worlds.

This pattern is particularly persistent because it requires structural investments that do not generate visible added value in the short term.

The real open question

Patterns 6 and 7 are our hypotheses regarding the structural causes. Patterns 1 through 5 are what become visible. Patterns 3 through 5 are what exacerbate the symptoms and keep them alive.

But we are aware that this classification is based on observations from a limited sample. It is entirely possible that there are other root-cause patterns we have not observed in certain client engagements - or additional amplifying factors. The model is open-ended.

What concerns us more is a different question. We know of R&D organizations where these patterns hardly ever occur. They are well-managed, deliver reliably, and have a clarity about their own structures that is lacking in other organizations. What do these organizations have in common?

We are currently focusing on five parameters that may have an influence.

Ownership structure. Publicly traded companies are subject to different management logics than owner-managed ones. The time horizon for decisions, the tolerance for structural investments without short-term returns, and management’s ability to bear long-term consequences - all of these could differ. Read more about this phenomenon in the article on finite games vs. infinite games.

Hierarchical complexity. Flat hierarchies create different dynamics than deep ones. But “flat” does not automatically mean “clear.” A flat hierarchy with unclear responsibilities can foster these patterns just as much as a deep one with unclear governance.

Strategic clarity. Organizations with a focused product strategy behave differently from those with a broad portfolio lacking an explicit prioritization logic. Market, product, and platform logic can be more clearly distinguished when the portfolio is manageable.

Organizational size. Size is a factor, but probably not a sufficient one. We have observed these patterns in very large organizations. Whether they emerge only above a certain threshold - and if so, at what threshold - remains an open question.

Governance and process maturity. Organizations with explicit decision-making logic, a clear division of roles, and well-established processes seem more resistant to these patterns. But here, too, it is unclear whether governance maturity is a cause or itself a symptom of a well-managed organization.

An invitation

We are sharing these observations because we believe that an outside perspective on one’s own structures can help provide clarity in areas where problems persist.

At the same time, we’re curious: Which of these patterns are familiar from your own organization? Which factors make a difference in your context? Are there patterns we haven’t described that, in your view, play the same role?

The question of why some R&D organizations remain clear and capable of delivering results despite their size, regulation, and complexity, while others remain chronically stuck in the same tensions, has no simple answer. But it deserves an honest discussion.