©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.

©2006-2007 Esther Derby

This column originally appeared on Stickyminds.com.

Conflict is inevitable at work. Sooner or later, you will disagree about what to test, when to test or how long to test software. How you.and the person you disagree with.approach the conflict affects both the outcome and how you feel about the exchange. Let’s listen in as Jim, a test manager, and Pam, a development manager work through one of those inevitable conflicts.

* * *

Jim, the test manager, started the coordination meeting with
Pam, the development manager, by stating that he needed her team to turn over
all the code on the first Monday in September. In a previous meeting, they’d
discussed having the code complete in October, but Jim’s statement sounded like
a demand to Pam rather than a starting point for discussion.

Pam asked Jim what was behind the change, and when he said
he wanted to begin testing early, Pam was thrilled.

“That’s great,” Pam said. “Early testing will really help
us. We won’t have all the code done until the October date we discussed
earlier, but we’ll have features ready to test starting in August. I can turn
over features every two weeks from August through September.”

“No, I need all the code for early testing the first week
in September,” Jim reiterated.

“Is the issue that you don’t have anyone to assign to
testing earlier?” Pam probed.

Jim shook his head. “No, we need the code all at once.”

Pam asked more questions to understand Jim’s concerns and
offered more options, but Jim stood firm.

Later, Pam mused to herself, “It’s almost as if he needs me to lose in order for him to win. I
offered everything I could think of so the situation would work for both of us.
Now we’ll have to hash this mess out with the VP. Why does Jim always have to
have his way?”

Meanwhile, Jim was thinking, “Why did Pam try to weasel out of this? If I agree to her options, she wins.”

Scenes similar to this one play out in business every day.
The people and the topic may be different, but the ways Pam and Jim are
approaching their differences represent common approaches to conflict:

• Collaborative Problem
  Solving–Pam is approaching her conflict with Jim by trying to find options
  that will work for both of them. She’s looking for the interests behind Jim’s
  position, sharing her interests, and looking for options that satisfy both
  parties.
• Competition–Jim, on the other hand, is approaching the conflict with one aim in mind: achieving his goal. He’s not willing to explore other options; he’s intent on pressing his preferred solution. If he get’s his way, Pam doesn’t get hers.

In addition to Pam’s Collaborative Problem Solving approach
and Jim’s Competition approach, there are three other common approaches to
conflict:

• Yielding–In this style, one person yields, accommodating the other personís wishes without pressing his or her own interests.
• Avoidance–Sometimes people do
  everything they can to avoid a conflict. They pretend the difference doesn’t
  exist to avoid the unpleasantness of confrontation.
• Compromise–In compromise, people try to meet halfway. Each gives up some of what he wants and achieves some of
  what he wants. Compromise is common, though not always satisfying since no one
  is completely happy with the solution.

All of these are valid and useful ways to approach conflict
in some situations. And each can be destructive when misapplied.

In the story about Pam and Jim, Jim could have achieved his
stated interest had he been willing to look for more options to meet the goal
of early testing. His desire to prevail–competition–in this situation will
damage his relationship with Pam, and may hurt his reputation with the VP.

Pam’s approachócollaborative problem-solving, while
appropriate in this situation, might not be helpful when there’s a clear
downside to meeting the other’s interest—for example if the other person
wants to pursue an illegal or unethical action. Pam’s collaborative approach
also takes time in order to uncover interests, generate options, and reach a
mutually satisfying outcome. It’s worth the time when long-term relationships
are at stake, but may not be when time is of the essence or the relationship is
transitory. (If a store clerk in the airport wants to talk on the phone with a
friend instead of serving you, and you have a plane to catch, you probably
won’t use a collaborative problem solving approach. You just want to pay for
your item and be on your way.)

Likewise, yielding is fine when one person doesn’t have much
investment in the outcome and the other person does. Yielding hurts when it’s
habitual–one person always gives in to the other. Others may perceive habitual
yielders as doormats and walk all over them. An
example in the workplace is when someone always says “yes” to all his manager’s
requests without discussing risks and negotiating. The long term cost of
habitual yielding is resentment, depression, anger, and contempt.

Avoidance may be the best policy when there’s nothing to be
gained by working through an issue. For example, one manager walked away from a
conflict with a peer when they couldn’t agree on a testing standard. He saw
that the situation would correct itself as soon as the standard (which he
believed was misguided) was published to the organization, and that arguing
with his peer would only damage their relationship.

We often hear that compromise is the ideal, and sometimes it
is. But looking for compromise often ends in a half-horse, half-camel solution
that isn’t fully satisfying to anyone. Compromise leads people to miss novel
solutions that can satisfy both parties and may be better than either of the
original solutions. Pam could have compromised and agreed to turn over
partially completed features, but that wouldn’t have worked out well for either
Pam or Jim. Compromise is the best option when it’s clear that a collaborative
solution isn’t possible.

Like Pam and Jim, most of us have a preferred style for
approaching conflict. Sometimes it works for us–and sometimes it doesn’t. When
we approach every conflict with the same style, regardless of what’s at stake
and without consideration for maintaining important relationships, we may win
in the short term but lose in the long term. Or we may avoid a difficult
conversation but build up resentment. We’re all more effective when we develop
our ability to approach conflict with the style that suits the situation.
Consciously choosing which approach fits best, given the stakes and the
relationships, is a winning strategy every time.

convert this post to pdf.

©2005 Johanna Rothman

I recently spoke with a manager who’d just incorporated another group of four people to his original three. “I was doing fine with my three people before I took over this group. I had time to manage, and I was able to contribute to the application. Now, with seven people, I seem to be floundering.” After asking the manager what else he was doing, he explained he was also recruiting for two open positions in addition to his normal management work and technical contributor work for one of the projects.

This manager has passed his limit of managing people and performing technical work. It’s not possible to be a good manager to more than three people and perform technical work. Depending on the circumstances, it may not be possible to manage even three people and perform technical work.

Here’s a sample breakdown of the kinds of tasks a manager of three people performs over the course of a week:

