The design of organizational structure is a science, with firm principles and useful frameworks.

It's not a fundamental science like physics or mathematics. It's an applied science -- an engineering science.

And it's not an Empirical Science; it's a "Formal" Science.

• Empirical Science: Relies on observation, experimentation, and physical data to test hypotheses about the world (e.g., physics, biology, chemistry).

• Formal Science: Relies on a system of a priori reasoning, axioms, rules, and logical or conceptual analysis independent of physical experiments (e.g., mathematics, geometry, logic, and theoretical computer science).

The science of organizational design is based on the Formal Science of cybernetics (systems science), especially the work of Ross Ashby.

Most of the principles of organizational design are derived from Ashby’s Law of Requisite Variety -- a foundational principle of cybernetics and systems theory. It can be summarized by the phrase: "Only variety can destroy variety."

In simple terms, the Law of Requisite Variety says that for any system to remain stable or survive, its control mechanism must be just as complex as the environment it is trying to manage. If a situation has 10 different problems it can throw at you, you need a regulatory system capable of 10 different responses to keep things stable. If you only have 5 responses, the remaining 5 problems will cause the system to fail or go out of control.

In systems science, "variety" refers to the total number of possible states, moves, or changes a system or environment can experience. Mathematically, it is (COMPLEXITY * VOLUME / TIME). Variety increases when complexity is greater, volume is higher, or time frames are shorter (things move faster).

The challenge in organizational design is one of managing variety.

Organizations live in environments with unthinkable variety. The word "unthinkable" is carefully chosen, because the human mind can only process a finite amount of variety. We all have a limited number of "brain cycles" each day. We can only read so much in a day, remember so much, make so many decisions, take so many actions....

No one mind can possibly process enough variety to manage everything going on in even small organizations to navigate a world of volatility, uncertainty, complexity, and ambiguity (VUCA).

This is precisely why we form organizations. When people collaborate, their variety processing abilities are pooled together, and the organization can handle more variety.

What those minds use their variety-processing abilities for (their focus, or specialty), and how they collaborate, is determined by organizational design.

The Seven Principles of Organizational Design

In my studies, I've found seven fundamental Principles of organizational design:

Principle 1: Golden Rule: Authority and Accountability Must Match
Principle 2: Specialization and Teamwork
Principle 3: Precise Domains
Principle 4: Basis for Substructure
Principle 5: Avoid Conflicts of Interests
Principle 6: Cluster by Professional Synergies
Principle 7: Business Within a Business

The first four are derived directly from systems science. The next two are derived from logical analysis. Principle 7 is more complex, and is an empirical answer to many organizational challenges, in keeping with the first six Principles.

Consider the underpinings of each of the seven Principles....

Principle 1: Golden Rule: Authority and Accountability Must Match

In organizations, accountabilities are a feedback loop, a control, that ensures that one's authorities are used properly.

But what if one person has authority over, and a different person has accountability for, a given outcome?

Then the controls on the person with authorities are, at best, incomplete. That person with authorities, but not concomitant accountabilities, can misuse their power without consequences. In the extreme (to make the point), they become an unconstrained tyrant. They can make decisions, design processes, and dictate policies that harm others without concern for their impacts on the organization's performance. And furthermore, they lack the knowledge of the people actually doing the work when making such decisions.

Meanwhile, the person with accountabilities but not matching authorities becomes a victim of the first person's actions. They don't have the ability to get their job done. And they become a helpless scapegoat when they fail (perhaps due to the bad decisions made by the person with authorities).

As too many people have experienced in their careers, this cannot work.

As per the Law of Requisite Variety, for every person, the controls (accountabilities) must have as much variety as the discretion (authorities). Principle 1 states that authorities and accountabilities must always match.

Principle 2: Specialization and Teamwork

We combine people into organizations specifically to process more variety than any one person can alone.

If all those people are identical in their skills, forming an organization addresses the challenge of volume and speed, but not of complexity. This may be adequate if the organization is dedicated to very simple (low complexity) tasks, like picking up garbage alongside a road.

