THE POWER OF KNOWING WHO DOES WHAT

If you question what you see and hear ” which, by the way, is generally a good habit to get into if you re in process improvement ” you might be wondering why you suddenly find yourself in a chapter about organizational roles and responsibilities and why this topic appears so early in the book. The answer is simple: in almost any systems engineering organization, almost every individual will have some basic understanding of the nature of his or her role, even if they can t articulate their roles very well. People will also believe they know the roles of others with whom they work and they will claim to know the relationships between roles. In both these areas, their knowledge will most certainly be wrong and based on utterly false and fact-free assumptions. Why? Because the nature of the human ego, particularly in Western society, dictates that I am the universe and the universe is me. What I do matters and what other people do does not matter until it messes with my universe. To quote a friend of mine, When I close my eyes, it is night.

One of the first things my consulting practice ” Natural SPI ” does when we engage a client is to try to figure out the answers to the following questions:

• Who does what?

• Why do they do what they do?

• When do they do what they do (in consequential relationship with what other people do)?

• For whom do they do what they do?

Notice we don t ask the question, how do people do what they do? which is the prevailing question asked in an appraisal (e.g., SCAMPI) used to baseline the organization s current state. That s because how people do their work is trivial at this point in time (the beginning of process improvement) and can t possibly be answered in a permanent way until the first four questions are resolved.

The above four questions are amazingly simple, yet the answers are amazingly complex. We will initially obtain confident answers to such questions. However, in the months that follow, we gradually peel the onion and find out that the initial answers weren t even close. It doesn t seem like a problem, at least not a big one. The organization muddles along. Confusion and conflict frequently arise over who is supposed to do what, and these perturbations range in intensity from snippy e-mail notes to all-out yelling, fist-pounding turf wars. Yet somehow in the end, everybody manages to get the product out the door so yippee, the organization gets to survive one more quarter.

Living from one system release to the next by pretending we all understand each others roles and responsibilities might get the organization through software or system releases, but CMMI-based process improvement won t have a prayer of succeeding. In model-based process improvement, consensus definitions for roles and responsibilities is critical to success and that is why it deserves its own chapter. It is also something the organization will want to start working out way before it begins planning its process improvement work (per Chapter 3) since planning assumes a certain level of understanding of roles (like who is involved in planning). First, let s review what has happened in organizations countless times as a way of informing you of what will occur in the future if roles and responsibilities don t get defined.

When Good Roles Go Bad

All of the following scenarios are based on real situations I have observed in my work.

The system is delivered and a customer complains that it doesn t satisfy their requirements. The customer blames the delivery organization for not understanding the requirements and the delivery organization blames the customer for providing poor requirements. Both sides are right and both sides are tragically and stubbornly wrong. No lessons are learned and both parties simply move their attention to the next crisis.

The SEPG members perpetually whine about management not being good sponsors of process improvement. The managers don t see process improvement sponsor anywhere in their job descriptions or bonus plans and wouldn t intuitively know what being a sponsor of process improvement means under any circumstances. So, the SEPG people must simply be chronic whiners and the senior managers are demonized. Nothing changes, especially the organization s growth and maturity level.

The organization s testing department hears that SEPG is going to establish a QA department. The department goes ballistic upon finding this out because, QA is our job why do we need another QA department?

Two organizations, each dependent on the other for developing subsystems of an overall system, are constantly at odds with each other over collaborative work. The poison of suspicion and paranoia pervades their communications because each organization believes the other is trying to take away work. There s no good way to objectively resolve the situation because the leadership in each organization knows what their roles are; no one can convince them they don t know.

The project manager and the program manager learn that they are both responsible for the project plan. The project plan never gets written because for each person it was someone else s job.

A system engineer sends an e-mail note to a vendor that identifies a problem in the system. Three months later, the problem isn t fixed and the system engineer blows up at the vendor. The vendor doesn t understand why the SE is so angry .

The organization s process improvement group is chartered with implementing ISO 9001. When a SEPG is formed to implement CMMI-based process improvement, the other process improvement group is incensed because the SEPG people are intruding on their territory.

When we get caught up in situations like these, it s easy to dismiss each of them as a one-off event. Yet when we view multiple similar situations, a pattern forms which allows us to take a system view of the overall problem. One of the primary root causes of all of these scenarios and in many other similar situations is the lack of defined and concurred roles and responsibilities. People in the organization simply assume that they know their roles and the roles of others. Those assumptions are valid except for all the times they are proven to be invalid.

Why Defining Roles and Responsibilities Is So Hard

Defining the roles and responsibilities in your organization is as difficult to do as it is critical to successful process improvement (and all other aspects of business). There are many reasons why this task is difficult, but the primary reasons are:

There are no universal definitions for roles and responsibilities; there is only infinite variation on a theme.

We don t have much practice at articulating what we believe to be our roles and responsibilities in the workplace.

In some organizations, there are many more roles than there are people.

In some organizations, there are many more people than there are roles.

Defined roles and responsibilities enable accountability.

Let s take a brief glimpse into each of these barriers to defining roles and responsibilities in the interest of learning how the organization can make progress in this area.

You Say System Engineer, I Hear Project Manager

