Bureaucracy & Organizational Politics

Emergent Characteristics of Structure

It has been said that, "Organizations are perfectly designed and operated to produce the results they get." Yet, do they get the results they want? Not usually! Have you, as I, puzzled over this to the point utter frustration, without feeling that you had found an appropriate understanding? The following represents a developing set of thoughts as to why organizational design implies the results the organization gets, along with some thoughts regarding alternatives. This article is somewhat an outgrowth of ideas initially developed in Leadership and Management: A Structural Perspective.

Is organizational design limited to traditional thoughts about hierarchy and reporting relationships, or does it encompass more, much more? Are not the organization's policies, procedures, incentives, rewards, goals, management assumptions, conclusions, beliefs, and actions all part of what influences the activities of an organization? Is not the trust employees have for those they work for, how they feel about their work, and how they feel about each other part of the structure of the organization? A structure which has an affect on how things are done, and what is accomplished.

Buckminster Fuller said that rather than attempting to teach people the right things to do, one should design organizations such that doing the right things was simply the path of least resistance. When all the relevant elements of organizational design are considered this seems an appropriate perspective.

Is it the management of an organization which is most desired, or is it the production of results? Traditionally organizations have been designed in a hierarchical fashion because they are easier to manage, or so it is most commonly believed. Suppose the hierarchical structure makes an organization neither easier to manage, nor more results oriented. How would we know? Suppose one could design an organization that was essentially self-managing. Probably a heretical thought from management's perspective, for then what would be management's purpose.

In response to this question, consider for a moment, a ship, if you will, and ask which function aboard the ship is the most important? Is it the Captain, who is responsible for running the ship? Is it the Navigator, who is responsible for plotting the course? Is it the Engineer, who is responsible for ensuring that the ship has the power to follow its course? Or is it none of these? Who really has the greatest influence over the operation of the ship? Is it not the designer who initially designs the ship to be built? Is it not the design of the organization, rather than its ongoing operation, which is the most important responsibility of management.

Organizations consist of two types of functions with different, yet similar intents. There are those processes which begin and end with an external customer interaction, and have relatively easily measurable results. Then there are those functions which are process enablers. Process enabler functions do not begin and end with external customer interaction, but support those processes which do. These functions generally have results which tend to be more subjective than objective, and are more difficult to measure.

With the above consideration an organization may be viewed as per the following diagram.

This diagram is not intended to imply that all the functions identified as processes need to exist as separate processes, but more to point out that within the organization there are various end to end processes which are operational. The relevant question is whether or not there are more advantages than disadvantages to be gained from combining processes. Everything has an up-side and a down-side.

Note that Customer Service exists as a function for which it is difficult to determine whether it is really a process or a support service. I have decided to consider it as a process because it begins and ends with an external customer interaction, mostly. Yet, unlike most processes, it is one the organization should seek to leverage rather than minimize. There will be more about this later.

The above diagram essentially represents what is generally termed a matrix organization, and organizational theorists have long since agreed that matrix organizations generally don't work as well as expected. Yet, I have never seen a really good explanation as to why this is. It is my opinion that the reason matrix organizations don't work as expected is that they are only partially implemented, and essentially doomed to failure before they begin, because of this partial implementation.

The above processes exists within the current organization, within the context of the hierarchical reporting structure. They're just not treated as processes proper. The appropriate manner in which to do this will be addressed shortly.

The activity within most organizations generally looks more like Diagram A than like Diagram B. And the reason has everything to do with the design of the organization. This is true even in matrix organizations that treat some of their functions as processes. The following paragraphs will describe how to design an organization to produce what is represented in Diagram B, not how to get from Diagram A to Diagram B. This may be a little counter-intuitive at first because Diagram A is essentially what exists.

The reason for proceeding in this fashion is that organizations are systems, and the first rule of systems is "Don't fight the system. Change the rules and the system will change itself!" This is very closely related to Buckminster Fuller's comment at the beginning of this paper.

Rather than analyze the matrix structure presented above, the following will essentially be a synthesis of a systemic operation which promotes the desired results. To accomplish this it is essential that we first understand the way hierarchical organizations are. We begin with "A Process," which is representative of any of the processes labeled above.

A process may consist of any number of functions, three was simply chosen as some representative number. The whole intent and purpose of the process is to optimize throughput. That is, to generate the highest possible levels of customer satisfaction with the least amount of resource in the shortest amount of time. Because we don't believe the functions (f1, f2, f3) can operate as autonomous self-managed groups we assign supervisors, which report to some level of upper management and make them responsible for the functions. Responsible for seeing that the work gets done. Thus the structure begins to look a bit different.

