©2007, 2009 Don Gray and Jerry Weinberg

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

• Respond negatively, looking for reasons, usually blaming someone else) for the results.
• Decide no difference exists by ignoring the results and do nothing.
• Respond constructively, learning from what happened and improving at getting the results we desire.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a ?success?) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

• Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
• If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
• Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
• Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

• Observe what’s actually happening. Are people doing what they say they’re doing?
• Listen to the language people use. Do you hear blaming?
• Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like ?It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

convert this post to pdf.

©2005 Johanna Rothman.

This article was previously published in Computerworld, April, 2005.

I was talking to a relatively young developer the other day. I asked him about his career plans. “Oh, I don’t do career planning myself. I wait until my manager talks to me.”

Oops. Your career is your responsibility. Some managers are interested and want to coach you through career planning. But in my experience, even the few managers who know how to help employees plan their careers take the time to do so.

Separate the skills

Your technical skills can be organized into four buckets: functional skills, domain expertise,
tools/technology, and industry expertise.

Functional skills are the skills you learned in school or have learned from books. How to develop, design, test, write, manage, schedule–all of those are functional skills. Domain expertise comes in two flavors: problem-space and solution space. Problem-space domain expertise is how quickly and how well you understand the problems your product is trying to solve. Solution-space is how well you understand the internals of the product–how well the product solves the problem.

Tools and technology expertise are all the languages, operating systems, and other tools you know. Tools and technology expertise is the easiest to acquire. Industry expertise is how well you know the industry you’re in.

Of these four areas of technical skill, your breadth in functional skills and your ability to acquire domain expertise in depth are the two most valuable skills. It’s easy for people to learn about new tools and technology–but it’s how they apply their functional skills to the new technology that predicts success. It’s easy for people to learn about an industry–and it’s how they use their industry knowledge to develop or test (or manage) a product that matters.

Focus on functional skills early

At the beginning of my technical career, I focused on my functional skills: how to be a better designer, debugger, unit tester, coder, over-all software developer. When I transitioned into testing, I refocused on my functional testing skills: how to be a better tester. When I moved into management, I again refocused on my functional skills, this time in management: how to give feedback, how to coach, how to plan. Early in your career (and any time you change roles), say for the first five to ten years, you learn new functional skills and new tools and technology.

Increase domain expertise mid-career

Once you’ve been working for 10-12 years, it’s critical that you continue learning about how to adapt your functional skills to new domains and new tools/technology. Otherwise you become like someone I met recently, who said she was a “Cobol programmer.” She had not learned any other functional skills, such as design skills, or other languages or anything other than Cobol programming. It’s not only that you shortchange yourself when you don’t learn new functional skills or new domains; you also decrease your value to your current (and future) employer.

You may wonder why I’ve used 10-12 years as an introduction to mid-career. The most valuable people aren’t afraid to change roles. I don’t mean that people should change roles every year?that doesn’t help you learn the functional skills or product in depth. But as an example, working as a developer, moving into a technical lead role, moving back to a development role, moving into a project management role, onto a different development role–all of those changes can make you more valuable and make you more capable in any of the positions you take.

Revisit functional skills when you change roles

If you change roles in an organization, such as moving from development to test, or from test to project management, or from management to architect, plan to update your functional skills for you new role. If you’ve been a technical lead and you’re moving to an architecture position, you’ll want to learn (or reinforce) new techniques to allow you to develop ideas and design more effectively alone and with others.

When I realized I was interested in learning more than just technical functional skills, I started working on my project management and people management functional skills so that I could be successful in those areas. It doesn’t matter which functional skills you start to improve once you’ve been working for a while; it only matters that you decide you’re ready to expand your skills in another dimension.

Remember the nontechnical skills. No matter where you are in your career, remember to pay attention to skills like writing, presentation, negotiation and influence skills, to name just a few. They are helpful no matter where you are in your career.

Don’t wait for your manager to plan your career. Wherever you are in your work experience, take some time to sketch out your future. The more you learn, the less of a commodity you are to your employer–and the more valuable you are.

convert this post to pdf.