1. Shouldn't the organization chart be adapted to the talents of the senior leaders?

2. Should structure follow strategy, as has been suggested by some consultants?

3. Does structure differ by industry or functional area?

4. We've had good successes with small multi-disciplinary teams dedicated to clients; what's the downside of this?

5. Is there a trade-off between a client-centric and a technology/service/product-oriented structure?

6. To empower leaders and hold them accountable, don't they need to have all necessary resources under them?

7. What is a matrix organization, and what are its pros and cons?

8. What are the pros and cons of a plan-build-run structure?

9. Some consultants recommend a "bi-modal" (quick/slow) structure; what are the risks?

10. What are the risks of "holacracy" and "boundaryless organizations"?

11. What are the pros and cons of decentralization and a "federated" model?

12. Should boxes on the organization chart be defined in terms of their roles and responsibilities (or RACI)??

13. Why does teamwork have to be addressed as part of a restructuring process?

14. What are the basic steps in implementing a restructuring?

15. During a shared-services consolidation, how quickly will the savings accrue?

Suggest another question and get a personal response....

Shouldn't the organization chart be adapted to the talents of the senior leaders?

No!

Organizational structure is a science. There are clear principles for desiging an organization chart. When you violate these principles for the sake of a few personalities, the consequences will inevitably be reduced performance.

Furthermore, when you structure around personalities, you'll have to restructure every time anyone changes jobs. That's expensive, disruptive, and induces cynicism -- the "organization du jour."

If you don't restructure, you'll find it very hard to find the right person for a job carefully tailored to the talents and interests of the predecessor.

Another risk is that you'll find it hard to explain the logic behind your structure. Without understanding their group's mission, it's tough for staff to show initiative and behave as empowered entrepreneurs. They're more likely to be passive and wait for the boss to tell them what to do.

And if clients don't understand the logic of your structure, they'll be confused about where to go for what.

It's true that people have different talents. But you don't have to optimize the structure to fit those at the top. Instead, first define a structure based on principles, and then fit people into it based on their unique competencies and interests.

More on the science of structure....

Should structure follow strategy, as has been suggested by some consultants?

"Structure follows strategy" was first suggested by Alfred Chandler in 1962 -- at the tail-end of an era of steady economic growth following World War II. Back then, business strategies were relatively stable and long term.

Not anymore! Strategies are multi-faceted, and can (indeed, should) shift rapidly due to competitive threats, new business opportunities, a volatile economy, new regulations, technology innovations, changes in your customers' industries, etc.

It would be chaotic to continually restructure every time business strategies shifted. But if you don't, your organization may be ill suited to pursue tomorrow's strategies.

Perhaps worse, a structure designed around today's strategies may fail to discover tomorrow's strategies.

A well-designed structure continually generates its own business strategies. And it continually assesses its customers' strategies and identifies high-payoff opportunities for its products and services.

More on organizational agility....

Does structure differ by industry or functional area?

The labels change, and the content of the work changes. But people are people, and human nature doesn't change by industry or functional area.

Thus, the fundamental principles of structure apply to every organization, regardless of industry, functional area, or the people involved. Have a look at the Principles and ask yourself if any don't apply to you.

Overview of the seven Principles of structure....

And while they're called different things, the same Building Blocks of structure (the lines of business within organizations) are present in every industry and functional area.

Building Blocks applied to various industries and functional areas....

We've had experience applying the science of structure to entire companies as well as departments within enterprises. We've had experience in corporations, not-for-profits, higher education, and government (federal and local).

There's no single "right" structure for any industry or function. But the same principles, frameworks, and participative change process apply to all.

More on the science of structure....

We've had good successes with small multi-disciplinary teams dedicated to clients; what's the down-side of this?

Small client-dedicated groups are very similar to decentralization, so the consequences are very similar.

The success comes from three things:

• The customer-intimacy this improves relationships, and in some cases facilitates the discovery of high-value opportunities.

  However, it's not an effective substitute for a dedicated Account Sales (business relationship management) function assigned to each client.