This begins to create all sorts of difficulties. The first problem has to with a false belief, because you don't optimize the system by optimizing the components of the system. The interactions between the components of the system are as relevant, if not more relevant, to optimization than the functions, but we'll get to that later.

Supervisors are supposedly responsible for ensuring the work gets done, yet they are more apt to be loyal to pleasing their management, because that's were their performance appraisals are done. And we shouldn't make the misguided assumption that ensuring the work gets done is what places supervisors in a favorable light with their manager. Let's be real, annoying as it might be.

And the situation is coerced even more because managers report to some higher level of management, here labeled Big D, and they operate in a manner similar to that described for supervisors, regardless of how much they would like to deny the fact. One generally responds favorably to the hand that feeds them.

So who's responsible for the process? Only Big D! And what real influence does Big D really have on the process? Think about pushing on a rope. Also refer to Leadership and Management: A Structural Perspective.

Now if this situation wasn't bad enough as presented, realize that the process does not have the capacity to complete the result for which it is responsible without the assistance from some number of support functions, i.e. one or more of the Support Services identified in the initial diagram. In its simplest form this migrates the structure to look rather like the following.

Note that "s4" actually represents multiple supervisors for multiple Support Services and "m3" represents multiple managers. "m3" and "s4" are responsible for providing support to the the individual functions of the process, actually multiple processes. Yet, the multiple supervisors are in competition with each other to serve their manager, and "m3" representing multiple managers, is in competition with "m1" and "m2" in relation to Big D. This additional complexity only implies that Big D has even less direct influence over the process than if the Support Services didn't exist.

Now that you're probably quite thoroughly depressed, you ask, how do we get out of this mess? Just wait, it gets worse!

The next attempt was Total Quality Management, where each group begins to pay attention to the requirements of its customer. Notice the addition of but 4 more arrows to the above diagram. Probably the single greatest reason for the failure of TQM was that it never did anything to change the structure of the environment. The reporting relationships and loyalties remained the same and sooner or later undermined any progress that TQM could make. It also didn't help that TQM has a tendency to produce a very localized myopic focus on the immediate customer as opposed to the whole process or the whole organization, and this gets back to the previous statement about not being able to optimize the process by optimizing the parts.

Over the past few years there has been an extensive amount of work done in the area of semi-autonomous Teams or self-managing work groups. Although there have been numerous successes in this arena, there have been just as many failures. Again, the basis for these failures stems primarily from the fact that the overall structure of the system was not addressed and changed. In addition to this, self-managing work groups are often pursued with confusing messages which undermine their potential success. One of the most prevalent of these mixed messages comes from management continuing to talk about the benefits of a team based operation, while still performing individual performance appraisals. The individual performance appraisal tends to refocus individuals on individual performance rather than team performance.

In the midst of all this one has to deal with bureaucracy and organizational politics. And although everyone decries their existence few have ever figured out how to rid the organization of them. The reason bureaucracy and organizational politics flourish is that they are a natural emergent quality of the organization structure discussed to this point. One of the first principles of systems is that "structure influences behavior" and the traditional organization structure promotes the development of bureaucracy and organizational politics. This along with the realization that people always, always, always do exactly what makes the most sense to them at the time they do it, implies that the only way to overcome these organizational dysfunctions is to alter the structure in such a way that bureaucracy and organizational politics simply produce no advantage.

Reengineering is the first management fad to even come close to addressing the root of the problem, without ever quite realizing that it was the root of the problem that was being addresses. Probably the most comprehensive approach to reengineering I've seen to date, with conscious foundation, is something called Whole Systems Architecture, which was developed by Dr. Lawrence Miller at Miller Consulting in Atlanta, GA. Dr. Miller was also the author of "Barbarians to Bureaucrats" in the late 1980s. The idea being that if you wish to produce lasting change within an organization you have to change the structure, not just the organization's reporting structure, e.g. the blocks on the organization chart. You have to change all the pieces which represent the real structure, i.e. the processes, policies, procedures, incentives, rewards, management philosophy, etc. This is very much in line with another foundational principal of systems, "Don't fight the system, change the rules and the system will change itself." This comment is directed at all those elements mentioned above which are part of the rules of the system. The structure and the rules are one!