Until the point at which we enter the professional workplace, who we are and what we do are so integrated at the subconscious level, that there s never any reason to question it or talk about it. What we do is who we are. I m a baby so I cry and drink milk. I later play rough with other boys and tease girls, ergo I am a young boy. I m a teenager, so I go to school, rebel against my parents, and try to get dates with girls . When I find myself listening to a lecture in a large hall, I must be a college student and that man standing up giving the lecture must be the professor because he is teaching. Even looking around us, we automatically classify who people are and what they do into stereotypes. We see a person driving in a police vehicle in a police uniform ” police officer is not only what she does, it s who she is. We see a car salesman on TV and the person and his role are one and the same.

So then we enter the professional workplace. I m a software engineer for one company for several years , so I begin to believe I know what a software engineer does. Then I switch jobs and go to work for another company as a software engineer. My coworkers have an understanding of the responsibilities of a software engineer and I have an understanding of the responsibilities of a software engineer, but the two understandings are different and we don t find out until a situation causes the misaligned understandings to surface. The problem is that the job of a firefighter may be the same no matter which city he protects from fire. But roles and responsibilities of a software engineer, system engineer, project manager, vice president, analyst, or quality engineer are likely to differ from one organization to the next depending on the nature of the business, the market, and the evolved culture of the organization. Then I take a better offer with yet another company as a program manager. I ve seen program managers at work, so I think I know what a program manager is and what I m supposed to do. Yet again, my ideas of a program manager are radically different from those of my employer and once again the harsh light of conflict and reality shines on the misaligned understanding.

What all of this adds up to is the simple fact that there are no universally accepted definitions for roles and their associated responsibilities in software and system engineering organizations. This fact, compounded with the natural human tendency to believe that a job title has the same meaning everywhere, makes defining roles and responsibilities difficult.

I Know What I Do, But Don t Ask Me to Explain It

Another dynamic that inhibits from defining roles and responsibilities is the simple, observable fact that, over time, we become so adept at doing something that performing our job becomes second nature and what we do and how we do it moves from our consciousness to the subconscious. Subscribing to one theory on human learning and skill adaptation, all of us more or less take this path :

1. We start out unconsciously incompetent: We don t even know what we don t know. We are neophytes in an area of knowledge and skill and we don t have a clue as to what or how much we have to learn.

2. Next, we are consciously incompetent: We are aware of what we don t know and what we need to learn. We are novices, not yet particularly skilled or learned, but at least we know what knowledge and skill to obtain and how to do so.

3. Then we are consciously competent: We are aware of what we know, how we do our job, etc. We have become proficient and we can articulate our proficiency because the knowledge and skill live in our conscious mind.

4. Finally, we are unconsciously competent. We are experts who are extremely good at what we do. But we are no more aware of our knowledge and skill than we are of our breathing or heartbeat.

When we look at these four evolutionary stages of competency, it seems obvious that if we were to coach or mentor someone in a new area of skill and knowledge, we would use someone in the third stage ” consciously competent ” since such a mentor would be able to articulate and thus transfer knowledge. But is this what happens? No. What usually happens is that we expect the experts, those who are unconsciously competent, to mentor novices. And it doesn t work for the same reason I can t explain to people how I write ” I don t know, I just do it; it s what I am. Yet 20 years ago, I probably could have explained the process of writing to someone.

More Roles than People

In an idyllic world, there s a job for every person and a person for every job. But in the world in which you and I live, the number of different jobs or roles within a particular organization does not coincide with the number of people in that organization capable of fulfilling those jobs. Additionally, when the ever- swinging pendulum management theory swings from specialization to generalization, we often see organizations in which one person is performing in multiple roles. Finally, the number or roles that evolve in an organization is often correlated to the overall size of the organization in terms of number of employees and the number of different lines of business or markets in which the organization participates. As shown in Figure 2.2, the definition of roles and responsibilities becomes particularly difficult as you move down in organizational size , because in the smaller organizations, individuals often have many roles and many responsibilities. Figure 2.2 illustrates just a small subset of the plethora of roles you could find in a global company of 10,000 or more employees and how the number of roles gets reduced when translated to a 1000-person organization. Finally, by the time you get down to the ten-person consulting firm, such as my firm Natural SPI, there are two or three people doing everything from running the Board of Directors meeting to running a check to the bank for deposit.

Figure 2.2: Organization Size and Number of Roles

Going the other direction ” from very small organization to very large organization ” you often find such a diffusion (confusion?) of roles that the names of some roles have almost no obvious or intuitive meaning. I know of one very large, global consulting company in which it seems every other person is called a Vice President or Senior Partner. These terms might mean something to the people in this organization, but an outsider, such as a member of an appraisal team, would have a difficult time figuring it out.

More People than Roles

The converse of having more roles than people is, of course, having more people than roles. This one is scary because if the organization does define their roles and then divide them up among the workforce, and there are people left over with no roles, management will draw only one logical conclusion ” that s right, some of you have to leave. Less frequently and usually in organizations with a lot of capital to throw around, management will simply invent some roles so that everyone can justify showing up and collecting a paycheck. You can often find people who don t have a real role in something called special projects.

Fear of Accountability

This one is really the rub. Look, if the organization s management and I decide and concur on my roles and responsibilities and we document those things, then people have something against which they can measure my performance in the job. That s great for performers; but it is anathema to people who really don t want to be held accountable for performing or producing. The postmodern workplace does contain people who would much prefer to have their role defined rather loosely, like show up every day and do some work. This type of role definition is usually assumed and not documented because it would look pretty silly to write down show up every day and do some work. If I am among those who really don t want to be measured or held accountable for performing or producing, this is exactly how I will want to leave things. The process focus people are not going to get my cooperation in defining roles and responsibilities.