• The client can control priorities within the bounds of finite resources (the dedicated headcount).

  However, this is not as effective as resource-governance processes that gives clients control of what they "buy" from anyone in the organization through a deliberate portfolio-management process.

• The dedication to specific clients induces greater customer focus among the staff.

  A more effective way to accomplish this is a culture of customer focus throughout the entire organization.

The most significant down-side is that a small, dedicated group cannot specialize to the same degree as shared centers of excellence. This defeats the very purpose of a shared-services organization. Generalists are less productive, produce lower quality, and are slower to innovate.

The benefits of specialization....

Furthermore, it scatters the "campus" of like specialists. This reduces professional exchange, risks overlaps and redundant work, and creates dis-synergies.

A better answer is a dedicated Account Sales function; a teamwork process that assembles the right team of specialists for each unique project; resource-governance processes that gives clients control over priorities; and a culture of customer focus throughout the organization.

More on the science of structure....

Is there a trade-off between a client-centric and a technology/service/product-oriented structure?

Problems occur when a single basis for substructure (be it client or anything else) is inappropriately applied to many of the functions in an organization. Where that's the wrong basis for sub-structure:

• Specialization (and hence performance) is reduced.

• There may be overlaps in the other dimensions, causing redundant work, loss of synergies due to dis-integrated products, and internal competition.

• Regardless of which approach you pick, synergies in the other dimensions evaporate. The experiences, methods, and work products developed in one group are rarely shared with other groups which might have similar needs. The result is costly reinvention.

• It also induces inappropriate biases. People naturally focus on the mission of their group instead of their professional specialty. For example, Engineers dedicated to clients will focus on knowing clients and doing whatever they need, rather than on specializing in a specific domain of engineering.

This is a false dilemma. There's no reason you can't have the benefits of each of these bases for substructure.

As per Principle 4, groups should be subdivided based on the nature of their expertise.

• Thus, the Account Sales (business relationship management) function should be subdivided by client (dedicated to specific clients).

• In parallel, Engineering groups should be subdivided by technologies.

• And Service Providers should be subdivided by type of service.

Once you sort out the lines of business within your organization, the right basis for substructure will be evident.

More on the science of structure....

To empower leaders and hold them accountable, don't they need to have all necessary resources under them?

This line of thinking leads to a "silo" structure made of self-sufficient groups containing all the specialties needed to do a specific job.

This is done in response to poor cross-boundary teamwork. But there are consequences:

• These small groups cannot specialize to the same degree as an organization made of well-focused centers of excellent. As a result, performance suffers in every way for lack of depth of skills.

• Any specialty needed by multiple groups is scattered among them. This "scattered campus" leads to redundant work, multiple parallel learning curves, and dis-synergies from multiple disparate solutions to the same challenges.

• No one group can afford to hire a specialist that's only needed part-time by multiple groups (such as an emerging technology). For lack of those skills in the organization, performance suffers and opportunities may be missed entirely.

In truth, you don't need to build silo structures to match authorities to accountabilities. Doing so is like saying that you need to own your own grocery store to control what you eat!

Just as managers have authority over vendors which don't report to them, they can manage team-members who report to other groups but are assigned to them. The antidote to silos is effective teamwork.

So, rather than build siloed groups, cluster specialists into centers of excellence that maximize specialization and professional synergies. Then, invest in the mechanisms of cross-boundary teamwork that draw together onto teams exactly the right mix of specialists from all over the organization to satisfy the needs of each unique project.

More on effective cross-boundary teamwork....

What is a matrix organization, and what are its pros and cons?

The term "matrix" has a specific meaning in the literature on organizations. Staff report to two managers:

• On one dimension of the matrix, they report to a profession manager who looks after their skills and methods. Essentially, this manager's job is to make available a pool qualified experts.