Reengineering, in most instances, is a relatively inappropriate label to be applied to the activities undertaken, for how can you reengineer something that wasn't engineered in the first place? Organizations are for the most part not engineered, they just develop out of apparent necessity over time, from one anomaly to the next. Whenever something develops within the organization that doesn't fit within the current structure, or mode of operation, the operation is altered just enough to accommodate that new something. In this way the organization develops, or evolves, over time, very much on an as needed basis.

From this point we go back to the beginning and define a more appropriate architecture beginning with the fundamental unit of the organization, the process.

The intent of the process is to produce a result for the customer in a manner which satisfies the customer's expectations and makes money for the organization. Without getting into the eternal argument regarding profit as "the motive" of the organization, let me simply put it that profit is a requirement for doing business, not the objective. This is much like breathing is a requirement of living, but not its objective. If profit is the ultimate objective of a business then the business should sell drugs, for this business has a much higher return on investment.

For a multi-function process to produce the appropriate result each function must focus on its operation and the results of the process. The operative word here is "AND." The functions should be setup as self-managing work groups which are evaluated on their contribution to the process. This creates a balance where a function cannot succeed if the process fails. This requires that each function receive continuing feedback on how the whole process is operating, and the results produced, as well as the progress of each function in the process. The process is evaluated on the results of the process.

With the establishment of self-managing workgroups there is a point which is often confused, and for good reason. The point of confusion has to do with the difference between importance and value. If each member of a self-managing work group is equally important, then why are they not all paid the same. While each member of the group is equally important, they are not equally valuable. The value of a member of the group has to do with the replaceability of the skill the individual brings to the group. And replaceability is dependent on the availability of individuals with that skill, the length of time that it takes to develop that skill, and the level of expertise of that individual in that skill area. While a surgeons assistant and a surgeon are equally important to the success of the operation, it takes far longer to develop the expertise of the surgeon than the assistant.

As an organization transitions from the traditional supervisor-employee relation to self-managed teams the individual teams need ongoing support of their development. To provide this support I have contemplated a position called Senior Associate.

The Senior Associate is not intended to fill the traditional supervisor role, but rather act as a resource to the function, responsible for providing development support services. That is to say, the Senior Associate essentially acts as a consultant to the function, with the Senior Associates performance evaluated by the function, not some other level of management. This will tend to keep the Senior Associate's attention focused on the function to be supported as opposed to developing allegiances with management.

Another position considered is that of Process Coordinator. This individual is responsible for the results of the process, the development of Senior Associates, and development and performance of the process functions.

Again, the Process Coordinator position is not responsible for the traditional management functions of planning, organizing, directing, and controlling. This individual is responsible for delivering services to the Senior Associates, and the process functions. The performance of this individual is evaluated based on the results of the process, and the perceptions of the Senior Associates, as well as the self-managed teams. You might say this person reports to everyone in the process, including the Customer.

This still leaves the question of Support Services and how to overcome the limitations inherent in the traditional structure for managing and providing support services.

The above diagram depicts three different support services provided to the functions, yet it is recognized that the same service may be provided to multiple functions, and multiple services may be required by different functions.

In order to remove the previously described difficulties with support services reporting to some position in the organizational hierarchy, support services must report to and be evaluated by the functions they support. This solves one part of the problem, yet creates another. That is, if the support provided enhances the function's operation and the results of the process, and there is no cost associated with using services, then the functions will demand as much support as they can get. As long as it's free, I want all I can get.

To overcome this the individual functions, and the process they are part of, are assessed a cost for using support services. In this way support services desired and used is balanced because using services detracts from the results produced by the process. The situation becomes results oriented self-limiting rather than management limited.

In the same fashion that there are Senior Associates and Process Coordinators responsible for, and reporting to, the processes and their components, there are Senior Associates and Services Coordinators responsible for, and reporting to, the service operations.

Service Coordinators, Process Coordinators, and upper management, then act in a collaborative fashion to continue to evolve the design of the organization, which has essentially become a completely self-directed, self-evaluating, self-managing, results oriented structure. One of the primary values added by the Senior Associates and Coordinators is a breadth of awareness and the time horizon they consider. The self-directed functional teams have a primary focus on their operation, in a short term time frame, with an awareness of the process. Senior Associates are more aware of the interactions between functions and service providers, and consider time frames of weeks and months. Coordinators should have an even broader perspective on whole processes, and consider time frames of months and years.

The relevant question at this point then becomes how to get from the current operational environment to the envisioned future operation. And this isn't nearly as difficult as it might at first seem.