• Meeting with with each of the three people one-on-one, and a group meeting. Including the preparation and follow-up time, this takes about four hours per week. (Each additional person adds another hour to this total.)
• Managing the project portfolio (dealing with requests to start/end projects, assigning people to projects, making the tradeoff decisions, and keeping track of what the group is doing takes another hour.
• Spending time with the manager’s manager to identify issues, solve problems, preparing budgets, reports, or other paperwork is about an hour per week.
• Talking to peers across the organization can take about an hour.
• Problem solving with the people in your group, with other people across the organization on behalf of people in your group takes about four hours per week/person, so here about 12 hours. I include recruiting for open positions in this chunk of work. (For each additional person, add another four hours)
• Many managers have an unpredictable amount of organizational issues to resolve also

So if a manager is managing only three people, that manager may have about 20 hours available to spend on technical work. But once a manager adds another person, that manager has only about 16 hours left to spend on technical work.

Much of the management work listed above is interrupt driven, intertwined, and ad hoc. That means that a manager can’t schedule his or her work in discrete chunks. The most effective managers context-switch the entire day. In contrast, the most effective technical people spend large chunks of time on one task until they are stuck or have completed the task. Managers, by the very nature of their problem-solving work, cannot stick with one task until it’s completed.

When your group expands to four or more people, don’t plan on completing much technical work. You may still be able to do little bits and pieces, but managers of four people can only devote small pieces of time to
technical tasks. Managers of seven people have no time to perform strictly technical work–they must devote all their time to management to be effective managers.

If you’re managing more people than yourself, plan for your management time. Then you’ll see if you can fit more technical tasks in.

convert this post to pdf.

©2007 Don Gray

“Why doesn’t my manager listen when I explain the details?”

“Why doesn’t the developer just give me what I ask for?”

If you’ve ever heard these complaints-or made them-you’re not alone. Questions like these are a symptom of a communication disconnect. Communication disconnects happen every day for a variety of reasons. Three common reasons for disconnects are:

• Where we get information
• How we store and “re”present that information
• What we do with what we know.

Getting Information

Information exists in two primary places; outside us, and inside us. Some people tend to focus on the “out there information”, what they’ve seen, heard or touched. They seek specific concrete and factual experiences. You could call them “sensors” since they get information through their five senses.

Others find the information “inside” based on their experience, knowledge, and insights. With minimal external influence, these people dive inside themselves, and start looking for possibilities, meanings, relationships, and patterns. They’re more interested in “what does it mean” than “what”. These people could be called “intuitors”, since their intuition guides their actions, rather than data.

The disconnect happens when “sensors” and “intuitors” try to share information. A sensor asks a question expecting to get specific data points, and instead gets a rambling (to the “sensor”) discussion of patterns and possibilities. Instead of a general idea and pattern of information, the intuitor hears a flood of boring minutia leaving the requestor wondering what the other is blathering about.

To reconnect, a sensor can ask “what have you seen, heard or experienced that leads you to this conclusion?” Intuitors could ask “what does all this data mean?” Even better is to know yourself whether you’re an intuitor or sensor, and what the other person is. This enables you to respond to the other person’s style.

You can practice being the other type. If you tend towards “intuiting”, try to notice several “out there” things every day. Carry with a small notepad at all times and jot down your observations, for example, a dirty brown-and-white dog sleeping in the street; a programming error that prints out the message, ‘RANK ERROR,’ then crashes Windows; a tall young woman in the next cubicle wearing Jovan perfume, making the noise of sharpening a gross of pencils.

Sensors can periodically pause and ask questions about the data in front of them. Is Jack’s current coding difficulty related to Jill being on vacation? It looks like progress is slowing, why? The Rule of Three encourages having at least three possible choices before selecting one. Use your imagination and explore beyond the first obvious answer.

Storing and “re”presenting Information

We store information internally in our mind as sights, sounds, feelings, or abstract concepts. The way we store information is called our representational (rep) system, since that is how we “re”present our experiences.

Take a moment and think back to a particularly enjoyable experience you’ve had a work. What came to mind? Did you see your teammates, maybe a particularly gnarly chunk of code you to which you finally saw the answer? Were there sounds of laughter and joking? Maybe you recalled feelings of happiness?

If you primarily saw the enjoyable experience, you use a visual rep system. Recalling memories and hearing sounds involves the auditory rep system. Primarily noticing the feelings (touching) means the kinesthetic rep system is being used. Remembering abstract concepts (the lack of visual, auditory, or kinesthetic descriptions) indicates a preference for the digital rep system.

Like most preferences, no rep system is better than another. They’re simply the way the way we tend to store and recall our experiences. We can (and usually do) use all of the rep systems, but most people have a preferred way of representing what’s in their mind.

The disconnect happens when interactions become intense, and the rep systems get crossed. Suppose you say, “That doesn’t sound right to me,” and I respond with “I can see that.” We just crossed rep system boundaries. You now have to translate my visual response into its correct translation in your auditory processing. To stay connected, I could have said, “Yes, I hear what you’re saying.”

To reconnect, listen for sensory words. When words appear like bright, clear, display, see, conceal, the speaker has a visual orientation. When you hear words like asked, talk, explain, complain, harmonize the speaker has overtones of a hearing orientation.

Feeling words such as touch, soft, smooth, pressure or excitement slipping into the conversation push towards a kinesthetic, or touch preference. When you become aware of words like believe, consider, decide, know, learn, process, perceive, the speaker is using the digital rep system.

To improve communicating, try to match the sensory mode of the other person. That way they won’t need to translate words from one sensory mode into another. A good time to practice this is when you reply to email. You can scan the incoming message for sensory words, and match the rep system in your reply.

Mind Reading

“I know what you’re thinking.” You’re thinking this is a lot of new stuff, and feeling overwhelmed with the ways communication disconnects happen. Which brings us to another disconnect called “mind reading”. Mind reading works on three basic (and faulty) assumptions:

• You take in the same information I do.
• You process this information as I would.
• You come to the same conclusions and decide to behave exactly as I do.

In short, I project my reality onto you, and tell you what you’re experiencing.

The disconnect happens when we mind read, and then take action without confirming what the other person really thinks. This creates misaligned goals, actions, and often hard feelings.

A developer made a decision that I thought should have been made by the customer. When I asked the developer if he should ask the customer, he said (and you can’t make up stuff like this), “I’ve been doing this for 20 years. I know what he wants better than he does.”You can avoid this disconnect by not mind reading. Rather than assuming you know the answers, ask questions. I’ve had people become irritated when I asked clarifying questions in order to avoid mind reading. If you find someone mind reading you, you might ask them “How specifically do you know how I feel (think, whatever)?” or “What did you see or hear that leads you to that?”

Calibrating Communications

When I work with a client, I first try to understand where they get information. Do they look for data (sensors), or rather hear about how this fits in the grand scheme of things (intuitior)? Sometimes it’s not an either/or. Perhaps they need the fit in the grand scheme with supporting data.

When I supply the requested information, I try to match the requestor’s rep system. This saves time and effort since they don’t have to translate my meaning.

Lastly, to avoid mind reading, I ask how the communication went for them. Did they get what they needed, in the format they could use? If not, I have new information that allows me to change what I’m doing. If they got what they needed, I’ve avoided the communication disconnects.

convert this post to pdf.

©2005 Johanna Rothman

If you’re like most of my clients, you have too much to do. Recently, an Engineering Director, Stephanie, explained all the things she “had” to do: monitor the projects, participate in the requirements sessions, draw up a yearly budget, write three performance evaluations, monitor training classes, visit customers, assist technical support and more. Some of the items on her list were clearly her responsibility, but others were not. Her not-responsibilities were preventing her from doing her necessary work. Stephanie needed a to-do list and a not-to-do list.

Here are some signs that you need to create a not-to-do list:

• You’re always working overtime.
• You never have time to sit and think.
• You manage crises well, because that’s the only kind of management you ever do.
• You’re the bottleneck for work that’s not getting done on your project.
• Papers sit in your inbox for weeks, and you’re hopelessly behind in your email.
• You take refuge in the technical work because you’re uncomfortable with the management work you’re supposed to do.
• You get depressed looking at the ever-growing pile of paper on your desk.
• Your to-do list is a write-only list; things go on but never come off.
• You are doing more work but your manager is less satisfied with your performance.

Your not-to-do list is the list of everything that’s not part of your job to address or solve directly. Here are some suggestions for creating a not-to-do list:

Clarify your role. Try defining your job description with a one-line sentence. What does your company pay you to do? How broadly are you interpreting that? Should you make it narrower? One Director of Engineering said, “I’m responsible for the care and feeding of the engineers and the product.” He stopped allowing the salespeople and the support staff to lean on his organization, by putting training and other procedures in place.

Work at your level. Check to see that you’re working at the level appropriate for your title. Many people retain pieces of previous work out of habit after a promotion or a reorganization, rather than working at the most appropriate level If you’re now in middle management, think hard about whether you should be doing technical work. If you are doing technical work, who’s doing the strategic thinking?

Make decisions when you add value. When it’s time to make decisions, check a couple of things: are you the right person to make the decision? Are you too tired to think straight? Will you add value to this decision? If you’re the right person to make the decision, clear your head, think the problem through, and then make the decision.

Delegate or manage your paperwork. If you need administrative assistance, or filing assistance, or other paper handling assistance, ask for it. Then, deal with the rest of the paperwork. If you don’t know what to do with your humungous pile, throw the whole thing out. If someone needs something from you, they’ll be back with another piece of paper.As you decide what you should do and not do, don’t just drop things. Explain your decisions, possibly by negotiating with the people affected by your decisions. And when you make your not-to-do list practice living with it for a few weeks. See if other people are working on handling the items on your not-to-do list. If no one’s working on that list, does it matter, or will your project risks increase? If your risk increases, explain which work you’re not going to do to manage the risk.

If you’re working on issues that belong to other people, stop. Draw your boundaries, and make the rest of the people in your organization live up to their job descriptions; don’t just take on more work.

convert this post to pdf.

©2000 Johanna Rothman, www.jrothman.com

You’ve hired a candidate. She starts on Monday. What will she think at the end of her first day? Will she be in the “honeymoon” phase, or will she be disappointed with your organization?

Being a new hire is a little bit like installing a piece of software. The first thing you see when you buy software is the installation. The first thing a new hire sees is how your organization takes in people. Here are some suggestions for a smooth first day:

• Be clear on whom your new hire is supposed to ask for, and where she should go. There’s almost nothing worse on your first day, than finding out at 8:00 am that you’re a mile away from where you’re supposed to be, and you’re going to be late to start your new job.
• Get the new employee’s office ready. As the new hire, when you realize you new employer doesn’t have a place for you to sit, you start wondering whether you made the right choice of offers.
• When the candidate accepts the offer, get the person’s office ready. Include standard office furniture: a desk, a telephone, and especially a chair!
• Create a standard checklist of stationery supplies people need in their office. I’m always surprised by how many people don’t have staplers, scissors, pens, pads of paper, wastebaskets. New hires may be shy about asking for supplies.
• Create a standard checklist of electronic needs: a computer hooked up to the network, an email address, information as to where the applications live and how to compile and build the product, access the test harness, or read the documentation. If you have this all on an Intranet, create a local set of bookmarks for her browser. If you have process documentation or templates, explain where those are located. If your organization has badges, order one.

Use a “buddy” for these next suggestions. The buddy, from your department, not Human Resources, greets your new hire at the door. If your company requires an initial HR visit, have the buddy meet your new hire when her meeting with HR is over. If there’s any trouble with these next activities, the buddy can fix it.

• Identify the project information location for your new hire’s project. Show her where that information is, and how to access it.
• Create a list of people-oriented questions and their answers: where the cafeteria is; how to get supplies when you run out; and where the bathrooms are.
• Identify the employee’s project manager, if it’s not you. Have the project manager identify the employee’s responsibilities and deliverables.
• Describe how the person gets direction for technical tasks, who receives status reports and when, and what the status reports should contain.
• Describe who the other team leads are, and the other people in your employee’s team.
• Bring your new hire to lunch with the entire project team. Give her a phone list and explain who everyone is, and give her permission to forget everyone’s name a few times.

Consider also supplying a product demo; an architectural overview of the product; and the marketing material, a customer perspective of the product. If you’re developing unique technology and the employee does not have experience in that technology put together a training guide for your particular technology.

It’s not a bad idea to have the buddy for about a month — sometimes questions come up after the first day. With a buddy, your new hire doesn’t have to feel embarrassed to ask questions.

If you remember what it’s like to come in as a new employee in your company, you can start putting together the information you wish you had received on your first day. This might help keep your new employees in the honeymoon phase a little longer — maybe even long enough to refer other people to your company.

convert this post to pdf.

©2003, Esther Derby, www.estherderby.com

Josh was dumbfounded when his boss, Brad, fired him. As far as he knew, his work was just fine. But Brad believed he?d given Josh ample warning that his work and work habits weren?t up to par.

When Brad told me he?d fired Josh, he seemed puzzled, too.

?I just don?t get it,? Brad said. ?Josh acted all surprised that he was being fired. But he should have known. I told him not to watch stocks at work. And it wasn?t just that,? Brad continued. ?His other work wasn?t so great. I expect tech writers to turn over clean copy. When Josh handed in work, I always had to proof it.?

?Hmmm. That is puzzling,? I said. ?How did you give him feedback??

?Well, I was walking by his desk one day and saw him checking the stock market sites, so I asked him what he was doing. Josh closed the browser and said something lame like ?Oh nothing.? So I said to him, ?Doesn?t look like nothing to me. Looks to me like you?re checking out the markets.??

?Is that the only time you gave Josh feedback?? I asked.

?No, I gave him other feedback. I brought up appropriate Internet use at a team meeting. And I gave him feedback on his writing, but it was always the same thing. I told him, but he just never listened.?

?How?d you tell him about his writing?? I asked. I was beginning to detect a pattern.

?Well, I proofed it and handed him back the markup. Next time it was the same thing. All five chapters he worked on were the same. It was like he expected me to proof his work,? Brad huffed.

I?ll bet poor Josh didn?t have a clue he was in hot water at work.

Communicating Expectations

Brad may have been more effective, and Josh might still have his job, if Brad had followed these steps for delivering clear and intentional feedback.

Give serious feedback in a serious setting. Brad gave Josh important information in a casual manner while walking by his cube. Neither the timing nor the setting marked the communication as important. Regular one-on-one meetings are a great place to provide feedback for minor course corrections. Always schedule a separate, private meeting to address situations that are more serious.

Address specific issues individually. Brad made a general announcement outlining appropriate Internet use in a staff meeting. General announcements of policy don?t carry the same weight as an individual conversation. If it?s important enough to bring up, it?s important enough to speak directly to the person involved.

Give clear examples. Brad would have been more effective if he had said something like, ?Josh, I saw that you were checking the stock markets on the Internet this afternoon, and on Monday and Tuesday,? or ?In Chapter 1, I had to correct numerous spelling and grammar errors.? General statements such as ?your work is of poor quality? don?t provide enough specific information for people to know what to improve. Labeling statements, such as ?you?re a sloppy writer,? will set up an oppositional dynamic that is likely to go nowhere.

Check for agreement. Getting agreement on the data is the first step in problem solving. Provide concrete facts. People are more likely to accept what you say when it is specific and observable. Josh will probably acknowledge that there were spelling errors in Chapter 1; Josh is less likely to admit to being sloppy. (Of course, if the employee consistently denies the facts, that?s another problem for another article.)

Request a change in performance. While he did drop little hints, Brad never clearly communicated to Josh that he?d like to see changes. Brad could have said, ?I?ve marked spelling and grammar errors on the copy you gave me. In the future, I expect copy to be clean when I receive it.?

Engage in problem solving. Brad could have made a straightforward request for a change in performance, or he could have engaged Josh in helping to solve the problem. Brad might have said, ?Josh, I was surprised at the number of spelling and grammar errors in the chapter you turned over to me. I expect copy to be clean when I receive it. What are three ways you can make sure the copy?s in good shape?? Josh might come up with several ways to reduce errors. He?s more likely to accept the solution if he?s involved in creating it.

Agree on how you?ll follow up. Sometimes you?ll need to follow up on the changes you?ve requested. Brad and Josh could have made an agreement that Brad would skim for obvious spelling and grammar errors and return the work to Josh if he found any.

Check for understanding. Brad assumed that his indirect hints were sufficient. He didn?t check to ensure that Josh had received the message. One manager I know wraps up feedback conversations by saying, ?I?m going to check for understanding now. I?d like you to summarize our conversation for me so I can be sure I?ve been clear.?

Giving clear and intentional feedback is an important part of every manager?s responsibilities. Our employers pay us to provide timely information to our direct reports to guide and influence their work and work habits. Providing feedback effectively gives employees information that may help them improve their performance. And that means we?re more likely to meet management goals, too.

convert this post to pdf.

©2002 Esther Derby www.estherderby.com

This column originally appeared in STQE magazine November/December 2001

“There is nothing either good or bad, but thinking makes it so.” William Shakespeare?s Hamlet, Prince of Denmark, Act II, Scene 2

The other day I was skimming the Harvard Management Update when a section in bold red print caught my eye: “Why don?t more organizations stop and think? Because they don’t want to face the truth.” The article went on to say that the ability to ?face the truth? is a critical business skill, and that failure to do so can have organizational and bottom-line consequences. Does this sound familiar? You and I see these consequences in software when projects spin out of control and shaky products are shipped ?on time? in spite of poor quality.

What is ?the truth?? Truth is a big word, so let?s settle for something more mundane: the current situation or the current state.

First let?s acknowledge that organizations can?t face truth; organizations are configurations of people and can?t really act as one human person would. But we, the people who make up organizations, can grapple with concepts like truth. So why don?t we? If it?s that important, we should all face up to the current situation, right? What makes it so hard for us?

Let?s look at two projects that didn?t go as hoped for, and how their sponsors faced the situation.

Martha was a new vice president in a software company that was growing by acquisition. Martha saw an opportunity to consolidate accounting and customer functions across acquired companies. She made the business case to her boss, Ben, chartered a project she named ?One-Account,? and started the search for a project manager.

The hiring market was tight, and Martha couldn?t find anyone with the level of experience and skill she wanted for the salary she was able to offer. After interviewing a dozen candidates, she settled for a bright young man named Steve, even though he didn?t have much experience.

Pretty soon it became obvious that Steve didn?t have the skills to handle the large and complex project Martha had hired him for. Steve wasn?t able to manage scope or build even a basic plan.

?I can?t go upstairs and tell Ben this,? Martha thought. ?If I tell him, he?ll think I?m a fake and a failure. I talked him into this, after all. We haven?t actually missed any dates,? she rationalized, ?and we aren?t over budget, so we?re not really off track…?

When colleagues started suggesting that Martha needed to step in and put the project back on track, she countered by justifying her current situation. ?I really did my best to find a more experienced project manger, but Steve was the fourth person I made an offer to, and by that point…what was I supposed to have done??

The project continued to wallow as Steve frantically hired more contractors to work on the ever-increasing scope. Martha started moving resources from other projects and initiatives to cover the wildly inflating budget. ?It?s all coming from my own budget, and I?ve got the One-Account project covered, so technically we?re not really over budget,? she told herself.

Martha?s boss, Ben, looked at his current situation, and realized he had a vice president who wasn?t able to face the situation and take action. Ben fired Martha.

Several times zones away, Jackson found himself in a similar spot. His organization was building a new Web application, the first for his company. He hired a project manager, Stacey, who had a good résumé and who seemed like a good fit for the organization. She was a nice person and did a good job building the initial plan.

Jackson felt things were going okay, so he turned his attention to a problem brewing with a subsidiary elsewhere.

When Jackson came back, he found that Stacey?s project team was still having planning meetings, but there were no results or tangible signs of progress. The delivery date had been moved out. When the team talked about delivery, they were pretty vague. ?Sometime in maybe the fourth quarter,? he?d hear, ?or maybe early next year.?

?This project isn?t going the way I want it to,? thought Jackson. ?Stacey did well at the planning stage, but she isn?t able to define concrete deliverables so people can make progress. I sure like Stacey and I want her to be successful. I need to do something to put things back on track.? Jackson started by coaching Stacey, meeting with her three times a week and giving her more direction. Still, the project wasn?t turning around 

Jackson sat down and had a long talk with Stacey. It wasn?t an easy conversation for either of them. Jackson realized that he wouldn?t be doing Stacey any favors by keeping her on in a position that was turning out to be a poor fit. Stacey moved into a role where she was more comfortable, and Jackson took over management of the project.

On the face of it, both Martha and Jackson faced similar problems?an important project that wasn?t going as they wanted. And Martha and Jackson were each aware of the gap between the desired state and the current reality.

The difference was that Martha became wrapped up in her fears about what the situation might mean for her career, and her beliefs about failure. With all that emotion swirling around, there wasn?t much room left for her to think clearly about what to do. Jackson, on the other hand, looked at the facts as just that: facts?information about the difference between the current state and what he wanted. Does this mean we should suppress our emotions? No, as managers, we need to learn how to manage our own emotional state, so we can focus on solving the problem.

The current situation can seem ?bad? when things are not going the way we hoped they would. But really, the situation just is. The ability to ?face the truth? and take effective action rests on the ability to be in a mental state where our emotions and fears aren?t running us. And managers like Jackson have learned to face the current situation as neither good nor bad?it just is what it is. From that perspective, we can gauge where we are in relation to where we want to be, and take action to close the gap. 

convert this post to pdf.

©2005 Esther Derby

This article originally appeared in insights Vol. 3 No. 1

Usually, when we think about software quality, we think of
good designs, maintainable code, or low defects.
In my view, quality starts long before we start writing the software.
Quality starts with interactions and relationships.

Consider a situation I ran in to a couple of years ago.
Kelly, the team lead for the FinWiz product, worked 30 floors below Jon, the
main customer representative on the team. Whenever Kelly had a question about
how the software should work, she phoned Jon. Jon always did his best to give
an answer. As the release date grew near,
Kelly asked Jon if he would stay late and participate in conference
calls with team members who worked several time zones away.
“No way,” Jon said. “You can’t even take an elevator ride to meet me
halfway. Why should I go out of my way for you?”

Kelly had always appreciated Jon’s responsiveness, so she
was surprised by his reaction.

Jon felt as if he’d accommodated all of Kelly’s requests
without getting much in return. In his view, Kelly wasn’t interested in
learning about his work context or the way he did his job.
She only called when she wanted a specific piece of information.
Because he perceived that Kelly wasn’t interested in the challenges
he faced in his job, he wasn’t willing to help with her challenge
meeting the off-site team’s time zone difference.

Fortunately, we can improve working relationships without
group therapy or group hugs. Here are five practical ways to build and
strengthen working relationships.

#1: Build a Foundation

Most effective working relationships don’t happen by
accident. Strong working relationships start from a foundation. Take time to
establish a relationship with the people who contribute to your success.

You don’t have to be best friends, but do work to broaden
your relationship beyond ’strictly business’ transaction.
Make a point of initiating friendly contact when you
don’t need something. Go for coffee. Go for lunch.
Make conversation. Showing interest can have a big effect
in building goodwill and relationships.

Foundations are built on give-and-take. Talking to someone
only to obtain something from him or her doesn’t build a foundation.
In the example above, Kelly could have asked Jon about his work,
shadowed Jon for a day, or offered to show Jon early versions of
the software to demonstrate interest in Jon’s work.

#2: Focus on Interests Rather Than Positions

Conflict is inevitable in close working relationships.
It’s a fact of life.
How we handle the differences that show up effects our success.
Conflicts can escalate when people speak in terms of
positions and can de-escalate when people talk about
interests.

A position describes a possible solution or course of
action: “We must achieve 90% test coverage!” Positions often feel like
categorical statements?this is the best or only thing to do.

An interest describes the outcome desired: “We don’t want to
have egg on our faces after the product ships,
so we want to cover all the high-risk, high-use areas of the product.”

People often agree on interests, but disagree on how to get
there. When people are arguing about positions,
try stating the interest behind the position:
what each will gain by following the course of action he’s
arguing for. Ask questions such as “What are your main concerns in this?”
or “What problems do you see this solving?” to surface interests.

When you explicitly agree on the goal, it’s often easier to
reach agreement on the means to get there.

#3: Seek Solutions Together

Most people are much more inclined to embrace a solution
they helped to devise. Rather than trying to persuade colleagues to do it your
way, engage them in developing a solution.

State the problem you see, and ask for participation in
generating potential solutions. For example, you might say,
“I’m concerned that our tests aren’t finding some serious bugs our
customers are likely to encounter. Can we brainstorm ways to increase
our testing effectiveness in this area?”

In addition to building relationships, involving others
brings creativity and a broader range of perspectives about the problem.

#4: Communicate Face-to-Face Whenever Possible

Words are only part of communication. Humans rely on vocal
tone, body position, gestures, pacing, and facial expression to decode
communication. The more cues available, the richer the communication channel.
The richer the communication channel, the more likely that the message you
intend is the message received.

When I’m face-to-face with someone, I can see a puzzled look
or a furrowed brow. Then I can check on what’s happening for the other person
and clear up the puzzlement or misinterpretation right away.

Talking on the phone provides verbal cues, but eliminates
visual cues. Participants in phone calls can help by articulating when a
statement puzzles them. If you are leading the call, help everyone participate
by polling and checking for reactions.

Email removes visual and auditory cues. Nonetheless, I’ve
heard many dramatic readings of email that imply anger, sarcasm, or
condescension on the part of the sender.
These dramatic readings are an interpretation
of the text; the sender may have had neutral intentions. Once the
misinterpretation starts, it tends to escalate,
and the hard feelings can linger for weeks.

When you sense that a communication may be going awry,
switch to a richer mode of communication.
If you’ve been using email, switch to the phone.
If you’e been on the phone, talk face-to-face if possible.
When it’s not possible to talk face-to-face,
switch out of the content of the conversation and comment on
how the communication is working. Talking about the process of
talking can help avoid a conversation that degenerates into bickering and
defensiveness.

#5: Make a Generous Interpretation

It’s human nature to attribute our own errors to
circumstances and other people’s errors to personal failings. This little bit
of human nature doesn’t help us build strong relationships. When you see
someone else failing or acting in a way that seems foolish, give him the benefit
of the doubt. Start by assuming that the other person is trying to be helpful,
no matter how it looks to you. People normally don’t do things that make no
sense within their own frame of reference. Try to imagine what must be true for
the other person’s actions to make sense. Then ask questions to understand
where the other person is coming from. Acting out of a generous interpretation
almost always creates more possibilities for constructive interactions.

Rebuilding

If you are starting with a clean slate, it’s easy to
practice these steps for building strong relationships. But what if a
relationship is already off on the wrong foot or in conflict? It is possible to
rebuild a working relationship.
I’ve found that a simple approach works best.

Begin by clarifying what you want for yourself and the other person:
Do you want a better working relationship? What would you be willing to
do if you really wanted that?
Next, approach the conversation with statements
about yourself?”I” statements?and clarify what you want:
“I feel there’s tension between us,
and I want to have a better working relationship with you.”
Then ask: “Is that something we can talk about?”

It takes two to rebuild a working relationship. However, if
the other person’s answer is no, don’t give up right away. Create another
opening by asking:
“What would need to happen for you to be willing to talk
about rebuilding our working relationship?”
Give the other person time to process your request.

I’ve both used this approach and recommended this approach.
And I’ve seldom seen it fail. A sincere intent to improve the working
relationship?in and of itself?can help remove barriers
and soften hard feelings.

I was once in a situation where I needed to work with a
fellow, Gordon, who (it seemed to me) was avoiding me:
When I passed Gordon in the hall and said “Hello,”
he looked at the floor and didn’t respond.
When I tried to engage him in conversation,
he turned away from me. I began to wonder what I’d done to offend him.

I decided to try the rebuilding approach outlined above.
Gordon seemed relieved that I’d brought up the tension between us.
He assured me it wasn’t something I’d done,
but that I reminded him of someone he’d had difficulty with.
Even though we never became friends, the conversation helped
create a smoother working relationship.

Effective working relationships don’t happen by accident.
Consider the people you depend on for your success, and then ask yourself which
of these practical steps can help you improve your working relationships.
Strong relationships grow out of consistent attention.

convert this post to pdf.

©2007 Donald E. Gray

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

This model is the basis for most of the process control in the world. The controller compares the setpoint to the actual value.The controller uses the error information to take corrective action. If the temperature is too hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The sprint cycle overview looks like:

The outside loop is the sprint cycle (usually 30 days or less). Every sprint the product owner sees new product functionality. They compare the current product state with the target and prioritize the remaining user stories. The product owner and team select a subset of the remaining stories which becomes the current sprint backlog.Completing the sprint backlog is the goal (setpoint) for the inside loop. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal during the daily standup meeting.

A Rose is a Rose

In QualitySoftware Management Volume 1, Systems Thinking Jerry (Gerald M.) Weinberg presents the model in a slightly different picture (page 62).

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

1. Randomness. All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. I keep a list of models I use here. The list includes:

• the Cybernetic Model
• Diagrams of Effect
• Behavior Over Time Graphs
• systems archetypes
• the Satir Interaction Model
• the Satir Transformation Models
• MBTI (and temperaments)
• abstracting (Korzybski)
• abstraction (Hayakawa)
• the NLP Meta-Model
• meta-programs
• intake modalities
• the Rule of Three

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model. I may choose to use other models to help resolve the difference between my desires and perceptions.For instance, if I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, Cybernetic Model.

convert this post to pdf.

©2000 Gerald M. Weinberg, www.geraldmweinberg.com

The editor of Contract Professional chose the name for my column there, “The Big Picture.” He told me he chose the name “because you (Jerry) look at the business of contracting and consulting and the people skills involved, which translate across all skill sets and even industries” — in short, The Big Picture.

That’s flattering — but why would you want to look at the Big Picture? If you’re like me, you’re often called into an assignment because you’re supposed to be an “expert.” You know what an expert is: “someone who avoids all the small mistakes while committing a grand blunder.” So, before I get down to the nitty-gritty of a new assignment, I like to place everything in a grand array. I always make mistakes in my assignments, but this way I can hope they’ll all be small mistakes.

My favorite method of approaching the Big Picture is first to break down the question into three parts: Self, Other, and Context. In this column, I’ll start with Self — that is, the Big Picture of yourself.

Focusing on myself, I then ask three three questions I learned from the famous family therapist, Virginia Satir:

- How do I happen to be here? (Past)

- How do I feel about being here? (Present)

- What would I like to have happen? (Future)

How do I happen to be here?

Here are some Big Picture questions that make an enormous difference in how I approach an assignment.

If it’s the first assignment with this client, how did I make the connection? Was it through a third party, or through a direct contact by the client?

If it’s a repeat, what impressions did I leave the previous times I was here? Did I leave friends, or enemies? Are my old contacts still viable? What assumptions am I carrying over from the previous assignments?

Did I get the contract I wanted, or did I have to make some concessions that might come back to haunt me?

How do I feel about being here?

Am I here reluctantly? Do I have some reservations, or forebodings, about this assignment?

Am I eager to be here? Am I looking forward to the task that I’ve agreed to do?

Am I puzzled about what’s expected of me, or is the assignment clear? How sure am I of the assignment?

How sure am I of myself — of my ability to provide value for value received?

However I’m feeling, is this the right mood for succeeding in this job? If not, what steps will I have to take to get in the right mood?

What would I like to have happen?

Why did I take this assignment? For the money? The experience? The challenge? The possibility of a future reference? If I don’t have my mission in mind whenever I choose a course of action, the client may be happy with my work, but I’ll come away with a hollow feeling.

What will success look like, to me? If I come away with a pile of money but a poor reference, will I be satisfied? How about an ecstatic client who’s enormously impressed by my repeating a solution I’ve done so often it bores me into a trance?

How long do I want to be here? If the client extends the project, will I be laughing or crying?

Using the Big Picture of Yourself

By using these three questions to assess my own state before I start an assignment, I’ve enormously increased my level of satisfaction. I use them to survey my state before I agree to any contract, new or renewed. On one occasion, for instance, I found I was about to renew a long-standing contract with a nice 15% increase in my daily fee. When I checked my feeling, however, I realized that I had negotiated for the wrong thing. Much of the time on the old contract, I felt that I was doing a fine job in solving the wrong problem, and I don’t find this very satisfying. I didn’t mind the extra 15%, but what I really wanted was more involvement in defining my own assignments.

Armed with improved self-knowledge, I halted the negotiation process and asked for more leeway, which the client was only too happy to grant. I was prepared to sacrifice at least some of the 15% increase, but the client insisted that I take it. He commented, “Now that you’ll be helping do the right things, rather than just doing things right, you’ll be worth at least that much more to us.”

Self-assessment doesn’t always pay off this directly. On another renewal, early in my career, my attempt to get more leeway in defining my work led to an irreconcilable difference between me and my client. This client knew — or thought he did — exactly what his problems were, yet I felt his poor problem definition limited my ability to be successful in my terms.

At that time in my life, what I wanted most was experience with certain types of problems and a few outstanding references. On my first assignment with this client, I had helped solve a problem that didn’t vaguely resemble what I really wanted to work on. And, though the solution was innovative and successful, it didn’t really help the client with his true problem — since he was working on the wrong problem to begin with. He attributed his lack of satisfaction to some unspecified shortcoming in my work, and was reluctant to give me a sterling reference.

And, of course, he was right. The shortcoming in my work was my failure to assess the Big Picture — both his and mine — before I took the assignment. As we negotiated for a follow-on, the three questions show me that the extra money he offered wasn’t adequate to overcome my bad feelings about working with him again. Negotiations broke down, but at least I didn’t waste another six months of my life struggling for something I didn’t really want.

It took me a few weeks to get a new assignment, and that cost me a few bucks. The cost is long forgotten, but I still savor the memory of my satisfaction with the new assignment — what I learned, what I earned, and how it put my professional life back on my own track.

Questions and answers

Q: It’s all very nice to say that I ought to be centered in myself before I make big decisions, but whenever I get into some sort of negotiation, I lose track of myself, what I want, and what’s good for me. What do you suggest?

A: This is too big a question to answer entirely, but the first part is easy. When you first notice that you’re starting to lose yourself, STOP whatever you’re doing. Then concentrate on how you’re breathing, and switch to smooth, regular breathing.

Q: I’ve tried the breathing thing, and sometimes it works. But sometimes it doesn’t, like when another person is blasting at me in a loud voice. What should I do?

A: If you can’t get your breathing under control, find a way to leave the situation. If you wish to continue, come back later. If you find yourself unable to leave, then that’s a sure sign you must leave, now, and not come back. This is not the situation for you.

convert this post to pdf.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

I’m not the kind of person who hangs out in nightclubs. In fact, the last nightclub I can remember visiting was in Miami Beach in 1957. What I remember about it is what the stand-up comic said.

After warming up the audience with some rather gross remarks, he commented that early in his life he had learned the motto he had lived by every since:

Sound mind; sound body …
… Take your choice!

How funny to hear it articulated so clearly, but many of us did make this choice early in life. Somehow we got the impression that athletes are stupid and software developers are flabby – and that we must make choose one or the other. Actually, though, a reasonable level of physical health increases the effectiveness of my intellectual work. Increased effectiveness then produces more slack time in which I can pursue healthy practices. So, good health tends to produce better health, at the same time that it produces better mental health.

But this syndrome works both ways. Poor health tends to produce poorer health by diminishing work effectiveness, which in turn causes work to pile up. Piled work causes me to overwork, consume junk food in haste, and generally ignore my physical well being. Eventually, my health becomes even poorer, and the cycle continues unless I can manage to break it in some way. I become, literally, stupid – “in a stupor; deficient in alertness; lacking in the power to absorb ideas.”

But this kind of brain dysfunction is merely the grossest kind – akin to the effects of being struck on the braincase by a piano leg. The brain is a complex problem-solving device whose functioning we still only vaguely understand. We know that the piano leg will put the brain out of commission, as will sickness. But we also know that a computer can be put out of commission with a sledgehammer, or by pulling the plug. What interests me now is some more subtle elements of my brain. Those subtle elements make people want to hire me as a consultant, treat me like royalty, and pay me large sums of money.

My interest in subtle brain factors drew me to reading an article about “personal chemistry.” The author’s list suggested some of these success factors:

Articulate: writing and speaking fluently in at least your native tongue.

Thoughtful: weighing a question for a few seconds before responding.

Bright, informed, sparkling: difficult to define, but obvious if a person doesn’t have it.

Breadth of interest: able to carry on an intelligent conversation without permitting embarrassing gaps because of lack of interest or education.

Unfortunately, the author seemed to suggest that you can somehow wipe a veneer of “chemistry” over your otherwise dull, boring self. For instance, he says, “brief reflections give the impression that you have good judgment” – not good judgment, but the impression of good judgment.

At this level of analysis, brain chemistry consists of a set of rules. For example, “count to three before you answer a question, so people will think you are thoughtful.” In the typical steamy working environment I usually encounter, however, this kind of veneer peels quickly, revealing all my ugly lumps and hollows underneath. No, if I truly want to be more articulate, thoughtful, bright, informed, and sparkling, rules won’t suffice. I have to devote some time and effort to the job.

My acquaintances who don’t work with computers tell me that software people are the dullest people they know. I have a hard time believing this assertion. We all know that computers aren’t dull – they are an endlessly fascinating subject. But let’s face it. There is more to life than computing, and more parts to our brains than those we use in our professional work.

At AYE Conferences, I’ve repeatedly seen that problem-solving behavior becomes stereotyped when people work in a closed situation. Once they find one or two tricks that work well, they tend to adopt those to the exclusion of all others. I wish we presenters could take more credit, but most of the effectiveness amplifying that takes place at AYE seems to come from exposing the participants to the problem-solving styles of other participants.

My consulting problems are growing more difficult. Systems are growing more complex; needs are growing more demanding; because of past successes, my expections run high. If I remained at the same level of problem-solving effectiveness, I’d soon accumulate a deadening backlog of unsolved problems. With a little slack time, I have some possibility of “outside” activities that stimulate those parts of my brain I don’t ordinarily exercise at work. Without such activities, my problem-solving effectiveness would grow ever more narrow and specialized. New problems would then become unsolvable problems.

My brain is a muscle. Like any muscle, it requires stimulation to remain healthy. If I’m locked into a pattern of work, work, and more work, my brain soon stagnates. Paradoxically, if I want to be more effective at work, I must be less single-minded in my devotion to work. Anything I do that stimulates new segments of my brain will make me a better programmer, or tester, or analyst, or manager, or writer, or consultant.

Many technical folks, seeking this kind of stimulation, enroll in university courses. Some are successful, but some are not. Perhaps the course is dull – not stimulating at all – yet they persist because their employer is paying the tuition and they are embarrassed to quit.

Or, the course may be too “relevant” to their work – more of the same bland diet they consume every day on the job.

If you want to keep your brain healthy, you might do better seeking your stimulation outside the formal education system. For instance, change your TV-watching habits, not necessarily to something more “intellectual.” Or, if you never watch TV, a little tube time might prove a stimulating change. If you don’t read anything but manuals, pick some paperback at random on the way home and read it – but stop if it’s dull.

If you read frequently, read something different. Or, stop reading for a few days and just open your eyes and ears and nose to the world around you. I find that natural settings always make my brain sparkle.

If you must attend courses or conferences, participate in something your employer would never pay for. That way, you can quit if it’s dull and move onto something healthier for your brain. Sound mind; sound body – it’s not a choice, it’s a mandate.

convert this post to pdf.

©1999 Gerald M. Weinberg

External consultants are seldom sent to classes by their customers, but often pay for their ownprofessional development. As such,they’re eager to get full value for their time and tuition.

Moreover, external consultants often find themselves as instructors in classes, in which case, they’re also interested in making sure the class goes well.

But not all classes go well, and often it’s because the mix of participants isn’t ideal. Or, to look at it another way, it’s because the instructor doesn’t know how to handle certain kinds of participants.

Our Problem Solving Leadership workshops are designed for professional development – specifically, to develop leadership abilities in the participants. Because leadership means so many things to so many people, our participants arrive with different expectations, so one of the first things we must do is clarify why each participant is in the room.

Over the years, I’ve seen students who fall into four categories – Customers, Learners, Visitors, and Complainers.¹
Each type of student requires a different approach from the instructor.

A Customer is someone who arrives with a particular problemto solve, for themselves or concerning some other person(s) or situation.If a student is a Customer, it’s possible to gain a relatively cleardescription of this problem. Here aresome examples of Customer problems brought to our PSL Workshop:

“I want to communicate better with my customers when they are trying to tell me
their requirements.”

“I want to do a better job facilitating meetings.”

“I can’t handle my boss when she criticizes my work.”

“My teammates often don’t listen to my ideas,so that they misunderstand them and reject them.”

“I’m putting together a new project team, and I want to do it without making the
same mistakes I made last time.”

The participant as Customer quite clearly wishes to do something about this problem and is seeking help from the class and the instructor. All the instructor has to do to satisfy the Customer is offer a high-quality class. Most instructors wish for a class composed entirely of Customers, but it’s never that easy.

A Learner is someone who comes in without a particular problem to solve, but just wanting to learn whatever the class has to offer.Typically, Learners may state their objectives in ways such as these:

“I heard this was a neat class, so I wanted to learn what you had to offer me.”

“I’m interested in teamwork and how to build teams.”

“My best friend at work took this class and wouldn’t tell me anything about it except that I should come and learn whatever I learn.I like that idea.”

“I’d like to improve my problem solving skills (without mentioning any particular situation).”

Learners are fun to have in class, because they gobble up everything the instructor has to offer. They never ask that hard question the Customers may ask: “What’s the relevance of what we just learned to so-and-so.”

Nevertheless, they can be a danger to the class because they may drift off in any direction just because it catches their fancy.If the instructor gets distracted by Learners, the Customers start getting angry because they’re not getting what they came for.

A Visitor is an uncommitted participant, often involved in the class under some kind of duress, implicit or explicit, and usually because of the concerns of some other person. Typical statements by Visitors might be:

“My boss told me I needed to learn whatever this class teaches.”

“My company bought three seats in this class, and someone cancelled one of them, so they sent me to fill the empty seat.”

“Everyone in our department has to go to this class.”

“I can’t get promoted unless I’ve taken this class.”

The Visitor has no agenda to participate in class discussions, and works on any exercises in the most minimal way. Attempts by the instructor to improve the Visitor’s participation are likely to be fruitless or to lead to “resistance” that can be disruptive to the whole class.

Trying to capture the interest of a Visitor can easily distract the instructor from paying attention to others in the class who are not Visitors.

Instructors need to treat Visitors respectfully, always being open to their contributions, should they decide to start making them. If Visitors do contribute, honor their contributions with complimentary (but not effusive) feedback.Until they volunteer to contribute, however, avoid soliciting their participation or trying to assign them tasks.

They have to make their own choice to transform themselves into Customers, or at least Learners.

A Complainer does have a particular problem (or list of problems), specific or vague, either concerning themselves or about some other person(s). The Complainer’s problems may resemble the problems brought by the Customer, but it’s not clear that the Complainer actually has any wish or hope that these problems be solved. Often, the instructor can distinguish the Complainer from the Customer by the whining, helpless tone in which the Complainer presents these problems – often repeatedly.

Complainers don’t really believe that their problems can be solved by this class, or possibly even solved at all. Therefore, they should be treated initially as Visitors, with empathy. If they display any hope that something can be done about their problems, that’s the time to get them engaged in the class. Often, this display of hope comes in the form of a tentative question that doesn’t refer directly to the Complainer, such as,

“Could this technique be applied to dealing with a boss who doesn’t appreciate your work?”

“But this technique couldn’t be used on a project under heavy schedule pressure, could it?”

Understanding and recognizing the four types of participant is obviously helpful to you when your job is to instruct a class, but what good does it do if you’re a fellow student? And what if you’re not in a class, but just a plain vanilla contract professional working on the job?

As a consultant,I’m seriously interested in my education. When I attend a workshop, I want to get my money’s worth – because I’m paying my own tuition and I’m usually not getting paid for my time. (Sometimes I can get my client’s to pay me for attending a workshop, but that’s a subject for another column.)

Therefore, whenever I’m in a workshop, I watch my fellow students just as I would if I were the instructor. If they’re Customers, I watch to see that they’re shopping for the same learnings I am, because if they’re not, they may steer the workshop into areas that are not related to what I’m shopping for. If they do, I may suggest something to the instructor, such as, “I see that you and Val have a deep interest in this subject, but it’s not my main focus right now. Would you be willing to continue off line with those who are really interested?”

If some of my fellow students are Learners, I cautiously enjoy their excursions into the unknown, because I’m always partly a Learner myself. I do my best to protect them from overfocused Customers (including me), while at the same time keeping my own goals in sight. If necessary, I try to steer things gently, as by offering, “Thank you for that wonderful exploration. I was fascinated, and could probably spend all day exploring it. But I wonder if we couldn’t come back to the subject of …”

If the instructor has a Visitor or Complainer to cope with, I consider myself a junior partner of the instructor and try to help out, generally off line during breaks. This role comes naturally to me, since we usually lead our own workshops in pairs – one instructor “on stage” and one ready to handle Visitors or Complainers one-on-one outside of the classroom.

For example, in a recent workshop, one of the Visitors was using one of our breaks to try to recruit other students to his cause by convincing them that the workshop was a waste of time – which, of course, would make his boss look like a fool for making him attend. Once I recognized that he was a Visitor, it wasn’t very hard to turn the subject toward his problems with his boss, and away from deprecating the very professional job my co-instructor was doing. Eventually, he realized that he had a choice between spiting his boss by learning nothing, or spiting her by actually learning some things that made him a better professional.

And speaking of professionals, I don’t spend most of my time being a student or instructor, so what does all this have to do with my day-to-day work? If you’re a regular reader of this column, perhaps you know by now that I always have my own learning in mind when I negotiate an assignment. I firmly believe that when I stop learning, I’ll stop being a professional – so, I’m always a student.

Yes, I’m on the job to earn money by helping my client, but I’m also there to learn, so I’m always on the lookout for Customers, Learners, Visitors, and Complainers among my co-workers. I believe that any worthwhile high-tech assignment is too difficult to be accomplished without constant learning by all participants, so I’m always working to enhance the learning environment, for me and for the others.And, one more thing.

Like anybody else, I, too, am susceptible to these stereotyped behaviors:

• becoming too focused on just the immediate job at hand (Customer);
• drifting off the subjectinto interesting side tasks (Learner);
• detaching myself from the importance of the assignment (Visitor);
• feeling powerless and whining about everything and everybody (Complainer).

None of these roles enhancemy performance on the job, so I always try to watch myself, too – and bring myself back to a more professional and effective role.

---

¹ At the suggestion of David Schmaltz, one of our PSL instructors, I adapted these categories from my teacher and colleague, Bill O’Hanlon. See, A Brief Guide to Brief Therapy byBrian Cade and William Hudson O’Hanlon ©1993 by Norton in NYC.

convert this post to pdf.

©2003 Johanna Rothman www.jrothman.com

Jim, a new project manager, struggled to define the project?s parameters: schedule estimate, people estimate, requirements outline, and necessary capital equipment. Jim proudly walked into his manager?s office, and proceeded to walk through his project plan discussing these numbers:

64.1 calendar weeks

12.125 people

ROI (return on investment) of 7.5 months

Jim?s manager, Dave, stopped him, smiling, and said, ?So, Jim, where?s this .125 person coming from? And what?s .1 of a week?? Jim was a little stumped, and said, ?Oh, I guess we?ll borrow someone else. I thought you?d want to see a project plan with the fewest number of people. One-tenth of a week is part of a day.? Jim?s manager said, ?Well, we only have whole people, so I need a plan with either 12 or 13 or whatever you think the right number of people is for this project. And, while you?re at it, although I would love to plan a release for a Monday at 9:37am, we both know that?s not going to happen. Please work up an estimate that?s more accurate, but not as precise. And, while you?re at it, show me our options?how many people for how many weeks, giving me ideas for how we would staff a shorter project with more people and a longer project with fewer people.?

Precision is the exactness of the measurement, the number of decimal places. Accuracy is how close you are to the estimate. When I worked with robots, precision meant how close to a specific place in space we could move the robot arm once. Accuracy meant how many times we could make the robot arm move to that precise place. Jim?s estimate was certainly precise, but estimates are more useful when they are accurate, close to the mark. Projects are composed of numerous predicted estimates, so we can?t expect accurate estimates, except to an order of magnitude. Over time, you can learn how to estimate so that your estimates (predictions) are close to your actual schedule.

When you talk about estimates, you?re in much better shape if you choose accuracy (how close you are to the prediction) over precision (exactness). As you move closer to accomplishing milestones, you can re-estimate with greater precision.

One way to discuss a schedule estimate is to deal with a range. Jim could have said, ?I?ll need 13 people for about 64 weeks. Or, I can do this project with more difficulty if I have 20 people for about 50 weeks. Or, if we take out this specific performance requirement, we?ll need 18 people for about 48 weeks.?

Each of the ?abouts? in the previous sentence exists for accuracy. Schedule estimates are just that, an estimate. In my experience, putting an ?about? in front of a schedule estimate is more helpful than a range (?62-65 weeks?). I?ve met too many senior managers who don?t hear the second number, just the first. When I use an about, I can choose a number that makes sense to me to use to senior management.

However, some of you work for managers who prefer a range of estimates, with a confidence for each point in the range. This is particularly helpful if you use a graph to explain your confidence. (see Figure 1.)

Figure 1: Estimates: Precision vs. Accuracy

The graph is a vehicle for starting the discussion about why you have how much confidence when. You can explain why you only have 50% confidence that you will meet the 3/1 requested release date, and you can explain why your confidence improves over time. With this graph, you?ll especially want to explain the difference in confidence between 6/1 and 7/1. The project manager who generated this graph was concerned about the amount of rework (problem finding and fixing) at the end of the project, and wasn?t absolutely sure the project team could finish the rework for 6/1. When he explained how the last three releases had used more than the planned four weeks, his management understood why his confidence level was less than 100% for the 6/1 date.

If you have a sponsor who says, ?Just give me a number, and give it to me now,? you have numerous choices about the date you provide. You can choose a date somewhere in your range, depending on how risk averse you are. Frequently, sponsors who need dates without a discussion of estimates really do want just a date you can promise, not the first possible date the project could be ready if Murphy?s Law didn?t come visit your project and all the planets were aligned. If your sponsor is not willing to use the date you provide, you?re dealing with the ?Bring me a Rock? game. If you have a sponsor who appears to not be willing to consider why you don?t have a date, you have several options: make an appointment to talk about project schedule estimates; discuss your sponsor?s concerns and what matters to your sponsor; or find a new sponsor or new organization.

Choose some technique, ?about? an amount of time, dates with confidence attached, or a date in the middle of your range, to help your project sponsor see that the schedule or the budget or the ROI, or whatever number you?re discussing is an estimate.

Be precise at the end of a project, when you file your project information, and manage the data that was part of the project?s outcome. In the meantime, be as accurate as you can, by using approximations, ranges, and ?about?. Jim now works for accuracy at the beginning of his projects, and precision at the end.

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.

©2003 Johanna Rothman, www.jrothman.com

Does your staff look forward to flu season so they don’t have to attend your group meetings? Are you looking for ways to escape your manager’s meetings?

Boring group meetings tend to be a result of inadequate agenda-setting and facilitation. The bad group meetings are just status meetings, one-on-one’s between the manager and whoever is talking. Even donuts don’t help a meeting like that.

Group meetings don’t have to be that boring or awful. They can be a technique for teambuilding, for increasing the group’s knowledge, and for problem solving. To do this, you have to have an agenda and an environment that supports group work.

If your group meetings boring or not useful, and you’re not sure what to do about it, try an agenda like this:

1. Spend five-ten minutes on juicy information such as: corporate information, cross-department news, company gossip, and rumors. This is the time to spread good news and find out what other people think is going on. Managers can listen to what their staff thinks is important. Staff can talk to their managers about their concerns. Consider adding appreciations?”I appreciate you John, for taking the time to calm the marketing manager down. I was busy, he was ready to go beserko, and you took the time to help determine what his concern was, and then you started the problem solving. Thank you.”
2. Take five minutes for someone to review a thorny problem they solved or would like help solving. Or, ask for new information that others may have about their projects.
3. Use the next ten-thirty minutes on “the issue of the week.” If you are just starting group meetings, or if you want to restart them, one way to generate issues is to ask, “What do we need to do, and who do we do it for?” That question will spawn a list of issues for your group: who does what for whom, and what the obstacles are. Plan to reprioritize this topic list, as one of the issues of the week.
   • Facilitate the meeting, by choosing a facilitator and a note-taker for each meeting. (This is also a good way to help your staff build facilitation skills.)
   • Make sure the facilitator ends the meeting on time.
   • If you’re done discussing the issue of the week, end the meeting early.
4. Use the last few minutes to wrap up. Either close the discussion, or plan how to carry over the discussion to the next week.

That’s it. No boring meetings, no individual one-on-ones. And you don’t need donuts to enjoy this kind of a meeting. Send out the agenda before the meeting. Make sure the note-taker sends the notes out within a day, and you’ve got a recipe for successful meetings.

convert this post to pdf.

This article is an excerpt from Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People, (Chapter 9: Planning and Conducting the In-Person Interview, p. 182-184) by Johanna Rothman. Published by Dorset House, 2004.

Part of managing the interview is making sure you hear the candidate?s answers ? and questions. In this excerpt, Johanna Rothman explains how to listen to candidate’s answers, how to evaluate a candidate’s answers, and when to consider replanning the interview.

######

Listen to and evaluate each candidate’s answers.

During the interview, practice your active listening skills. Here are some guidelines for active listening in an interview:

1. Stay in the moment. [Hacker, 1999 #8], p.87 Focus your listening on what the candidate is saying now. If you find yourself thinking about something else, make a note if you must, and return your attention to the interview. When I interview people, I use the physical act of closing the door to also mentally close the door in my brain to the problems I’ll have to return to at the end of the interview.
   
2. Maintain your alertness. If you normally run from one meeting or issue to another, you may find it difficult to stay in one place for the interview. If so, consider these techniques: Dress in layers that can be added or removed so you can keep comfortable during the interview; keep water or other non-sugar beverages available to perk yourself up if you feel drowsy or inattentive; do whatever you can to get a good night’s sleep the night before the interview. There are, of course, other techniques that you can use, but these are a good start.
   
3. Allow the candidate to complete their thoughts and sentences. Some candidates speak more slowly than others. Some candidates continue thinking as they talk. Don’t interrupt the candidate, so you can hear everything the candidate has to say.[Rosse, 1997 #11], p.179
4. Encourage candidates to complete their stories. Sometimes, candidates tell a story only part of the way, thinking you’re not interested or the details are not relevant to the position. If you think there’s more to the story, say, ?I bet there’s more to that story. Tell me more.?
   
5. Restate what you thought you heard. Use this technique when you want to check your understanding, especially if you think you heard something that appears outlandish or even merely somewhat unusual. If, for example, a candidate states, ?The project was the longest three months I ever spent,? ask him or her to tell more about the experience. If you don’t understand what point is being made, say something like, ?I think I heard you say the role of the release engineer is to rename everyone’s variables. Is that what you said, and if so, what exactly did you mean??
   
6. Summarize the major points of what you heard. ?So what you liked best about your last job was the pair programming. The product technology wasn’t that interesting, which is why you’re looking for a job. Did I get that right??

When you actively listen, you can evaluate how the candidate answers and the quality of the answers you hear. Table 9-2 presents a checklist you can use to evaluate a candidate’s answers during an interview.

Table 9-2: Questions to Ask Yourself About a Candidate’s Responses.

Question	Interpreting the Answers
Is the candidate talking about real experience?	Does the candidate talk about past projects and past behavior when answering the behavior-description questions? Or does the candidate answer in a hypothetical way: ?Oh, if I were going to manage a project, I would do it like this ??
Does the candidate appear to have limited experience?	Sometimes candidates have the same number of years of experience listed multiple times, continuing to work the same way at each job, never learning more or stretching themselves. Use your behavior-description questions to ask what was the same and what was different about each project or each job.
Are you talking too much?	I estimate that I spend a minute or so asking a question that takes a candidate about four to five minutes to answer. If you?re talking more 20 percent of the time in the interview, consider why. Are you asking closed questions? Are you leading the candidate to the answer you want to hear?
Is the candidate hijacking the interview?	Is the candidate taking over the interview and not answering the questions you want answered? Sometimes the candidate is a talker, and you may need to interrupt to restate your question or bring the answer back on track. If you have to interrupt the candidate more than once, note the kinds of questions you interrupted the candidate on. You’ll want to compare notes about the candidate with the other interviewers to see if they had this problem also.

While listening, you may decide that you need to guide the interview in another direction. Replanning the interview is fine. I recommend that you check the interview pace about halfway into your time and make sure you’re covering the topics you need to cover. If you’re behind schedule, see if you can focus your questions more tightly. If you’re ahead, try to encourage the candidate to speak more about his or her experiences.

Answer the candidate’s questions.

Leave the last two to five minutes of the interview open for the candidate to ask you questions. Some candidates will have questions; some won’t. If the candidate has questions, answer them to the best of your ability, always telling the truth. If the candidate has no questions, suggest that he or she take your card to call you later if any questions crop up. Between interviews, a candidate may wish to use the restroom or get something to drink, so be sure to offer these options.

convert this post to pdf.

©2005 Johanna Rothman.

This article originally appeared on stickyminds.com.

I’ll bet you’re one of those people who have too much to do. (I haven’t met anyone in the past few years who didn’t have too much to do, so it’s not much of a bet.) And, I suspect that you’re so busy with what you’re doing, that you haven’t yet thought of what you should not be doing.

A not-to-do list is as important–if not more so–than a to-do list. When you make a to-do list, you’re listing, categorizing, and prioritizing all the work you need to accomplish. But with a not-to-do list, you’re first thinking about why you are working, and ensuring that you’re accomplishing the strategically important work.

I recently worked with a Chief Technology Officer (CTO) who, aside from his CTO role was also acting as the development and testing managers, until he could hire people for those positions. As a short-term tactic, that may have been OK. But while he was acting as the manager of both groups, he was unable to perform his job as CTO. After three months of attempting to act as all three managers, he realized that he was not working well enough in any of the three roles. Because he was trying to perform all the work himself, he’d made it impossible to take the time to hire the people he needed to help the organization run smoothly.

Taking on too much work isn’t limited to senior managers; it’s just as much a problem for other managers. One test manager prided himself in his ability to be a team player–by taking on each project, regardless of whether he had the testers or time to do the testing. He assigned testers to every project, even if he wasn’t able to plan for staffing the project in advance-and whether or not his staff had enough time to devote to each project. He soon found himself in the position of assigning each tester to at least three or four projects. Because each tester was always context switching, the testers were unable to make progress on their projects. Soon, testing was a bottleneck, and the testers were assigned to each project later and later.

Technical contributors are just as susceptible to the problems of too much work to do and not enough time to do it. One developer I know somehow hadn’t managed to take long weekends or a week of vacation in three years. He was always too busy, adding a feature here, fixing something there, developing a tool for someone. Sure, all of his work was valuable, but it wasn’t necessary at the time he performed the work. A month ago, his wife discovered he was about to lose all his vacation time. So she packed a suitcase, dropped the kids off at the grandparents, and “kidnapped” him from work. On the way to the airport, she locked the cell phone and pager in the glove compartment and told him he’d better relax and enjoy the vacation!

There is always more work you could do. And there will never be enough time to do it all. The key to successful work is to pick and choose which work to do and when.

When you’re planning your work, ask yourself these questions:

1. What does the organization pay me to do?
2. What work helps me fulfill that mission?
3. What work is important to the organization, but should not be done by me?
4. What work is not needed by the organization?

Your first responsibility is to perform the work the company pays you to do–your mission. In the case of the CTO, filling in as the acting manager for a week or two, or maybe even a month, while recruiting for the open positions may have been a great idea. But as the CTO, his mission was to make sure the management work was accomplished, not do it himself. He would have been better off determining another way to manage the work without attempting to act as the development and test managers for three months. The previously mentioned, beleaguered test manager was initially confused with his mission. He originally thought his mission was to “fully test all the software.” But that’s an impossible mission. He revised his mission to “test the riskiest products in restricted time.” That mission allowed him to assign staff to the products with the highest risk, and to time-box their testing work, so people were available when they were needed for the next project.

Once you know your mission, you can look at all the work on your to-do list and determine if the work on your list helps you fulfill that mission. It’s all too easy to keep parts of older roles (before a promotion or a move in the organization), or to help a colleague around the company. But your first job, especially if you have too much work to do, is to ask yourself if each and every item on your to-do list helps you add value to the organization in your current role.

The CTO adds more value by acting as the CTO rather than as the development and testing managers. The test manager adds value by determining which projects to staff and which projects not to staff.

If you’re like many people, you have work on your to-do list that needs to be done. But if it’s tangential to your mission, someone else should do it. You may have started performing this work because someone needed it and you were the “go-to” person. Early in my career, before the days of reliable FTP, I babysat large file transfers to remote sites at particular times of the week. After a few months of doing this, I told my boss I couldn’t attend a meeting he wanted me to attend because of the file transfer. He explained to me that although this work was necessary, I was not the person to do it. That work didn’t require my skills and attention. The work was necessary, but I wasn’t the one to do it. If you still own work that doesn’t fit anymore, work with your manager to transition that work to someone else.

When I perform assessments, I inevitably find someone accomplishing work that is no longer needed. Sometimes the work is generating reports. Other times the work is a standing meeting. But whatever the work may be, the organization no longer requires that work. Once you recognize no-longer-valuable work, you can cross it off your list without worrying about who will pick it up.

Planning, organizing, prioritizing, and performing your work is not trivial. Take a few moments to think about the value you provide to the organization, and how to reflect that value in your to-do and not-to-do lists.

convert this post to pdf.

©2003 Johanna Rothman, www.jrothman.com

The project retrospective was proceeding nicely. We’d had lunch, and we entered the mid-afternoon low-energy lull. I decided it was time to change gears for a few minutes, to move the energy back up a couple of notches, so I introduced appreciations.

Appreciations are a special form of thank you. They take the form of:

I appreciate you [the person's name] for [a specific action].

A second optional part that I suggested the participants include is:

[What that action meant to you].

If you’re in the same room, you can walk up to the person, look them in the eye, and express the appreciation. For some people, that seems too emotional, not a work statement, so I make that part optional. But, if you want people to continue repeating beneficial behaviors, include the what-the-action-meant-to-you part.

This project team had no trouble appreciating their colleagues. Here are some of their paraphrased appreciations:

“Hermione, I appreciate you for insisting that we estimate the project assuming we only had 4 work days each week. I had an estimate that was amazingly close to the actual schedule. That’s never happened to me before.”

“I appreciate you Ron, for thinking about the project and testing intelligently. I’ve worked with testers who didn’t know about our projects, and not had the benefits I wanted from the testing. You found things I didn’t know I’d put into the code.”

“Harry, I appreciate you for playing basketball with me when I couldn’t think about that part of the design anymore. You helped prevent me from designing garbage.”

“I appreciate you Dumbledore, for reviewing my first draft architecture write-up so quickly. Because you reviewed it quickly, I was able to reorganize it, and our customers really like the way the product is organized now.”

Notice how appreciations are different from typical corporate thank you’s. Here’s a typical corporate thank you. For best effect, read this with a deep blustery voice, “On behalf of the senior management team, we thank the Foosis project for their time and effort. Great job everyone!”

Nothing personal about that thank you. What did the Foosis team do? Is the company going to use it? Did it make a difference?

When you appreciate someone, you’re thanking a specific person for a specific action, and explaining how that action was personally valuable to you.

Not bad for one or two sentences, eh?

(I appreciate you J.K.R., for creating such wonderful characters that engage and encourage reading by all ages.)

convert this post to pdf.

©2001 Don Gray and Dan Starr

Near the Blue Ridge Mountains in North Carolina, not far from where you think it should be, there really is a town called Mayberry.

Although the main highway bypassed the town years ago, the namesake for the popular 1960s television series is still a bustling community, and a fair amount of traffic enters Mayberry’s downtown from the north on the US Highway 52 business spur every morning. In town for a week of consulting work, we were able to observe the recent road construction along that route and watched a trio of local citizens demonstrate their own unique administrative styles. Let’s take a look at how these characters traffic management closely parallels common styles of software project management.

When road work just north of town closed Business 52, all the traffic entering town from the north had to take the 52 bypass around to the west side of town and enter the downtown on Key Street. Unfortunately, this meant traffic would have to make a left turn onto Key Street, crossing fairly busy east-west traffic (see Figure 1).

The town council feared that during the morning rush the traffic waiting to make the left turn onto Key Street would back up on the southbound off-ramp all the way to Highway 52 itself. This could cause a serious accident, since Highway 52 has a 65 mph speed limit. So the council decided to station one police officer and one or two rescue squad volunteers at the intersection to make sure that traffic on the ramp did not back up.

Three Approaches to Managing

Being a take-charge guy, the officer on duty (we?ll call him Barney) arrived at the scene Monday and quickly sized up the situation. He decided that what was needed was a traffic light at the intersection of Key Street and the ramps. Since it would take the county months to approve a light, he decided to operate as a “human traffic light,” directing traffic manually. Each direction got its turn: westbound Key (including left turns onto the southbound ramp), then eastbound Key (including right turns onto the southbound ramp), then the off-ramp (which could turn either way onto Key). Barney?s plan didn’t actually work all that well. Traffic stalled in both directions on Key Street. And there were a couple of close calls on the ramp; traffic backed up almost onto Highway 52 once when Barney let a few cars turn left onto Key Street. By the end of rush hour he was hot, tired, and a little discouraged, and he had written a fistful of citations to drivers for making unmentionably rude gestures at a law enforcement officer.

On Tuesday, one of the rescue squad volunteers (a helpful local woman known as Aunt Bea) said she knew how to take care of the situation. She figured that traffic could probably take care of itself as long as drivers didn’t have to cross each other?s paths. So she let traffic go both ways on Key Street, and let people make right turns onto and off the ramps. When somebody had to turn left, she’d stop the other lanes and let them go. Aunt Bee’s approach worked better than Barney’s (at least nobody made rude gestures at her), but there was still a lot more congestion than we expected, and by the end of rush hour Bee was glowing profusely.

On Wednesday Sheriff Andy showed up, bringing a lawn chair and a thermos of lemonade. He set up the lawn chair on a shady spot from which he could see the intersection and a fair way down the off-ramp, and sat down to sip lemonade. When traffic started to back up on the ramp, he got up, stopped Key Street traffic, and let the ramp empty; then he went back to his lemonade. Other than that, Andy pretty much didn’t seem to do anything. Despite his apparent inaction, the intersection just seemed to work. People were calm and relaxed, with the drivers making right turns creating breaks for others making left turns, and everything worked a lot like it did before anyone showed up to help?just a little better.

Putting on our consultant hats, we realized we?d just witnessed three distinct styles of management?Barney’s micromanagement, Aunt Bee’s motherly management, and Andy’s masterly management. Since these styles are also common in software project management. Let?s look at each of them in more detail, and see what we can apply to our own software projects.

A Question of Style

Each of our managers made different assumptions that shaped their style?in particular, assumptions about the people being managed, and about the role of the manager. These assumptions determined how they approached the critical activities of managing. In his book, Quality Software Management, Vol. 1: Systems Thinking, Jerry Weinberg highlights five critical activities:

1. understanding the problem to be solved,
2. planning the solution approach,
3. observing what the people being managed are actually doing,
4. using rules and process models to determine what to do next, and
5. taking action to guide the group toward its goal.

Together these activities form a feedback system that ?steers? the project team. How they are executed (i.e., what the manager defines as the problem, how the manager plans, what observations get made, which rules get followed, and how the corrective actions get taken) makes all the difference?determining just where the team will go, how the team members will feel about the software project as a whole, and ultimately how satisfactory the results will be.

Micromanagement

Barney practiced micromanagement, which is based on the assumption that the manager has to see to it that everything gets done. Most micromanagers don?t deliberately meddle out of a need to be in control; they?re just operating under the assumption that if they don?t do it, it won?t get done. Micromanagers also tend to make the related assumption that those being managed will do what they?re told to do; no more, no less.

These assumptions describe machines better than they do humans. Indeed, when Barney said we needed ?human traffic lights,? he was describing a situation in which both the manager and those being managed were more mechanical than human. Perhaps this is why so many good programmers become micromanagers when they get their first promotion?they?re just ?programming? the ?bio-robots? who work for them!

Using Weinberg?s model, we can see how Barney?s assumptions defined his view of the critical management activities:

1. The problem to be solved was to personally make sure everything was done in an orderly fashion.
2. The plan that followed was for Barney to pretty much do everything himself. He would personally direct the movements of each and every vehicle. This meant that the plan had to be simple enough that he could be in control of its execution at all times.
3. Even with the simple plan, Barney was far too busy directing traffic to observe much. Standing in the middle of the intersection, he wasn?t in the right position to see up the ramp when traffic began to back up onto Highway 52.
4. Even if he had made better observations, his manager-centered process model didn?t allow him to do much. The underlying assumption that he was personally responsible for each and every car going through the intersection meant that he couldn?t delegate much – he couldn?t count on the drivers to do anything other than what he told them to do.
5. Barney?s actions were pretty limited; because he had to control each vehicle, he couldn?t leave his spot in the middle of the intersection. In the end, he couldn?t do much beyond try harder at what he was already doing?waving his arms more frantically at the folks, in the hopes that they’d get through faster.

Because the manager must make (or at least approve of) all decisions, only one thing happens at a time and everything else lines up waiting for a turn. When simplicity, centralized information, and oversight are turned from virtues into vices, it creates a choke point that affects project planning and execution.

Simplicity Since the entire project plan must be under the control of the manager at all times, the plan must be simple enough that a single person can comprehend it in its entirety. This sets an upper bound on project complexity?if the problem to be solved is beyond this bound, the manager has to simplify it somehow (e.g., letting traffic go in only one direction at a time). This serialization of activities is a common simplification in micromanaged projects as well, and it wastes both effort and time. When serialization isn?t enough, the manager may start leaving ?non-essential? activities out of the project plan. Micromanagers are notorious for over-simplifying, to the point where their software project plans may leave out something essential for a successful product launch.

Centralized information Since the manager is the only one who can make a decision, it?s critical that he get lots of quality information about how the project is doing. Unfortunately, the only observations allowed are those that the manager puts in the project plan?but that manager?s far too busy making each and every decision to actually observe much of anything. So in practice, micromanagers are often flying blind, making decisions on little or no actual information.

Oversight The need to get explicit approval for each action adds to the amount of time required to accomplish tasks. So micromanagement tends to be inefficient, with a lot of people waiting around for the manager to tell them what to do next. The manager-as-bottleneck is a key structural problem. The practice also leads to people problems, such as initiative squelching. The manager?s assumption implies that the people being managed have nothing to contribute beyond the functions defined for them by the manager. What if the workers want to do something other than follow the rules?because they see a better way or a problem with the plan? Forget it. The micromanager will not allow it to happen. This creates short tempers and long days for those who are micromanaged.

Most people don?t like this style of management. Some will respond with a sort of dead, mechanical compliance, waiting dutifully for their next set of instructions from the manager. Others may choose some form of subtle rebellion, such as ?working to rule??following the manager?s instructions to the letter, no more, no less, even when those instructions are clearly a recipe for failure. And others will rebel more openly, taking advantage of the manager?s continual distraction to get away with whatever they can. Alas, these responses to micromanagement tend to set up a positive feedback loop that reinforce the micromanager?s assumptions and leads to even more micromanagement. Micromanagers tend to be very busy people.

So, is micromanagement ever appropriate? Certainly, when the problem to be solved is small enough for one manager to truly comprehend the entire project plan, and the people doing the work are willing to follow each and every command of the manager. While this situation can occur now and then, it’s not very common in the software world.

A common cause of micromanagement is the newly promoted, technically competent manager rushing in to help a floundering employee or rescue a particular part of a software project. This creates a co-dependent dynamic where the manager becomes the rescuer, and the employee becomes helpless. This ensures that the next time there is a problem, the manager will step in again, and so on, until something happens to break the pattern.

While micromanaged projects can (and often do) result in successful product launches, it?s often more in spite of their management than because of it. There ought to be a more efficient and less aggravating way to handle the situation.

Motherly Management

Aunt Bea chose a kinder, gentler style that we call motherly managing, allowing the drivers to do some things for themselves, and helping them when she thought they needed help. But her underlying assumption was still pretty close to Barney?s: the people being managed might be able to do a few routine things without being told, but all significant decisions?especially when there was some form of contention or competition?were still firmly under her control.

If the micromanager views the people being managed as machines, the motherly manager sees them more like children, able to do a few routine things but still needing protection from anything potentially dangerous. Like the micromanager, the motherly manager is not necessarily malicious or desperately in need of control. Aunt Bea had no great need to have power over the drivers; she just knew that they couldn?t make major decisions without her help. She simply couldn?t visualize the situation where one person could be turning left into the gap created by another turning right, because she couldn’t see who was controlling the relationship, and she knew that two drivers certainly couldn?t cooperate without somebody to coordinate them.

Aunt Bea?s motherly assumptions defined her view of the key management activities:

1. The problem to be solved was something like ?take care of the people who have to cross other traffic.? Like Barney, she saw the problem in personal terms; it was her problem, not the drivers? problem.
2. Because Aunt Bea saw the drivers as human beings who could do a few things for themselves, her plan was a bit less rigid than Barney?s. She could allow at least a few routine things to happen in parallel, but under exceptional conditions she would take full control of everything, which meant reverting to serial execution.
3. Aunt Bea?s more distributed plan required somewhat more sophisticated observations than Barney?s. She had to observe those situations in which her help was needed?in particular, left turns. Notice that she wasn?t observing whether people were having trouble making left turns; her underlying assumption said that a left turn signal was a request for help. Like Barney, she spent her time in the middle of the intersection, a point from which she couldn?t see up the
   ramp very well.
4. Because of her motherly assumption that the people being managed couldn?t handle any form of contention or conflict, Aunt Bea?s process models dictated that she must personally resolve these things. So her response to just about any out-of-the-ordinary condition was to stop traffic and go back to taking turns.
5. Like Barney, Aunt Bee was working from a very limited set of actions, in part restricted by her need to be in the position of control at the center of the intersection. If those actions didn?t work, about all she could do was more of what she was already doing.

Like micromanagement, motherly management can work when its underlying assumptions are true and the problem and solution aren?t too complex. Trouble is, most software development shops aren?t day care centers, and most development is non-routine and requires that a lot of conflicts be resolved. Interfaces, partitioning, decomposition, protocols?these are all ?left turns? in the view of a motherly manager, who must personally make sure that everybody plays well together. This creates a structural problem similar to micromanagement. Similar, but also different. Since some work can take place independently under motherly management, the manager is less of a choke point than in the case of micromanagement.

But because the process is still highly manager-centric, the actual amount of work that can be done in parallel is often less than expected. We end up with a process that?s very nearly effective: almost parallel, relatively observant, and coming awfully close to giving workers independent responsibility:

Parallel (almost) Only pre-defined ?routine? things can take place in parallel. As long as traffic went straight ahead or turned right, Aunt Bea?s plan seemed to work. But she couldn?t predict how many people would want to turn left. When lots of people started turning left, her plan fell apart. In the same way, the actual performance of a motherly-managed software project depends heavily on just how much of the development is really ?routine? with no need for interactions or conflict resolution. If there are a lot more ?exceptions? than expected, a lot of developers working in parallel according to the project plan may be sitting on their hands waiting for the manager to make a decision. This can make a project plan that was parallel in theory become serial in practice.

Myopic Motherly managers make more observations than micromanagers, but they still confine those observations to specific conditions noted in the project plan. If the conditions defined by the manager are in fact not the key exceptions that need to be managed, the motherly manager will be spending time and energy observing the wrong thing, while missing the observations that are really necessary for project success.

Nannying Motherly management can be less oppressive than micromanagement for the people being managed, because the ?mother? allows her ?children? to do a few things on their own. The individual developers can go ahead as long as they aren?t going against the flow or getting into conflicts. But at the first indication that something non-standard is going on, the whole process stops until the manager decides what to do. The manager must handle all the decisions that really matter?and this squelches the individual contribution to solving the overall problem just about as effectively as micromanagement. There is a great deal of variation here?a manager who views the employees as teenagers is less openly controlling than one who views them as toddlers. Still, most of the people who work in the software business have college degrees, and we wonder if we?re making the best use of their expensive educations when we manage them as though they were children.

If we are going to find a style that?s more efficient and effective than micro and motherly, we must start by changing our underlying assumptions. Barney sees the people being managed as machines to be programmed; Bea sees them as children to be helped. Now let?s see what happens when Andy views them as adult human beings.

Masterly Management

Andy took an approach that at first didn?t look like ?management? at all. He just sat in his chair, sipping lemonade and watching traffic on the Highway 52 off-ramp. When it started backing up badly, he strolled out into the intersection, stopped traffic on Key Street, and let the off-ramp clear; then he went back to his lemonade. He seemed to be ?working? a lot less than Barney or Aunt Bee, yet traffic flowed smoothly. We refer to Andy?s style as masterly management ? because of our three traffic controllers, only he was truly the master of the situation.

The keys to Andy?s management style were his underlying assumptions: that drivers are adults, that most of the time they can take care of themselves, and that his role as a manager is to support these competent adults so they can do the real work of getting themselves safely through the intersection. This is vastly different from Barney?s and Aunt Bea?s assumption. Andy felt secure enough about his own competence and the drivers? know-how that he could remove himself from the center of the job.

Because Andy did not place himself at the center of the management task, he could be much more flexible and effective at the key management activities:

1. Andy saw the problem to be solved as moving traffic efficiently and safely through the intersection. He also realized that most of the time this intersection didn?t need any help; people made turns here every day without any supervision. What made this a unique problem that might require some management intervention? The detour increased traffic on the Highway 52 off-ramp, and that might, on occasion, cause traffic on the ramp to back up onto the highway and cause a safety hazard. Notice the difference?while Barney and Aunt Bea defined the problem in terms of what they had to do, Andy defined the problem in terms of results, independent of who actually ?did the work.? By doing this, Andy positioned himself to observe and “steer” the system that did work, rather than as the person doing the work.

2. With his understanding of the real problem to be solved, Andy was able to construct an effective plan for its solution. The drivers could be responsible for getting themselves through the intersection. He and his ?management team? would monitor the off-ramp and make sure that it could be emptied when (and if) it backed up far enough to pose a safety hazard. While Barney might accuse Andy of not having much of a plan, the fact is that Andy?s simple-looking plan actually allowed some very complex things to happen. Because he didn?t attempt to control low-level actions by the drivers, Andy?s plan delegated management work to individual drivers. This allowed them to operate in parallel, which they did?drivers waiting to turn left off the ramp took advantage of gaps in traffic created by drivers turning right.

3. Now that he had both a problem statement and a plan, Andy could identify which observations he needed to make. To keep traffic from backing up onto Highway 52, he had to watch the ramp?not the intersection. So he positioned himself off to the side, where he could see the ramp. This is another critical difference in Andy?s style. Standing in the middle of the intersection, Barney and Aunt Bea were taking in a great deal of information?most of it irrelevant to solving the real problem. They weren?t in the right place to make the observations that really matter. Of course, Andy didn?t ignore what was happening in the intersection?but he didn?t make the intersection his primary focus.

4. Andy?s management style used two process models. First, if traffic?s backing up on the off-ramp, stop traffic on Key Street and allow the ramp to drain. Second, if something blocks the intersection, get it out of the way immediately. The rest of the time, Andy?s process model says ?let the drivers take care of themselves.?

Both of these models are more subtle than they look. The first model allows Andy to do some fine-tuning as the morning progresses. How far up the ramp is ?too far? for traffic to back up? At first he took a conservative approach, draining the ramp when it was backed up about halfway to the highway. Later, after observing how quickly Key Street traffic could be stopped to drain the ramp, he changed his definition of ?too far? to something more like three-quarters of the way up the ramp. This meant even fewer interventions were needed, because often traffic would back up to the halfway point and then drain back down by itself.

The second model contains a flexible definition of just what triggers action. Andy?s looking for a symptom, which could have a variety of root causes. If something blocks the intersection (e.g., a driver too timid to turn left), Andy?s model will handle it.

5. Finally, Andy took a lot less ?overt? action than either Barney or Aunt Bea. Most of the time it appeared that he was doing nothing at all. Yet, when action was required, he knew what action was appropriate and effective. But it would be wrong to say that Andy?s actions were simpler than Barney?s or Aunt Bea?s. In fact, his infrequent interventions required more skill. After all, Barney and Aunt Bea were already standing in the middle of the intersection, and had the drivers? complete attention. Andy had to enter an intersection full of moving vehicles, get the drivers? attention, temporarily interrupt their self-management, get the drivers to carry out his instructions, and finally re-establish the self-managing system. This is a task requiring some skill.

Like the other two styles we?ve discussed, masterly management works when its underlying assumptions are valid. In software development, where the people being managed are skilled, competent, educated adults, these assumptions are usually true.  Masterly management, therefore, addresses the structural and behavioral problems we saw with micro and motherly management:

The delegation inherent in the plan means that most contentions and minor conflicts get solved without the manager?s intervention, so most of the time the people aren?t waiting for the manager?s attention. When a problem does require the manager?s attention, that problem doesn?t have to wait in line behind a bunch of minor conflicts.

This support for parallel activities means that masterly management can work with projects that are just too complicated to be understood in all their detail by a single manager?and most software projects would fall into that category.

Because the people being managed are also delegated a self-management job, they are able to contribute observations that a micro or motherly manager is likely to miss.

Masterly management involves managing the project rather than the individuals. Most of the time, the people doing the work are free to pick their own methods within some basic guidelines (for instance, driving on the correct side of the road, or using the corporate standard tool set). This allows creative energy that might otherwise be spent on finding ways to ?beat the system? to instead go toward creating profitable products.

In short, a masterly manager like Andy observes and steers a system. If the problem is well understood, the plan is appropriate, and the people doing the work are competent, the controller often doesn?t need to do much. Unlike micro and motherly managers, masterly managers spend most of their time in observation and thought rather than in frantic activity. But don?t be fooled?when Andy was sitting in his chair sipping lemonade, he was more effectively in control of the situation than either Barney or Aunt Bea.

If masterly management is so good, why don?t we see it more often? Because in some ways it?s unsettling, especially for the manager:

Looks can be deceiving Masterly managed projects often give a certain appearance of chaos. When Andy managed the intersection, traffic was turning every which way, which was disturbing compared to the neat and orderly behavior when Barney was in charge. However, more traffic moved through the intersection, and did so more safely, under Andy?s chaotic-looking management style. Many software projects already look like chaos. Will going to masterly management make them more so? We doubt it; we suspect that much of the apparent chaos in software development comes from resistance to micro and motherly management.

Power is as power does Masterly management requires a different mindset. Most people associate the word manager with the word power. Yet moving from micromanagement to masterly management involves giving up much of the apparent power and authority of the managerial position, and giving it to the people being managed. The masterly manager has more real power, according to writer Barry Oshry (quoted in Weinberg?s book Becoming a Technical Leader), if we define power as the ability ?to act in ways which enhance the capacity of our systems to thrive and develop in their environment.?

Measuring what counts In some organizations (particularly those where micromanagement is the rule), a masterly manager may have a hard time getting promoted. After all, you won?t be doing much visible managing compared to the micro and motherly managers around you, and it will be easy for the micromanager who makes promotion decisions to conclude that the project succeeded in spite of your ?inaction,? not because of it.

But masterly management also has rewards. Masterly managers often don?t have to work as frantically as micro and motherly managers. As a masterly manager, you?re less likely to find yourself in the office at three in the morning, trying to resolve yet another trivial issue. And you?ll get the satisfaction of knowing that you?re truly an effective leader when the project team says, ?We did this ourselves.?

Micro, Motherly, or Masterly Management

The best way to determine your management style is to ask questions and observe what is happening.

Do the people reporting to you scatter like leaves in the wind when you show up? Do you feel like they are performing to the letter of the law and not the spirit? Do you jump in and start coding when there is a problem? If so, you?re probably micromanaging.

Do you organize workflow for a minimum of interaction so things go smoothly in the team? Do you step in and try to make everything all right for everybody? In crunch mode, do you revert to micromanaging? Your heart may be in the right place, but you may be in motherly managing mode.

Do you spend a fair amount of time observing what is happening, thinking about the impact the events will have on your team and project, and planning what to do? If so, you may be masterly managing.

If you would like to change your management style, there are some important questions to think about. First, how did you come to have your current management style? For most of us, the way we manage is influenced by the people who?ve managed us, and by the environment in which we manage. Acknowledging these influences, and the constraints of your current work situation, may help you determine whether it?s time for new models. It?s important, too, to examine how you feel about your style. If you?re happy with the status quo, change may not be necessary. But if you feel overworked, and seem to be constantly fighting fires, then maybe a change is in order.

And finally, what would you like to have happen? We saw that Barney, Bea, and Andy?s view of the ?problem at hand? shaped their unique responses, and the same is true for you. Once you know what you would like to have happen, you can create and implement the plans that will allow you to achieve your goals and keep your traffic running smoothly.

convert this post to pdf.

©2005 Don Gray

Three of my favorite quotes about change and translations:

“The only person who likes change is a wet baby.” This change corrects a problem so I’m OK with it.

“Everyone likes change, when someone else is doing it.” I’m OK with the status quo. You do the changing.

“The only universal constant is change.” Get used to changing. The universe constantly changes so you need to change too.

If change is so inevitable, why do people, teams and organizations experience so much difficulty changing? We should be good at it!

In fact, we are good at change, but in our own particular way. Any given change carries two factors. The requested change, and how we feel about that change. Recently while cooking, I grabbed the handle of a pan that had been in a 350 degree oven. It didn’t take long before I let go of the handle. I had no trouble accepting the need for this change.

Not all changes, though, are as universally accepted as dropping the hand of a hot pan. Suppose everyone were required to shave their head. This change wouldn’t bother me and I’d readily shave my head. Johanna Rothman assures me she’d have a big problem with this change and be very slow to change. This typifies “You go ahead and change. I’m happy with the status quo.”

Change Quotients

If we ignore neurologically requested changes (like letting go of the hot pan handle), we can view the ratio of the change/willingness to change as a quotient. As we average all the quotients over many situations for one individual, we arrive at a statistical value I’ll call that person’s Change Quotient. The Change Quotient relates to how open a person is to change.

Change Quotients vary from 0 to 1. Values close to 0 indicate a preference for slow changes and value approaching 1 indicate people who readily change. We each have a unique change quotient. 0 doesn’t mead “bad”, and 1 doesn’t mean “good”. The values simply indicate a preference.

People with lower change quotients often view those with high change quotients as chaotic and “flighty”. I was once asked to “make up my mind” when in fact I’d already made my mind up and shared the results twice while the other person was still thinking.

Conversely, “glacial” describes low change quotients to those having change quotients approaching 1. These people seem to reject instantly any suggestion to change, even something as simple as removing their boot from your bare toes.

Several things contribute to our Change Quotient. Any proposed change runs a gauntlet of survival rules, self-esteem, and personality/family checklists. The gauntlet forms our “willingness to change.”

Survival rules perform as “mental reflex actions”, the things we do, the thoughts we think, and feelings we have, that we don’t consciously think about. We build most of our survival rules by repeated assertion, usually by our parents or respected adults, of things to keep us alive. “Never make a decision until you have all the facts.” “Don’t be wishy-washy–make up your mind.” “Be your own man–don’t let others push you around.”

Self-esteem reflects how we currently feel about ourselves. This fluctuates based on our physical state (rested/tired, healthy/sick), our mental state (happy/sad, exited/bored) and how we feel others view us.

Our family creates our initial world view. Some families view consistency and slowness to change as admirable qualities. Others feel adaptability and responsiveness are desirable attributes. Each one of us starts with our family’s view of change start with this view.

Personality builds on this foundation. We add our experiences, successes and failures, to build new rules about change. Which kinds of change we can accommodate (or welcome) quickly, which changes we need to consider, which changes we want to avoid.

Responding to Change

Some years ago I found out that I was not really in charge of everything, and actually in control of very little. This led me to

Don’s Dismal Dilemma: How will I achieve my goals, when I’m not in charge or control?

Physical systems follow patterns established eons ago. Friends do what suits them. My clients determine when and where I’ll work with them.

As time progressed, I found the one thing in the universe I have complete control over: me. And so I found

Don’s Delightful Discovery: I can’t control what happens to me, but I can control me, and how I respond to what happens to me.

As Virginia Satir said, “We can direct our efforts to change what we can and to work out creative ways to live with what we can’t change.” [New Peoplemaking, pg 7]

When we quit changing with our environment, we face extinction. We need to update our mental models so they conform to current reality. As we grow and mature, our realities change. Our mental models need to reflect the changes. Mental models formed in childhood and not updated make for interesting adult behavior. Dad warned me about getting “Hardening of the Attitudes”. (Notice the survival rule that affects my change quotient?)

Changing allows me to achieve my goals. If the goal doesn’t change, and external events (by definition beyond my control) change the situation, I need to change my actions (I control these) to bring the results in line with achieving my goal. Or perhaps my actions aren’t producing the results needed to achieve the goal. Again change becomes necessary to realign with my goal. If I don’t change what I’m doing, my actions will take me away from my goal.

“Insanity: doing the same thing over and over again and expecting different results.” Albert Einstein

Occasionally I need to change my goals. As I learn more, what used to be important may not be important now. Changing goals allows me to work on what’s important to me.

So what to do? The answer depends if you are the changer or the changee.

For the changer …

Asking other people to change can appear as “Inflicting Help.” Insisting other people change borders on foolhardy. Think about the following:

1. You’ve already thought through the change, they haven’t. Allow some soak time.
2. Are you really solving a problem? Check out “Solving Other People’s Problems.^“1
3. Expect people to react differently at different times to different change requests.

For the changee …

Rhonda’s Second Revelation: “When change is inevitable, we struggle most to keep what we value most.” – Jerry Weinberg

1. Remember everyone has a different Change Quotient. What you see as change, they may view as stable.
2. The Helpful Rule reminds us “Regardless of how it looks, people are trying to be helpful.”
3. Share with the changer what is most valuable to you.

I’d like to share my favorite quote about change:

“Change happens one person at a time.” Virginia Satir

And you can always change your mind about how you change.

¹ Amplifying Your Effectiveness: Collected Essays, Dorset House, ISBN 0-932633-47-1, pages 17 – 21

convert this post to pdf.

©1998, 2002 Don Gray, www.donaldegray.com

Man’s achievements rest upon the use of symbols. – Alfred Korzybski

Why is our field struggling in its efforts to become and engineering discipline? The answers lies in our heritage as symbol processors and the patterns of evolution from craft to science.

“Higher order abstractions of lower order referents.” This is not recognized as a sentence. If fact, it is not recognized at all! This is something we learn to do as soon as we learn to speak. When we utter our first “Ma-Ma”, we’re not really referring to the organism that conceived, nurtured and gave us birth (although all of this is true). We refer instead to this object that floats into view when we cry, feeds us when we’re hungry, and changes us when we need it. It even makes funny faces and keeps uttering the incoherent phrase “Ma-Ma”. And whatever it is, it gets obvious delight when we form and utter “Ma-Ma” back to it. We are clueless about what a symbol is, but we know how to use it to our advantage.

The process of abstraction (in language) was introduced by Alfred Korzybski, and is demonstrated by the abstraction ladder[3]. The abstraction ladder can be used to show how we progress from the physical (atom/molecule level known as process level) through various abstractions layers to the actual use in language. For example, a “cow” ladder may include the following layers:

8. Wealth – The word “wealth” is at an extremely high level of abstraction, omitting almost all reference to the characteristics of Bessie.

7. Asset – When Bessie is referred to as an “asset,” still more of her characteristics are left out.

6. Farm Asset – When Bessie is included among “farm assets,” reference is made only to what she has in common with all other salable items on the farm.

5. When Bessie is referred to as “livestock,” only those characteristics she has in common with pigs, chickens, goats, etc., are referred to.

4. The word “cow” stands for the characteristics we have abstracted as common to cow₁, cow₂, cow₃, . . . cow_n. Characteristics peculiar to specific cows are left out.

3. The word “Bessie” (cow1) is the name we give to the object of perception of level 2. The name is not the object; it merely stands for the object and omits reference to many of the characteristics of the object.

2. The cow we perceive is not the word, but the object of experience, that which our nervous system abstracts (selects) from the totality that, constitutes the process-cow. Many of the characteristics of the process cow are left out.

1. The cow known to science ultimately consists of atoms, electrons, etc., according to present-day scientific inference. Characteristics (represented by circles) are infinite at this level and ever-changing. This is the process level.

In most cases, if we work diligently, we can work our way back down the abstraction ladder to “what the user ‘really’ means”. If we step back though, and look at the higher order abstraction “software”, what do we find when we get to the bottom of the ladder?

Even though I’ve wrestled with this question, in relation to software I still keep getting the same answer, “Nothing!” There is no lower order referent at the ladder’s lowest rung. There is no object, no “atoms, electrons, etc., according to present-day scientific inference”. Representations of the software exist, but I’ve never seen a “handful” of software.

Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke

This leads me to the conclusion that software is the “brain stuff” which executes on a computer, doing something useful for somebody. This brain stuff has no mass, no energy, nothing. Yet it transforms inputs into outputs, as if magic.

This is not the first time we’ve come upon things that we didn’t quite understand. Physical phenomena have been observed for centuries before the underlying principles were divined. After a couple more centuries of scientific inquiry, the principles were organized and engineering became possible.

Perhaps this then is the start of the confusion about software being part of engineering. Both activities lack low order referents. Both activities involve “brain stuff”. Both activities involve mathematical proofs, explanations and derivations.

To say however that creating software should fall under the engineering profession makes no more sense than to say accounting, or the actuarial mathematics should be part of the engineering profession. Some day when we better understand what this is all about, we may find that engineering and software are simply two branches of “brain stuff”. A better analogy is to say that software is like engineering in that there are many branches sharing a common trunk.[1]

The discussion about adding software to the (professional) engineering disciplines is understandable, if misguided. No other technology has become as pervasive as fast, or has the impact on our lives that software has. The stuff is everywhere after only 40 years.

Similar to the evening news, it seems the bad news gets the majority of the air time. For every Denver Airport Luggage System, there are successes that never get air time, yet we take for granted. In my kitchen, only the can opener and toaster don’t have keypads and readouts. My car’s anti-lock brakes depend on software. In fact, if the main processor goes out, my car won’t even run. I’ve never heard a story about these (or similar successes) on the news. Is it a wonder society is nervous about the quality of the software that pervades their life?

In her report, “Prospects for an Engineering Discipline of Software”[2], Mary Shaw makes several key points.

1. Activities generally start as crafts.
2. When there is sufficient experience and demand, the steps of the craft become more formalized, and the production/commercial phase of the activity is entered.
3. As science foundations are determined for the activity, professional engineering becomes possible.
4. Professional engineering and science exist in a symbiotic relationship with engineering providing new problems for science, and science providing new techniques for solving the engineer’s problems.
5. As for software engineering “Unfortunately, the term is now most often used to refer to life cycle models, routine methodologies, cost estimation techniques, documentation frameworks, configuration management tools, quality assurance techniques, and other techniques for standardizing production activities. These technologies are characteristic of the commercial stage of evolution; software management would be a much more appropriate term.”[2]

Software management issues are addressed by the Software Engineering Institute’s “Capability Maturity Model” and the ISO9000 series of standards.

The Journey of a single step begins with a thousand miles.

So what should we do? To include software as a professional engineering discipline is doomed to failure since:

1. Creating software is still in the craft/production stage. As the primary resource is “brain stuff”, I’m not convinced we’ll ever move beyond this stage.
2. Finding a common core of knowledge applicable to all branches of software will result in abstracting up a step and result in those activities that Mary Shaw refers to (correctly in my opinion) as “software management”, not software engineering.
3. Education in the field at this time seems somewhat disjoint from science and current practice.

At this point in time, it looks like the next step is one of education.

1. We need to teach software creators about best practices, models, and algorithms (and here might lie the eventual basis for engineering activities in software).
2. We need to teach software managers that “brain stuff” is:
   • Not compressible in time. (Most late software is the result of bad date scheduling, not bad programming).
   • Not necessarily easy to rework. Changing the structure of a program or system may be very costly. (as in time and dollars)
   • Quality must be built in from the start, not inspected in at the end.
3. We need to teach society what are reasonable expectations with regard to software.
4. We need to teach ourselves what it means to be professional, and then start acting that way. [4]

Notes

[1] Check “Will There Ever Be Software Engineering”, Michael Jackson IEEE Software, Jan/Feb 1998

[2] Prospects for an Engineering Discipline of Software, Mary Shaw SEI-90-TR-20

[3 ] Language In Thought & Action, Fourth Edition, S.I. Hayakawa, page 155

The “Abstraction Ladder” is based on “The Structural Differential,” a diagram originated by Alfred Korzybski to explain the process of abstracting. For a fuller explanation both of the diagram and of the process it illustrates, see his Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics ( 1933 ), especially Chapter 25

[4] Three organizations I’m aware of that are involved in the issue of professionalism are:

• Association of Computing Machinery (www.acm.org)
• Independent Computer Consultant’s Association (www.icca.org)
• IEEE (www.ieee.org)

convert this post to pdf.