• On the other dimension, they report to a customer or business-program manager who manages their day-to-day work. This manager typically also serves as Account Sales (business relationship manager) to that customer.

The intent is to have the benefits of professional guidance and specialization, and also dedication to a customer or business program.

Matrix structure has worked adequately in stable industries such as aerospace where engineers are dedicated to a program (an airframe) for many years.

However, in more dynamic settings it breaks down. Here's why:

Ideally, whenever a program ends, the matrix should be restructured and people reassigned to new programs. But in organizations where projects come and go every day, this is infeasible. So the structure degenerates into small groups dedicated to a client (akin to decentralization).

Those groups may or may not have just the right mix of skills for that client's projects. Despite the profession dimension of the matrix, these people become generalists attempting to satisfy all the needs of their clients. Loss of specialization leads to lower performance.

On top of that, reporting to two bosses is confusing for staff and contentious for their managers.

The matrix organization confuses two very different concepts: "boss" and "customer."

A better answer is to have everybody reporting to a profession manager -- a center of excellence in their field. Then, teamwork processes can draw just the right mix of skills onto each unique project team.

More on teamwork processes....

And by the way, a dedicated Account Sales function is far more effective than the part-time attentions of managers who are also supervising people and projects.

More on the Account Sales function....

What are the pros and cons of a Plan-Build-Run structure?

This simplistic approach is often done in the hope that it will induce more innovation, since the Plan group is dedicated to thinking about the future.

In fact, it slows the pace of innovation. One small group of planners cannot keep up with innovations in every specialty nearly as well as if every group were responsible for innovation in its profession field. Essentially, the Plan group becomes a bottleneck for innovation.

There's also the risk that an "ivory tower" research and development group loses touch with the real needs of the business.

To the extent that the Plan group discovers innovations, there are costs in transferring their knowledge to the people doing the work in the Build group.

Perhaps the worst consequence is that the staff in the Build group are denied the opportunity to think about their own futures. With the fun part of their jobs taken away, they are disempowered and demotivated.

And with the learning component removed from their jobs, their skills become obsolete; their productivity and the quality of their work diminishes; and their sense of professionalism deteriorates into a production-line atmosphere.

Staff in the Build group blame the Plan group for their plight. Tensions develop even though collaboration is essential to this structure working.

A better answer: Every group needs to set aside some "unbillable" time for professional development, experimentation, and process improvements. This is a challenge for the resource-governance processes, not structure.

More on market-based resource-governance processes....

And to the extent that "planning" means understanding clients' requirements, this is a function of the Sales line of business. Note that this specialty is very different from Engineers who study emerging technologies.

More on the Sales line of business....

In a healthy organization, everybody both delivers today's work and thinks about the future, within their respective lines of business.

Some consultants recommend a "bi-modal" (quick/slow) structure; what are the risks?

In some functions like IT, there's a need for rapid response to urgent business challenges and short windows of opportunity. Other projects require a meticulous development method to produce complex, robust solutions.

As a result, different methods are needed. In IT, Agile methods produce quick results; traditional "waterfall" development methods handle large, complex projects better.

All that's true. But that doesn't mean that developers should be divided into groups based on methods -- a quick response group, and a slow but meticulous group.

That structural split has unfortunate consequences:

• Each specialty is divided between the two groups. This reduces specialization, and hence performance.

• With two groups working in the same domain (in IT, the same data objects), business synergies are lost and costs rise due to dis-integrated solutions.

• The Quick group may be prefered by clients, and get the more highly valued projects. "Two classes of citizenship" emerge, which is demotivational for the Slow group. The resulting tensions impede collaboration, although the Slow group may have knowledge the Quick group needs; and their solutions may need to be integrated.

• The two groups compete with one another, each offering a different approach to essentially the same business opportunities. This is exacerbated by fuzzy boundaries, such as an arbitrary threshhold of estimated project size (e.g., 1000 hours). Competition confuses clients and further undermines collaboration.