But most organizations encounter tremendous complexity -- in their products and services, their markets and competitors, the economic and regulatory environment, etc. To handle that complexity, people must specialize. By combining people with depth in all the needed specialties, the organization as a whole can handle greater complexity, as well as volume and speed.

Therefore, Principle 2 states that the more an organizational design permits specialization, the greater its potential performance in a VUCA world.

Sure, in small organizations, people cannot specialize to the same degree as those in larger organizations. But the Principle remains; good organizational design optimizes specialization.

Of course, specialization can only work if there is excellent collaboration across organizational boundaries. Otherwise, specialists who can't get help from other specialists will have to dabble in other people's fields of expertise to deliver their results. Obviously, organizational performance then suffers.

In practice, cross-boundary teamwork is the gating factor. Many organizations are not very good at it. So, they reduce specialization, giving up performance, to avoid the need for teamwork.

A classic example is decentralization. For example, when every business unit within a company has its own IT staff, then each of these IT groups must cover all the many specialties needed to deliver technologies. Each being smaller than what a centralized IT department would have been (one that pools all their people), they cannot specialize to the same degree. Performance suffers.

Why do business unit leaders advocate decentralization, despite its negative impact on performance. They say that it's needed because a corporate function won't understand their unique needs, forces "one size fits all" solutions, doesn't give them control of priorities (what they "buy" from an internal service provider), and treats them as unruly children to be controlled rather than important customers to be served.

But if these concerns can be addressed by a customer-focused centralized funtion (i.e., by great teamwork), then the enterprise can attain greater specialization, and hence higher performance.

Thus, Principle 2 also states that excellence in cross-boundary teamwork is necessary to optimize specialization. An organization design (sometimes call an "operating model") must build those high-performing teamwork processes before an organization chart that optimizes specialization can work.

Principle 3: Precise Domains

"Domains" are the boundaries within which a person or group operates. It's their specialty, their function, their scope, or their internal "line of business."

There are three components to Principle 3: domains must be clear, with no gaps and no overlaps.

Clarity: Defining a domain for a group takes more than a few words in a box on an organization chart. Those few words can be interpreted by different people in different ways, and can be used to justify a wide range of activities which may or may not have been intended to be within the scope of that group.

A domain is like a picture. The higher the resolution, the more information (variety) it conveys. Precise and clear domains are easier to understand, and more effective at guiding a group toward excellence in a specific specialty.

Thus, there's more to a domain than a few words in a box. The first component of Principle 3 states that a group's boundaries must be defined in precise language -- envision a paragraph or two that says, "This groups produces results which meet these criteria...."

No gaps: If any needed specialty is missing, people will have to fill that gap by acting outside their own specialty. Performance suffers.

The alternative is the organization scrambles to acquire a specialty when the need is discovered. This takes time. It takes time for a person within the organization to learn a new specialty. Alternatively, if external specialists are engaged but they are not managed by someone who knows that field of study (due to a missing domain), that outside specialist may not follow enterprise policies, or even act in the best interests of the organization.

The second component of Principle 3 states that every needed specialty -- those needed today as well as needs anticipated in the future -- must be assigned somewhere within an organization. Even if someone spends only a few hours a year monitoring an emerging specialty, studying it enough to inform the organization of its possibilities, and bringing in (and managing) in contractors and vendors when needed, someone needs to be accountable for every specialty.

No overlaps: If domains overlap, then more than one group is studying the overlapping specialty. If they divided that shared domain between them, then each could delve deeper (specialize to a greater degree). But overlaps, just like decentralization, reduce specialization and performance suffers.

And by the way, when domains overlap, internal groups compete with one another. The result is redundant efforts (higher costs) and incompatible results (loss of enterprise synergies). Plus, the culture is affected; if you pay people to fight, they fight!

The third component of Principle 3 is that domains must not overlap.

Principle 4: Basis for Substructure

What's the best way to divide a domain into sub-domains for the next level on an organization chart (the subordinates)? This is termed the "basis for subsructure."

If you chose the wrong basis for subsructure, then multiple sub-domains are asked to specialize in what that domain is supposed to be good at.

For example, a Sales function is supposed to be good at knowing customers and the value that an organization's products and services can bring to those customers.