The traditional approach to organizational change of this scope has been to get top management to buy in, then attempt to communicate and energize the whole organization to the transformation. I have seen this method applied in numerous TQM implementations, more often than not with an ensuing dismal failure. Attempting to transform the whole organization at once simply dilutes the effort, and since organizations have experienced numerous attempts at transformation in the past, they have become essentially numb to intervention.

The most appropriate approach to organizational transformation is one rule (read structure) at a time. As was previously stated, structure influences behavior, and the policies, procedures, incentives, rewards, etc. are all elements of the structure. They are the rules of the operation. They are the structure! To change the operation of the organization, change the rules, one at a time, and the organization will change itself in response. A bit more clarification is in order at this point.

As for the transformation of the various segments of the organization, this should be on a group by group basis. That is, work with a single organization, introduce a set of concepts, develop an understanding, and then work with the group so they can actually develop their own transformation plan. It would be quite easy to develop the plans for them, but then it would have to be sold to them, and it would always be someone else's plan, not theirs, and probably the best you could hope for would be enrollment rather than commitment.

Having considered this at some length it would seem most appropriate to work with the process organizations first and then progress to the support services groups. It should also be remembered that in the beginning small wins produce great long term returns.

This does not imply that one group is finished before the next group begins. It implies that one begins one group at a time. As a group becomes more capable of functioning on its own then proceed to the next group, and then the next. This is an endeavor which does not actually have an end, for the development of the individual groups, and the organization, is a process in and of itself, which should continue for the life of the organization. The transformation represents embarking on a journey, not pursuing a specific objective destination.

As far as concepts introduced and transformation plans developed everything is done from a basis of what gets measured. That is, first develop an understanding of what it makes sense to measure, and then support the development of the group to effectively produce those measures. This is true for both support services and processes, realizing that processes will have a tendency to be somewhat more objective while the support services will tend to be somewhat more subjective. Yet, both are quite measurable. If you can't measure it, why do it?

In the development of an understanding of what is most meaningful to measure, and how to measure it, it is essential to keep in mind that measurements must include the Voice of the Customer, the Voice of the Employee, and the Voice of the Business. All three dimensions must be accommodated.

It is understood that extensive support must be available to assist the individual groups during their transformation. And, at the same time, remember this must be a level of support that nurtures, supports, coaches, etc., rather than drive the group toward a destination. This type of support must also be available to assist in the development of Senior Associates and Process/Service Coordinators.

As for a specific point to begin with a group, it begins with a single question, "Are there ways that our efforts could be made more meaningful." This is not a question directed toward making things faster, less expensive, etc. These will be beneficial outcomes of the effort. The meaningful questions for the group in addition to the initial question are:

• What is the group doing that it should continue doing?
• What is the group doing that it should improve in some way?
• What is the group not doing that it should begin doing?
• What is the group doing that it should stop doing?

Just Do It!

When I had reached this point I thought I was pretty much done. Then someone said, "Ok. You have the job. Now tell me exactly how you're going to make it a happen."

Partly it's a good question and partly it's a terrible question. As for the good part, additional thought about specific actions to be taken is a good idea. From the bad part, it's actually two parts. This whole description isn't something one makes happen. It's something one enables to happen! The other part has to do with advantages and disadvantages of explicit descriptions of how to do things.

Fads become fads when we reduce foundational understanding to regimented formulas which are essentially followed without much conscious thought. A formula for multiplying two numbers is fine because the same formula always works. In an organizational context there are simply to many variables for any formula to be correct. The foundation of action must be understanding tempered with continued reevaluation of the current situation. Anything less has a very high probability of failure.

So back to the question of an explicit sequence of steps to be taken to get from here to there, and here is a initial stab at it. This is not intended to be "the answer" but more a set of guidelines from which specific approaches would be developed by individuals responsible for various facets of implementation.

In a number of places there have been comments about alignment, and alignment can only happen when there is something to align upon. A laser aligns because it is focused via a lens. In this instance the focal point is initially created by a paper entitled "This I Believe," which whoever is responsible for the organization needs to write. This is a one page statement of belief which talks to what is believed about people, customers, and the business. This should be very consistent with the Voice of the Employee, Voice of the Customer, and Voice of the Business dimensions previously presented. Once written the paper needs to be shared with the organization and then the author must continually act in a manner consistent with what has been written. What this does is create a focal point for alignment along with a continuing set of actions consistent with what was written, thus serving as an example of coherence.