• Clients may want to do things quickly even though the resulting sacrifice in quality will be very costly over the life of the solution.

• Innovation in methods is less likely, since groups are dedicated to existing methods.

A better answer is to divide Engineers by their professional specialties, and then train them in multiple development methods so that they can handle both quick and slow projects.

More on the Engineers line of business....

This can be complemented by resource-governance processes that don't make the mistake of allocating all available resources to the big projects known at the beginning of the fiscal year. Financial planning (not structure) should reserve resources for quick-response opportunities that arise during the year.

More on market-based resource-governance processes....

What are the risks of "holacracy" and "boundaryless organizations"?

In response to unhealthy, bureaucratic organizations, some people have rejected the concept of organizational hierarchy altogether.

They experiment with allowing staff to pursue whatever interests they please. These may be called boundaryless, organic, or cellular organizations.

They may reject the authority of managers, and view all staff as free agents who can sign up for whatever projects they wish. This may be called Sociocracy or Holacracy.

The costs are significant:

• There's no guarantee that the organization will contain all the needed skills to address its mission.

• People may become generalists as they follow their interests into many different specialties. Performance throughout the organization suffers.

• Important projects may be abandoned because staff don't want to sign up for them.

• Complex projects that require a mixture of different specialties are difficult to address.

• It's difficult to assess and manage performance, and to reward exceptional performance.

• These approaches often come with their own form of bureaucracy. For example, Holacracy involves a very complex set of procedures, prescribed down to meeting agendas and decision algorithms, that consume up to one-third of staff's time.

In fact, hierarchy is a very good way to lay out a mosaic of the needed specialties. It's just not a good way to coordinate work.

So to get the best of both worlds, consider a traditional hierarchical organization chart that tells people what they're supposed to be good at, combined with flexible processes of cross-boundary teamwork.

More on effective cross-boundary teamwork....

What are the pros and cons of decentralization and a "federated" model?

Decentralization occurs for three major reasons:

1. Clients want to be able control priorities, which they can do when support staff report to them.

2. Strategic value depends on focusing on what's unique about clients (not what all clients have in common). A dedicated group knows clients well, and responds to their unique, mission-critical needs.

3. Clients want to be treated well, and past shared-services organizations may have treated them as supplicants (or even adversaries).

One problem that arises is a loss of coordination across a profession, leading to replication of efforts, disparate solutions that undermine enterprise synergies, and a lack of career paths.

Some have attempted to address these consequences with a "federated" model that expects centralized staff to coordinate the work of people who don't report to them. This is typically a frustrating endeavor, since people pay attention to their real boss, not a distant "dotted line" boss.

And it often leads to contention for control between decentralized and centralized managers.

Even if people are cooperative in a federated model, the more serious consequence remains: Each profession scattered among the decentralized groups loses its ability to specialize. Little pockets of generalists cannot perform nearly as well as teams of well-focused specialists. This is why decentralization drives costs up (often by as much as 50 percent) for a lower quality of service.

Also, note that decentralization is not scalable. If you decentralize to the business-unit level, then staff within departments will have all the same complaints. Decentralize down to the department level and groups within the departments will demand their own support staff. It's a slippery slope! While decentralization may appease senior business-unit leaders, it doesn't change the landscape for those at lower levels.

A better answer is a shared-services organization that earns clients' business by addressing the concerns that induce decentralization.

1. Clients should be given control of priorities through market-based resource-governance processes, not structure.
   More on market-based resource-governance processes....

2. The centralized organization needs an Account Sales (business relationship management) function to build healthy relationships, understand clients' unique missions and strategies, and methodically discover strategic opportunities.
   More on the Sales line of business....

3. The shared-services staff should adopt a culture of customer focus.
   More on culture....

Consolidation of shared services can lead to significant benefits to everyone, but only if the centralized organization has earned "market share" through relationships and performance.

More on the shared-services consolidation process....

Should boxes on the organization chart be defined in terms of their roles and responsibilities (or RACI)??