If you subdivide Sales by product, then multiple sales representatives will call on the same customer (at least on those who might buy multiple products). Imagine two customers, and two sales representative representing two product lines. Each sales representative will have to call on both customers. So, each will have half as much time to spend with that customer. This undermines their mission of knowing and cultivating relationship with customers.

Furthermore, customers won't invite the sales representative into their planning in early stages (where every sales professional would love to be). Instead, the customers must figure out on their own which product line they need before knowing which sales representative to call. Again, this undermines the mission of Sales, which is to link customers' needs to any or all of the organization's products.

To make matter worse, those product-dedicated sales representatives cannot be truly business driven, suggesting whatever is needed based on a customer's strategies and operational imperatives. Instead, they are product driven, "solutions in search of a problem." This is a poor way of establishing a strategic partnership with the organization's customers.

Sales is supposed to be good at knowing customers. The right way to substructure Sales is by customer -- dividing the market into territories, such that each customer has one and only one sales representative dedicated to them.

Engineering, on the other hand, should be subdivided by product (and the components that go into products).

Principle 4 states that the basis for substructure should exactly match the specialty of the domain.

Principle 5: Avoid Conflicts of Interests

In all but the largest organizations, by necessity, many groups must cover more than one specialty.

Using IT as the example again, there hundreds (maybe thousands) of distinct specialties in the broad field of technology. And given that you don't want to be one-deep in any specialty, domains must be broadened to cover multiple detailed sub-specialties. As an example, an "AI Safety and Security" domain may have to cover the many sub-specialties within that mission.

So, in designing an organization chart, what do you combine with what?

The key is to avoid conflicts of interests.

For example, if you combine operations with engineering -- stability with innovation -- you have created a conflict of interests. The balance between stability and innovation will not be decided through the collaboration of two people representing those two points of view. Instead, it will be decided by the one person who manages both.

One individual may, by personal preference, stress operational stability. Another may love innovation. The balance will be non-determinant.

Even if you separate the two conflicting interests at the next level of the organization (the subordinate sub-domains), there's a problem with requisite variety in the leader of the two competing domains. No one person can be excellent at managing two very different specialties.

Furthermore, a job with conflicts of interests is extremely stressful. You can't win at both goals. This often results in job-related health issues such as burn-out, ulcers, or worse.

There are five fundamental conflicts of interests inherent in all businesses, and in businesses within a business:

• Invention (major innovations) versus operational stability

• Purpose-specific solutions (applications) versus the platforms or modules that contribute to various purposes (components)

• Enterprisewide thinking versus the focus of a specialist

• Technical/product specialization versus unbiased diagnosis of clients' needs

• Service orientation versus audit

Principle 5 states that specialties should be combined in a way that minimizes conflicts of interests. Of course, at the CEO level, the many conflicting interests necessarily meet. But from the next tier of leaders on down, organizations should be designed to minimize conflicts of interests.

Principle 6: Cluster by Professional Synergies

Beyond just avoiding conflicts of interests, what's the best way to cluster specialties together under a common leader?

First, note that the job of a manager is not to get people to work together on processes or projects. With the diversity of processes and projects in any organization, many requiring common specialists, no one person has requisite variety to be the coordinating mechanism. By the Law of Requisite Variety, coordination of teamwork must be systemic. (More on this in Principle 7.)

Free of this, leaders can instead focus on more important things like:

• Vision and strategies for their domain (and sub-domains)

• Talent, including inspiring, mentoring, and managing performance

• Professional excellence, with appropriate methods and tools, including collaboration with other similar specialists to facilitate organizational learning (e.g., sharing "tricks of the trade" and innovative discoveries)

These things require a deep understanding of the professions reporting to a leader.

The more similar the sub-specialties are, the less variety is required to lead them. And as a result, the leader will do a better job of leading.

Principle 6 states that you cluster similar specialists under a common leader to optimize professional synergies (not because they work together, which should be handled by the systemic teamwork process).