The next step is to transform one group within the organization, with the intent of this group later serving as a model to the rest of the organization. A model which can be presented from the perspective of saying, "See, it can be done. Here is an example!"

The intent is to develop a sense of ownership within the group from the perspective that the group feels responsible for their own actions and the direction in which those actions are taking the group. It is proposed that this be accomplished from the one, to the many, to the all. What this implies is beginning the transformation on the individual level, progressing to small groups, and finally to the whole group, in such a manner that the whole group essentially feels like, and believes, they were themselves responsible for the transformation.

I would begin this by meeting with each individual in the group, one on one, and use the following set of questions as a basis for discussion.

• Why are we here?
• What is the group doing that it should continue doing?
• What is the group doing that it should improve in some way?
• What is the group not doing that it should begin doing?
• What is the group doing that it should stop doing?
• What do you expect from me?
• What do I have a right to expect from you?

During these meetings the intent is essentially to create an expectation on the part of the individual that their perspectives are valuable, and that something will be done with their input. There must be no attempt to debate each individuals perceptions. At this point knowing and the creation of expectations is the most important part of this activity. I would ask questions for clarifications where I wasn't quite clear as to the implications of the answer. I would probably also ask questions regarding areas that weren't touched on by the initial set of answers. Areas which might include what does it make sense to measure, and how do we measure it, how should the group operate, and how should it evaluate it's own operation, how should performance appraisals be done, etc. As I met with each individual I would keep a set of notes as to the answers provided in each category.

After meeting with each individual I would have them start meeting in small groups of 4 to 6 people to discuss the collective set of answers developed during the individual meetings. Were I the individual responsible for this group (a reference to a prior mode of operation that has to be done away with) I would have this meeting facilitated by someone else so I did not tend to hamper communications among the individuals. The intent would be to have them develop some consensus as to the most important entries in each category and determine to what extent the answers in the "Why are we here?" category are consistent with the previously written "This I Believe Statement."

These meetings actually accomplish two things, one obvious, one not so obvious. The meetings provide a focus for groups of people to come together on something other than themselves, and their personal differences. Providing this point of focus allows the group to come closer together without realizing it. The meetings also end up producing relatively prioritized lists of purpose, vision, values, and actions to be taken. The purpose, vision, values, and actions which emerge from this interaction are something you couldn't get by directly asking for purpose, vision, values, and actions. Some things just don't work the way we would expect them to work.

Once the small group meetings have been completed the small groups findings must be collectively presented to the whole group, by different members of the individual groups, and the whole collective must come to some sort of agreed upon consensus as to "What's to do?" At this point I should realize full well that the actions required will be in two categories, those which can be done by the group, and those which must be done by groups at other locations within the organization.

The group essentially develops it own set of marching orders at this point, and individuals from within the group should be allowed to take the lead on various items. And, the individuals that take the lead would be responsible for reporting back to the group regarding progress in certain areas. This is rather the development of team based self-managed work groups without ever telling anyone that it's being done. It's something you just allow them to get to because it's where they will gravitate to when allowed to do so.

As for the support efforts which are identified as responsibilities of other places in the organization, this support is very critical, and must happen, for if the support doesn't happen it will discourage the group.

At this point, as the group accepts responsibility for itself I would make it know that I am a resource at their disposal for certain types of support which they deem most appropriate. I am not there to do their job, but I am there to provide support. All of the traditional management / supervisor responsibilities, i.e. planning, organization, directing, and controlling, have been transferred to the group. My primary role would be one of facilitator, coach, and coordinator for things the group asked that I coordinate. At this point I would expect that my performance feedback would be done by the group for it is they who are now my customers, not the management I used to report to.

In conjunction with all of this, there is an awareness that "Senior Associates" need to be developed, and at present there is no model for them to follow, because no Senior Associate currently exists. So what's to do?

The first Senior Associate is being developed on the fly during this process. And before the effort was started it would seem to make sense to identify the next couple of potential transformation groups and have them become familiar with the process as it unfolds. The intent is for them to develop an understanding by association. This would make the whole process somewhat familiar to them when they began the same effort. At some point along the way it is expected that individuals that have been acting as Senior Associates could begin to act as facilitators for the later transformation groups.

In the midst of all this, upper management begins to get out of the day to day running of the operation and begins to develop a longer term perspective on the overall design of the organization, as was previously discussed. This would be accomplished via the same process as described for individual group transformation, with the same set of questions. The responses to which would be distilled and prioritized during group meetings to develop consensus.

And I guess at this point I would say, "And that is that!"