Traditional "roles and responsibilities" aren't the answer.

They blur accountabilities and authorities because they define people's tasks rather than outcomes (products and services). Defining roles and responsibilities (tasks) begs the question, who's accountable for results -- the organization's products and services?

Even the more sophisticated "RACI" framework focuses on tasks rather than results, and risks separating authorities from accountabilities.

The key to good boundaries is defining what people produce rather than what they do. This is fundamental to empowerment -- managing people by results, not dictating how they do their jobs.

Dividing up results is actually a lot easier than sorting tasks. The list of an organization's products and services is far shorter than all the tasks people do and roles they play. And by defining who produces what, you'll automatically know who does what.

More on clear boundaries (Principle 3: Precise Domains)....
Provocative essay: Roles and Responsibilities....

Why does teamwork have to be addressed as part of a restructuring process?

The word "structure" means two things:

• The organization chart which defines everybody's specialties (and the reporting hierarchy).

• Processes of teamwork which combine those specialists onto project and service-delivery teams.

There are two reasons why a restructuring process has to address both the organization chart and the cross-boundary teamwork processes:

1. When you change the organization chart, you inevitably change workflows. If these aren't deliberately reconstructed, the restructuring can lead to chaos (visible to staff and clients) and missed commitments. To get work done, staff may revert to prior patterns of work, despite what the new organization chart says; so the new structure may never work as intended.

2. Without excellent teamwork, specialization doesn't work. A well-designed organization chart gives staff a clear focus on a single line of business (their specialty). But without effective teamwork, they're forced to become self-sufficient "silos" of generalists, despite the organization chart. Put simply, you can't specialize if you can't team.

Thus, building effective cross-boundary teamwork is an essential part of a restructuring process.

More on effective cross-boundary teamwork....

What are the basic steps in implementing a restructuring?

An effective restructuring process must not only design a new organization chart (the boxes) and get the right talent in each new job. It must also address the processes of teamwork. (See the prior FAQ.)

Thus, the basic steps in a restructuring process are:

1. Design the new organization chart.

2. Appoint leaders to positions.

3. Craft clear boundaries (termed "domains") which ensure no gaps or overlaps, and build leaders' understanding of their jobs as lines of business.

4. Practice walk-throughs (workflows) so that the leaders understand how real work will get done in the new structure (before deploying it).

5. Roster all staff based on their skills and current workload.

6. Go live, which involves educating all staff in the new structure.

7. Follow a meticulous migration process to ensure no missed commitments, and no "dump and run." And at this step, make walk-throughs a routine part of the way the organization works.

Beyond that, the restructuring process must build staff's understanding of the new way of working. And it must "capture hearts and minds" to ensure support for the change.

To do this, a participative process is necessary. The leadership team should be engaged in the design and implementation process.

Some fear that participation will degenerate into "horse trading" and battles for territory. But the Principles and the framework of Building Blocks ensure a fact-based approach.

More on the steps in a restructuring process....

During a shared-services consolidation, how quickly will the savings accrue?

An effective consolidation process involves three distinct phases (C-I-O):

1. Consolidate: Staff are moved into the organization to give its leader legitimate authority to engage them in the process. But groups are left intact during this phase, doing what they always did for their customers. Don't break anything!

   Of course, just changing lines of reporting doesn't produce any savings.

2. Integrate: Incoming staff are moved into the appropriate groups (or in some cases, both sides design a new structure together).

   Even at this phase, staff go on doing what they've been doing for their traditional customers. So there are no real savings yet.

3. Optimize: Managers of the newly integrated groups harvest cost savings and synergies.

   This is when the savings and synergies are realized.

Any attempt to harvest savings sooner (before the real productivity gains have been realized) leads to an under-resourced function that delivers a lower quality of service; fails altogether at serving some customers; and antagonizes staff and chases away people with critical institutional knowledge.

More on an effective consolidation process....

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....