The benefits are many: Their common leader will be better at all three of the above focus items. Team members will be more likely to engage in professional exchange with related specialists. Career paths are improved in a larger organization with supervisory opportunities over related sub-domains. And domain gaps and overlaps can be adjudicated at a lower level (the common manager), rather having to rise to the top of the organization before all the pieces can be seen.

Principle 7: Business Within a Business

This final Principle refers to the nature of a domain. It is not itself derived directly from systems science, but rather is built on the compendium of the first six Principles.

Traditionally, domains (and job descriptions) are defined by roles in processes, responsibilities for tasks, and/or competencies.

As to roles in processes, any given specialty may support multiple processes -- both operational and innovation oriented. This approach is likely to lead to the scattering of a specialty across an organization -- essentially, decentralization. Per Principle 2, that will reduce specialization and performance.

Defining responsibilities for tasks generally produces ambiguous boundaries. Many specialties perform similar tasks, although the nature of their work and their deliverables are quite different. This results in domain overlaps. Per Principle 3, that too reduces specialization and performance. Additionally, we don't pay people to "go through the motions." We expect results.

And a structure based on competencies, while closer to the concept of a specialty, is also problematic. Many different specialties may be competent at things like managing projects and resources. Again, this leads to fuzzy boundaries and lost specialization.

Meanwhile, what's needed from any domain is results -- at two levels:

In the short term, results means delivering projects (products) and services with quality, at competitive costs.

In the long term, results means maintaining an internal capability over time through innovation and wise business strategies.

Of course, accountability for these two goals must not be separated, as per Principle 1. You can't have one person deciding another person's future.

Furthermore, with accountabilities comes authorities. Once desired results are agreed, people must have all the needed resources, information, and decision authorities (including deciding how they go about producing results). Nobody outside their domain (and their boss) should tell them how to do their job.

There is a compelling way to look at this combination of accountabilities and authorities: Consider every group a business within a business.

This is not a matter of financial transactions (groups charging one another). It's a way of thinking about jobs.

As an entrepreneur running a business within a business, you have defined your catalog of products and services (types of results). You view other groups in the organization as customers, and are in part measured on their satisfaction. Customers decide what they "buy" from you (within the bounds of available resources), but you're empowered to deliver your products and services in the best way you know how.

This paradigm also addresses the challenge of systemic cross-boundary teamwork (Principle 2, specialization with teamwork). For every initiative, there's only one group that delivers it (Principle 3, clear domains). That domain is fully accountable for the entire deliverable. That "prime contractor" can then "subcontract" with other domains for needed components and support services.

This way, cross-boundary teams form laterally (not up and down the hierarchy). They include just the right people, based on the unique needs of each initiative, because the prime contractor will naturally buy everything that's needed, and no more. And individual accountabilities of team members for those components and support services are clear, so that subcontractors can be empowered to deliver their products and services as they see fit (and to subcontract, in turn, to others for help if they wish to).

This dynamic approach to teamwork ensures that all domains aligned with the enterprise's key operational processes and strategic imperatives. It is a "customer-back," a "strategy-back," a "crisis-back," etc., organization.

Another powerful benefit of the business-within-a-business organization is that it gives everyone a sense of purpose. This is not just the purpose of the enterprise. Each domain has a its own unique purpose, using its unique talents to create value for others -- often people sitting across the hall from them (their internal customers).

The business-within-a-business paradigm is also the basis for a framework that (at a high level) defines all the types of businesses that exist in any organization, termed the "Building Blocks" of structure. The 7 Principles and these carefully defined constructs together add up to an engineering science.

Principle 7 states that every group (domain) should be defined by what it "sells," as a business within a business.

Organizational Structure Is a Science

There is no right "one-size-fits-all" organization chart. But these principles are firm. Compromising them invariably leads to reduced organizational performance.

As in any Formal Science, these Principles are based on reasoning, logic, and conceptual analysis. Experiments and hypothesis testing, the core of Empirical Sciences, are not needed for this Formal Science.

And while organizational design is not a fundamental science like mathematics or cybernetics, it's a science nonetheless — the science of engineering high-performing organizations.

This science is so mature that one can look at any organization chart and predict who's not achieving their objectives, who's fighting with whom, and who has ulcers!

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....