The next AYE Conference will be November 7-11, 2010 in Phoenix, Arizona.
Please Join Us
Some groups have well-defined missions. Some don’t. The problem when you don’t have a mission is you can’t always know what work to do. In Make Your Mission Possible, I suggest ways to define a mission.
convert this post to pdf. Copyright 2008 Johanna Rothman, originally published in Better Software
Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.”
“Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?”
“We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right?” Steve nodded. “But the bad news is that we have to port them from release to release.”
“We did that last month.”
“Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.”
“What? Why did they do that? Not to this product-they can’t.”
“Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.”
“How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.”
Steve put his head in his hands. Finally, he looked up and said, “OK. I’ll do it. But on one condition: We decide what we’re doing as a development group once and for all. You asked me to be a team lead, right?” Janice nodded. “Well, I don’t know what I’m leading. Let’s decide what our mission is-whether it’s to support any crazy thing our customers want, or make products, or support installations, or what. Let’s define our mission and write our mission statement. Then we’ll have a basis on which to say no to new work if it doesn’t support our mission. From now on, we will have a reason for the work.”
A week later, Steve and Janice met to develop their mission. “Steve, I invited Chris so we have all you technical leads in one room. Since you prompted me to think about the mission for our group, I decided to ask my boss for his mission, as well. He doesn’t have one yet, so we may have to revise ours later. But at least we’ll know where we’re going.”
Janice placed two lists on the table. “Here’s all the work we’re doing in development. One list is a month-by-month portfolio of all of our projects and all the extra things I’m supposed to do as a manager. This other list is the work other people would like us to do that we’re not doing. Now, do you two have work you’d like to be doing that’s not on this list?”
Chris and Steve nodded.
Janice handed them a stack of index cards and said, “OK, let’s write all the work we’re doing and the work we’d like to be doing, one project to a card. We’ll organize them on the table into these buckets: work that seems to make sense for our group; work that needs to get done, but maybe not by us; and work that we are doing but we don’t understand why.”
After a few minutes, Janice, Chris, and Steve had their cards sorted. Chris said, “Wait a minute. Why are we looking at the work? Why don’t we decide on our mission first and then manage the work?”
“Good question,” Janice said. “Since my manager doesn’t know his mission, yet, I’m not sure we can finalize ours beyond the work we do. Clearly someone in the company values our work, so we have to make sure we continue to do work the company values but that also makes sense for us to do. By starting with an analysis of our work, we’ll have a basis for our decisions-especially when we start looking at the work we’d like to be doing that we never have time to start.”
Janice, Chris, and Steve discussed their work, bucket by bucket, starting with work it made sense for them to do.
Next, they discussed the work that they thought the company needed to have done-but not necessarily by them-and put a sticky on the card with the name of the group that they thought should do the work.
Finally, the trio discussed the work they didn’t understand why they were doing. Janice wrote a sticky with the name of the person she was going to talk to about those projects.
“Now that we understand our work and the reasons why we have it, let’s discuss our mission. A good mission explains what we do and don’t do. It establishes the boundaries of our work and explains how our development group fits into the organization. A great mission will provide reasonable and measurable objectives for our work so other groups can see what we are responsible for-and not responsible for,” Janice explained.
“Oh, so I don’t have to add something impossible such as, ‘Respond to all requests in twenty-four-hours’?” Chris asked.
“No, that’s how we got into trouble with Big Customer1 last quarter, remember?” Steve said.
“You know, if we were a custom development group, responding to all requests in twenty-four hours might make sense. But we’re not!” Janice said. “Let’s develop a mission that makes sense for us, and I’ll talk it over with my boss. I’ll convince him our mission is on target.” Janice grinned. “But if he doesn’t agree, at least I’ll understand what he wants us to do differently.”
The three of them worked for a while, until they were satisfied. Janice said, “Read the mission out loud, Steve so we can hear it.”
“We will enable our customers to organize and see their data by creating products that our company can sell. We will continue to extend each product and family of products so the products provide a cost-effective solution to our customers’ needs.”
“OK, with this emphasis on products and product families, as well as cost-effectiveness, I now have ammunition to say no to more of these customizations,” Janice said. “Maybe my boss will think about his mission instead of just saying yes to everything that he sees. But if not, we can use our mission to set some boundaries for what we do and what the company does. Thanks, guys.”
I thank Dwayne Phillips and Esther Derby for their review.
convert this post to pdf. ©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:
Choices for a poorly ending project.
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.
Results of blaming
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.
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. ©2009 Gerald M. Weinberg, www.geraldmweinberg.com
IT professionals must be good team players, but what does that mean?
For one thing, it means they must know how to come into a situation and quickly cooperate and gain cooperation, but cooperation takes many forms. It’s not sufficient to want to cooperate. You must also know how. This column is about the technology of cooperation.
People
Most people, when they think of cooperating, think of everybody doing the same thing?like all pulling on the same rope in a tug-of-war or rowing in the same Roman galley, perhaps chained to the oar. When you consider cooperating by sharing people’s direct labor, first try to categorize the situation into one of these two:
1. The job is well understood and easy to communicate to a newcomer.
2. The job is fuzzy, or not understood at all, or complicated.
In the first situation, as in a tug-of-war, it is relatively easy to move people about from one work group to another. The amount of productivity in this situation is roughly the sum of the individual productivities. Ten people can tug ten times as hard as one. Many managers think that adding IT professionals is just like adding bodies to a tug-of-war team.
But even a tug-of-war is not so simple, for those who are experts at it. Given roughly equal weights on both sides, the team that understands and uses technique will win every time – and can even overcome substantial weight deficits. Adding a new member to a skilled tug-of-war team will not add proportionately to their success. Indeed, unless the new member understands their technology and system of communication, the addition of another body is likely to reduce their total tugging effectiveness.
When the job is fuzzy, and ideas are needed more than simple tugging power, the addition of a new member can be helpful if the team is ready to accept new viewpoints imported by the new member. Experienced IT professionals, however, know how hard it can be to have their better ideas heard when they’ve just started a new assignment. It can be horribly difficult to integrate a new person. Time and “wasted” effort must be allowed for in such additions, especially as the job grows more complex.
Thus, if quick addition is needed, adding people willy-nilly is not the answer. This observation was the essence of Brooks’s Law – adding people late in a project makes the project take even longer. Adding them early, however, which allows time for this “wasted” effort of integrating the new people, can, in the end, make a project go faster.
Any IT professional who is thrown into a project late and expected to make things go faster needs to be aware of Brooks’s Law and needs to communicate to the management what kinds of delays are to be expected. Moreover, each of us IT professionals needs to master the arts of quickly learning what the job is about and how the existing team communicates.
Programs
When we import a program or a piece of hardware to a project, we import technology in a form that may seem more acceptable than a new team member might be. This is the dream of reusable software. But when the team members feel that their own technology is an extension of their own egos, programs may not be portable at all. Instead, they run into the “not-invented-here” brick wall.
Of course, even when a team is willing or even eager to import software or hardware, it may prove poorly designed for portability. In general, portability of complex technology doesn’t come by accident, but by design and by testing of the design. Even for well-designed technology, there is a break-in period which may or may not be shorter than the time taken to add a new member to a team. Of course, the payoff for an imported technology can be huge, but only if it’s adopted and used.
Some IT professionals come on the job with their own tools, not anticipating the amount of difficulty they will experience getting the existing team to adopt their “superior” tools. If you feel that your tools add to your value as a IT professional, you must master the art of introducing tools – especially to people who may be insulted by the very idea that you might know something better than what they already know.
Perceptions
Ideas or ways of thinking can be the most portable of all kinds of technology, as long as the ideas or perceptions are not labeled too clearly as “belonging” to someone. The rule here is perhaps the most important that a technically-oriented IT professional can learn:
There’s nothing you can’t accomplish if you aren’t concerned who gets the credit.
If a project is successful, there’s always enough credit to pass around.
Points or Perceptions
Much of what we do on a job is to win the approval of the management, or of the customer. We call this “scoring points.” Success on a job depends very much on the ability to score points, in whatever game management happens to be playing. If they are playing a good management game, then the more points you score, the better the job you must actually be doing.
But bad managers give points for the wrong things, and if you work under such a point system, you soon become a poor performer. In any case, though, in work as in life:
Points can never be passed directly from one person to another.
To pass points, you must pass people, programs, or perceptions.
In general, sharing perceptions may be the easiest way to cooperate. Moreover, if you don’t share perceptions, it may be almost impossible to cooperate. So, when you enter a new group and want to cooperate, it’s best to start by listening?and learning how other people perceive the world.
convert this post to pdf. © 2003 Johanna Rothman, www.jrothman.com
Meetings are a fact of our lives. Most of the time we don’t need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.
Darcy is a middle manager in a startup. They have enough money for the next eight months. For the last three months, the senior managers have closeted themselves in meetings day in, day out. Darcy knows they’re trying to define the current strategy and tactics to accomplish the goal: drive enough revenue to break even. If they can break even in eight months, their investors will consider investing just a bit more to overcome the slow economy and the company will succeed. If they can’t break even, they’ll be shut down.
Darcy’s no dummy. Neither are the other people in the company. They all know what these closed-door meetings mean. Darcy is concerned that if the senior management team can’t figure out what they’re going to do soon, the meetings will turn into layoff-decision meetings.
Darcy’s management team needs a little facilitation to help them overcome their inability to come to a decision and move forward to specific tactics and action items.
Senior management teams aren’t the only groups who become stuck and need help making decisions. Sometimes, a technical group has the same problem. Desmond, a database developer has on ongoing discussion with George, the GUI developer, and Tina, the tester about how to appropriately design the database upgrade for their product. Desmond, George, and Tina all agree they need an upgrade. They can’t decide how the upgrade should work. Depending on how they choose to implement the upgrade, their work will change, as well as the work the users will have to accomplish. Each of them has different ideas, and each idea is valid. They can’t come to a decision, and they have only a week left to decide.
In both of these cases, well-meaning, intelligent people are stuck. Their normal ways of managing their disagreements are not working.
Consider choosing a facilitator under these conditions:
You may be able to use people inside your organization as facilitators. Sometimes HR people or others are trained as facilitators. If you’re not part of the problem context or solution, you can facilitate the decision-making.
Whatever you do, choose when you require a facilitator. Don’t let the problems or conflicts escalate into no decisions, especially when you require a timely decision.
convert this post to pdf. ©2004 Esther Derby
In a recent workshop, I described an exercise for expressing appreciation. “That won’t go over here,” stated Patty, one of the managers in the workshop. “These are engineers; they don’t want that mushy stuff. Besides, they know that we value them.” Patty didn’t notice that several of the engineers were shaking their heads in disagreement.
The engineers in Patty’s company aren’t the only ones starved for notice and appreciation. A recent Gallup Poll report quoted this statistic: “…the number-one reason people leave organizations is that they don’t feel appreciated, notes the U.S. Department of Labor.”
Given the high cost of replacing knowledge workers, reducing the number-one reason for turnover seems like a good investment. And when you consider that this investment doesn’t cost a dime, why not eliminate the appreciation gap?
When you offer appreciation, appreciate the person, not just the work. Most people like to hear “you did a good job.” But a comment on the quality of work is an evaluation. I like to use this form, which I learned from the work of Virginia Satir:
[Name of person] I appreciate you for [contribution, action, quality].
I might say, “Tom, I appreciate you for moderating technical reviews. It’s really making a difference in our code quality.”
I?’l admit that this felt awkward the first time I tried it. But I also noticed that these words had a very different effect than “You did a good job” or “Thank you.”
Be authentic. Authenticity means that you really do believe what you are saying. Pavlov proved that it’s possible to shape canine behavior by providing rewards for a desired response. People, however are not canines, and they are quick to recognize manipulation. Going through the motions isn’t enough.
Appreciate privately. Most people don’t need or want their manager to gush over every accomplishment in public. In fact, public recognition is uncomfortable for many people. A word in private will let people know that you do notice and appreciate.
Appreciate weekly. “Atta boy” once a year during a performance evaluation isn’t enough. Notice and comment on a contribution every week.
Don’t dilute the value of appreciation. Some well-intentioned person devised the “praise sandwich” as a recipe for delivering feedback. A praise sandwich surrounds criticism between two bits of praise. I suspect this person wanted to ensure that the feedback recipient was in a receptive mood by making them feel good. In reality, the praise sandwich conditions people to expect a slap after a positive stroke. If you have feedback to offer, do it! Don’t dilute the value of appreciation by only giving it along with bad news.
Token rewards anger as often as they delight. One colleague received a movie ticket from his boss after he’d worked well into the evening to fix a critical defect. His response to the reward was one of anger. “After I already spent one evening away from home, he wants me to spend another one? without my wife!” he stated in disbelief.
Don’t wait. When Sara handed in her resignation, her boss told her she was the best project manager he’d ever worked with. “Why’d he wait until I quit to tell me?” Sara fumed later. “Maybe if he’d let me know that he noticed what I did for the company I’d still be there.” A few simple words a week could have kept Sara on the job.
You may feel awkward when you first try giving appreciations–I know I did. Practice in a low-risk situation, maybe by telling a store clerk you appreciate her for helping you find just the right item. Watch what happens and practice until it feels natural. Then try out this simple practice at work.
convert this post to pdf. ©2005 Johanna Rothman
This article appeared previously on stickyminds.com.
I meet many managers in the course of my work, and they all share a common complaint: They have too much work to do.
I ask how they know there’s too much work to do, and they look at me as if I’ve sprouted another head or two. “My staff and I are spread too thin?that’s how I know,” they answer.
I ask if more people would help. “Of course,” they answer. While they look at me as if I’m an idiot, I ask the question that too few managers can answer right then and there, “How many more people would you need,
and for how long?”
I have sympathy for those of you trying to work in organizations with too few people and too many projects. So, I recommend you develop an answer to the “how many people” question. Once you have the answer to that question, you can then deal with the trade-off question with your managers, “If I take on this new project, which work would you like me to stop?”
Define the Universe of Work
I develop and manage a project portfolio by first defining all the work (the “universe of work”), organizing the work by seeing when each person starts and stops each project or piece of the project, and by listing the unstaffed work.
It’s not easy to define all the work, so I make sure I include these activities when defining the work:
Organizing the work this way ensures all your project work is included in the Universe of Work&msash;plus all the work you or your staff performs to maintain the lab, support a product, negotiate with another department, or to budget. When I discuss this with managers who are in charge of five to six people, it’s not uncommon for them to
list more than thirty activities. If you’re in a larger group, you may have more than thirty separate activities.
Take time to define your Universe of Work. I normally set aside one half-hour to write everything down. Once I have a first draft, I put my list away for a day. Afterward, I revisit it to see if I want to add anything. But don’t feel as if you need to complete your Universe of Work list with just one review; it’s easy to forget the periodic work or intermittent ad hoc work.
If you’re so busy you don’t have time to think, you may want to take a little time every day to review your list and add to it.
Organize the Work
Once you know what all the work is, you can make a plan of how you and your team will complete the work. I like to use a whiteboard or flipcharts for this, especially if I have more than a few people in my group. The top row of the paper lists your timetable, which begins with next week followed by consecutive weeks (January 1, January 8, January 15, and so on). Write the names of the people down the left most column. For each week, write down what each person is working on.
If you have many long projects, write the names of the months across the top of the page. Block out the projects, with their start and end dates down the page. Then take a one-month snapshot and fill in the blanks by person.
Now you have a list of what everyone is working on?and when?for the next month. And I’ll bet there’s more work from your Universe of Work list. List that work on the “unstaffed” list.
List the Unstaffed Work
Underneath the last person’s name, write “Unstaffed work.” Now, week by week, add in the unstaffed work row everything that’s in the Universe of Work that is not assigned to anyone. You should have a picture that looks something like this:
| Week 1 | Week 2 | Week 3 | Week 4 | |
| Amy | Feature A UI | Feature B UI | Feature C UI | Feature D UI |
| Bill | Feature A database | Feature B database | Feature C database | Feature D database |
| Claire | Feature A middleware | Feature B middleware | Feature C middleware | Feature B middleware |
| Don | Feature A test | Feature B test | Feature C test | Feature B test |
| Melody Manager |
Management | Management | Management | Management |
| Unstaffed work |
Project 1 Report B (all of it) |
Project 1 Report B (all of it) |
Project 1 Report B (all of it) |
Project 1 Report B (all of it) |
This is a portfolio for a cross-functional team. If you manage or are part of a single-function team, the tasks in the boxes would reflect that.
Estimate the People Required to Complete the Unstaffed Work
With this picture, you can see who’s working on what?and whether those people are multi-tasking?and how much work is not staffed. Now you can estimate how many people you would require to staff the unstaffed work.
Manage the Portfolio
I find that the hardest part of this is starting. Once I have a rolling wave, four-week portfolio, I find it relatively easy to maintain.
As you complete one week, add the data for the next week at the end of the plan. If you’re not sure how long a duration portfolio you need, start with a four-week plan. If you don’t have enough insight into the future, consider adding another week or two onto the end. But I find that few people or organizations are able to maintain detailed tactical plans longer than a few weeks, so more detailed planning isn’t useful.
Once you have a detailed rolling-wave plan, you’ll be able to answer the question of how many more people you need and how you could restaff the projects to take advantage of more people.
But I find the project portfolio chart much more useful than just showing my management where we are understaffed. I use the chart when my manager assigns my group more work. I show my manager the chart and ask, “My staff are working as hard as they can. They can’t do more. What work would you like me to move to the unassigned work?” Now we can have a conversation about how much work needs to be done, the criteria for completing the work, and the relative priority of the work.
Summary
Knowing how much work you group can accomplish?and when they can finish that work?is critical to your success as a manager. With a project portfolio, you can manage the work. You can make tradeoff decisions about which projects to staff and which ones to leave unstaffed. And you’ll know how many more people you need for how long. Make sure you’re managing the project portfolio, not allowing it to manage you.
convert this post to pdf. ©2006-2007 Esther Derby
This column originally appeared on stickyminds.com
In a recent discussion on the state of a software company,
a programmer declared, “We don’t need managers around here,
we need leaders!”
I’m always puzzled by statements like this.
“How do you see the difference between management and
leadership?” I asked.
“Managers do things right, and leaders do the right thing,”
the programmer replied, repeating a Warren Bennis quote.
“But what do they do differently?” I pressed.
quot;Managers manage, and leaders lead,”
the programmer replied with conviction.
Here’s how leadership professor John Kotter describes the difference
between management and leadership (which I paraphrase here):
Management is:
Leadership is:
Reading these lists, it’s clear to me that organizations need both.
Here’s an example. A test manager takes a job with a new testing group.
He talks with his team, his manager, and the internal and external
customers for his unit’s work.
Based on what he hears, he articulates a mission for the group: “We
provide assessments of product quality and help product owners understand
risks.” That’s leadership?setting a direction.
He works with the team to identify all the work they’re currently
doing, work that’s in queue, and projects scheduled for the next several
months. Together, they assess what they can accomplish,
what they won’t do, and whether they have the right mix of
skills to do the work. That’s management.
He supports the team as it self-organizes to accomplish the work.
The organizing part is management (done by the team), while supporting
self-organization is leadership?meeting human needs for autonomy.
The test manager works with the team to identify the resources they
need?machines, tools, and training?and then adjusts the
budget to acquire the necessary resources. That’s management.
He’s showing leadership when he meets with members of the team to
understand their aspirations and help them articulate professional
development goals. When they work together to build skills into daily work,
that’s management.
As the team works to test its products, the manager and the team work
together to develop metrics and dash boards that show test progress and
communicate the quality of the product?management again.
He makes sure the development manager and product owner define
release criteria, leading through influence. He also brings change to
the way the company makes ship decisions. When a testing project
starts slipping, he pulls the team together to assess the issues and
replan their approach–management, according to Kotter’s definition.
And so it goes?a little management here, some leadership there.
The balance shifts, depending on the situation. The test manager combines
management and leadership activities to attend to people and accomplish
meaningful work.
I’ve worked with people who were all leadership. When they lacked
management behaviors?follow-through and attention to practical
implementation?they left chaos in their wakes
(and didn’t actually produce much useful change). I’ve also worked
with people who were mostly management, which only worked when they
had enough personal warmth to navigate human relationships.
(In accounting areas, you don’t necessarily want creative ideas or
big charisma?think Enron.)
Viewing leadership and management as dichotomous sets up a false
choice. Most positions in organizations need both, and that’s what
effective managers deliver.
convert this post to pdf. ©2005 Gerald M. Weinberg
The other day, I was trying to help a client (let me call them “StartupCompany”) mired in conflicts, exceptions, errors, anomalies, lapses, modifications and other deviations from the norm. These annoying exceptions were playing tricks with my blood pressure, so I had to be wired to a wearable blood pressure computer for twenty-four hours. As if StartupCompany didn’t have enough interruptions, now my wearable computer was inflating a blood pressure cuff at random intervals throughout the day.
Every time the cuff inflated, I petulantly asked myself: Why can’t they run a project like real people living run-of-the-mill, low-blood-pressure lives?
That night, I was using the Yellow Pages, and in the A categories in the Yellow Pages index, I chanced to notice a curious pattern. Here are the first few items:
Abortion Services and Alternatives. These were the first two entries in the index. I decided to skip them both, so as not to take sides in the pro-choice/pro-life conflict. I had enough conflicts within StartupCompany.
Abuse – Men, Women, Children. I decided to continue my scan of the index, and this was the next entry. The normal process of family living involves people loving and respecting each other, communicating well, and behaving appropriately according to societal norms. But when people start behaving inappropriately, they need Abuse Services. In StartupCompany, people normally respected one another, communicated well, and behaved appropriately according to societal norms. But they sometimes didn’t, and they lacked “abuse services” for coping.
Academies (including private schools and special education). When the formal education system doesn’t provide special knowledge or handle special cases, private academies and special education are called for. People within StartupCompany often needed to know things they hadn’t learned in the public schools, but StartupCompany had no provision for special education.
Accident Prevention. Accidents aren’t “supposed” to happen, StartupCompany had accidents. In order to improve, they needed processes to prevent accidents and to mitigate their consequences.
Accordions. Despite what some people think, accordions are perfectly normal, though not everybody learns to play them or appreciate them. Still, StartupCompany could have used some entertainment to lighten the mood once in a while.
Accountants. Accounting is also normal, but, if everything always went according to plan, we wouldn’t need to account for things so carefully. We have to protect our financial well-being from mistakes and misbehavior, and that’s what accountants do – and also what they should have been doing in StartupCompany.
Acetylene Welding. Some welding is normal, and some is for repairing things that are not supposed to break – but do anyway. StartupCompany lacked a “welding team” to handle lots of stuff that broke.
Acrylic Nails. Most normal people have fingernails, so why is there a nail business? Oh, yes, it’s the human interface, and StartupCompany had to cope with conflicting ideas of what made a system beautiful – but they had no special beauty experts to resolve the conflicts.
Acting Instruction. We all need to “put on an act” now and then when we’re caught by surprise. StartupCompany’s people certainly needed training in how to behave in improvisational situations, but there was no acting instruction.
Acupressure/Acupuncture. If we were all healthy all the time, we wouldn’t need medical services, and if “normal” Western medical services worked all the time, we wouldn’t need acupressure and acupuncture. So, there are not only abnormal services, but meta-abnormal services – the services when the normal abnormal services fail – certainly true in StartupCompany.
Addressing Service. Have you ever tried to maintain a mailing list? Almost all the work is not the mailing itself, but maintaining the addresses. It’s even worse for email, because email services haven’t yet evolved “normal” ways of dealing with changes. Gee, neither had StartupCompany.
Adjusters. Adjusters, of course, are an abnormal service from the get-go. Without accidents, we wouldn’t need insurance, and if things stayed on course, StartupCompany wouldn’t have needed risk analysis. But they did.
Adobe Materials and Contractors. Adobe materials may not be “normal” where you live, but here in New Mexico, adobe is a normal building method. StartupCompany, too, has its idiosyncratic processes that are not normal in other projects – and newcomers have to learn about them or pay the price. But StartupCompany had no special services to bring newcomers up to speed.
Adoption Services. Yes, sometimes people are not wanted by their parents, and StartupCompany certainly had some unwanted people. But, they lacked “adoption” services for moving unwanted people around.
Adult Supervisory Care. “Normal” adults can take care of themselves without supervision, and normal workers wouldn’t need much managing at all. But StartupCompany had two adults who could not take proper care of themselves, and the managers spent an inordinate amount of time on these two out of a hundred.
I stopped there, sobered by my reading. It was now clear to me that StartupCompany, being a startup, had an overly simplistic picture of what it takes to run a company. I needed an adjustor to adjust my blood pressure – I needed to see that my job as their consultant was to teach them that deviations are normal, and that they (and I) could do what real people do:
convert this post to pdf. © Gerald M. Weinberg, 2004 www.geraldmweinberg.com
Software Development Magazine recently interviewed Jerry. Here are some of his answers.
Q: What?s the most important piece of management-related advice anyone has ever given you?
GW: If you blame your employees, you’re a bad manager. You hired them, accepted them, supervised them, and directed their training. You?re responsible. If you don’t like what’s happening, look to your own behavior. But, if there’s credit to be given, it’s theirs.
Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?
GW: You don’t take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off — or you don’t take the position. I don’t know why managers don’t understand that. They take on new assignments like high school kids on their first blind date.
Q: What if an employee begins to exhibit bad behavior after he or she has been hired — behavior that wasn’t apparent in the interview phase?
GW: Well, that happens, and that’s what managers get paid for handling. It can be a setback, but it’s your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I’ve been trying to remedy for years — so in a sense, I’m to blame, because I’ve succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn’t need managers.
Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)
GW: I might add something about how to make yourself so valuable that your work will never be outsourced — something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that’s just not being done because the odds of success are so poor.
Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?
GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they’re getting even.
Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?
GW: “Drawing the line” is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, “And what do you propose to do about this?” Depending on the reaction you get, take it from there.
Q: You once said, “If you can?t manage yourself, you have no business managing others.” Could you elaborate on that? What does it mean to manage one’s self?
GW: Well, perhaps you can look at Kipling’s famous poem,”If.” It starts:
If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don’t deal in lies,
Or, being hated, don’t give way to hating,
And yet don’t look too good, nor talk too wise;
Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling’s day, it now applies to women, too).
Q: In your opinion, why do so many software projects go over budget or fail to meet their original requirements?
GW: There’s no single reason, but here are probably the top three:
1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.
2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).
3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project?s success is determined by the leaders’ ability to manage themselves emotionally.
Q: If you were to find yourself on a development team, reporting to a project manager, what qualities would you want that manager to have?
GW: I’d want that manager to be a congruent, adult human being, capable of learning from others and his or her own mistakes. A good place to start honing these attributes is the AYE Conference.
convert this post to pdf. ©2005 Steven M Smith
He is wearing his traditional garb — dark suit, white button down shirt, red tie, and black tasseled shoes. The glare off his wire rimmed glasses makes it difficult to see those steely blue eyes. Harry Fox has all the right moves and his quick climb up the management ladder proves it. He is arrogant and ruthless. People who oppose his ideas pay a price. And the payment is extracted when they can least afford it.
We are both participating in a problem solving meeting. Well that’s not quite true, I’m observing and Harry is talking. He just stole the floor from Jim King a few minutes ago by talking louder than Jim. I hate this bully. Harry is dictating his ideas about how the team should solve the problem. But he is wrong. He has missed some crucial facts.
Should I share the facts? Wait a minute. Harry doesn’t care about facts; he cares about looking and sounding good. Harry is connected all the way to the top of the company. I’m connected to the people on my team. I hesitate. Wow, that’s totally uncharacteristic of me: I am known as someone who speaks his mind. I look over at Harry. He has taken his glasses off and is moving them rhythmically up and down as he talks. Although what he is saying doesn’t make sense, it sounds authoritative. Damn, I feel my gut twisting. Is it anger? No… It’s fear.
Harry wraps up his talk. There is a pause. If I want to speak, it’s time. I say nothing.
The omission of crucial facts and opinions happens in thousands of business meetings every day. If people don’t feel safe, they aren’t going to say anything. And you will have no idea about what you missed.
Too often the participants whose opinions count the most assume that the other members of the meeting feel as safe as they do. This assumption is wrong more often than not. But it is rarely ever tested.
You can help increase the safety of your meeting. Collect data. Share it. Interpret it. And decide how to respond to it. These actions will open the opportunity to transform your meetings. For instance, the opportunity to discuss and take action on previously undiscussable items, such as who was or wasn’t invited; what is and isn’t on the agenda; and how the discussions will or won’t be processed. I’ve experienced the power of this kind of transformation many times. You can too.
Inform everyone that you will use a secret ballot to poll the participants about safety. Poll people with the following question, “How safe is it for you to fully share your ideas during this meeting?”
Write this question on the board or a flip chart. Clarify that the ballots are not identified, just a number on a slip of paper. Expand on what “fully share” means by listing some controversial ideas that weren’t shared at other meetings that would have made a difference.
An unsafe environment causes participants to share fewer ideas and to carefully filter the ideas that they do share to be sure they’re safe. Poll for the information in Figure 1.
| Level | Description | Comment |
| 4 | Secure | Everything is discussable without filtering |
| 3 | Safe | Almost everything is discussable without filtering |
| 2 | Neutral | Most things are discussable without filtering |
| 1 | Dangerous | Many of my best ideas are undiscussable |
| 0 | Treacherous | Most of my best ideas are undiscussable |
Figure 1. A gradient of safety
Pass out a ballot — a small piece of paper, post-it note or note card — to each participant. Ask everyone to write either the number 0, 1, 2, 3, or 4 that corresponds to their level of safety onto the ballot. My experience is that some people will, regardless of the instructions, write a decimal number. Simplify things for yourself by informing everyone that all the ballots will be rounded so that the results fit the range of the gradient.
Ask them to cup the ballot in their hand so that no other participant can see their rating. Stress to everyone that you don’t want anyone to share their rating with anyone else, regardless of how safe they personally feel. Again, emphasize that only you will see their ratings. Have the participants fold the ballot in half and place it in a container, such as a hat.
Ask a participant to help you build a histogram of the poll. I suggest that you use a flipchart so that have a hard copy of the histogram to use when your write up the minutes of the meeting. Pull each ballot out of the container one-by-one and read the score to the person building the histogram. Stuff the recorded ballot into one of your pockets or put them in your briefcase so no one else can or will ever see it. Note, you are not only revealing how safe people feel — you are also building safety by checking in a way that reinforces safety.
Figure 2 shows an actual histogram built during a requirements gathering meeting that I facilitated at a large manufacturing company.
| Level | Description | Number of people |
| 4 | Secure | ********** |
| 3 | Safe | * |
| 2 | Neutral | **** |
| 1 | Dangerous | **** |
| 0 | Treacherous |
Figure 2. The histogram of an actual safety check that was built during a requirements gathering meeting. How do the participants who feel completely safe help the participants who feel threatened?
Ask the participants, “What is your interpretation of the histogram?” A manager in the requirements gather meeting told all the other participants that they needed to start trusting each other. His management colleagues vigorously echoed his belief. And his colleagues had a lot more to say about the importance of trusting each other. I let this discussion continue for 10 minutes and asked, “What cluster of people on the histogram do you think is offering the most advice?” The room fell silent. The people who felt the safest realized that they were doing the most talking. And they realized that the people who felt threatened weren’t talking.
Telling people how they should feel doesn’t work. And, in my experience, people know that as a fact but forget to put that knowledge to work. It helps to give them a gentle reminder. Ask everyone, “How do the participants who feel completely safe help the participants who feel threatened?” The answers I have heard in meeting after meeting can be summarized in two words: 1) Care and 2) Listen.
During the manufacturing meeting, people did start to care and listen. The participants slowed down and asked each other questions. And, most importantly, they were okay with moments when no one spoke. I believe that silence is a gift. It shows people that you are ready and want to listen. And, in the case of a meeting, silence demonstrates that the group is ready and wants to listen.
These changes made a big difference in the requirements meeting. The discussions were deeper. And the enriched conversation enabled them to discover requirements that would have been invisible to them. They were more effective together than they had ever been.
Another method that can help create safety, especially in large groups, is to let the participants build the safety guidelines for their meeting.
Split the participants into small groups. The ideal size is a triad — 3 participants. Ask the groups to 1) introduce themselves to each other, and 2) create a set of guidelines for conducting a safe meeting. Give them a few test cases to ponder. For instance, someone starts blaming someone else, someone tells an inappropriate joke, someone dominates the meeting, and so on. Let everyone know that they shouldn’t limit themselves to the test cases. You want them to share any guideline that will make the meeting safer.
The hope is that the discussion will help remind people of what they already ready know about safety and remind them to practice what they know. And, just as importantly, the hope is that a connection with a small, manageable number of people will increase safety.
Have each small group introduce their members and share the safety guidelines they created to everyone. You will be amazed at the wisdom that people have about safety. Gain agreement from everyone on which guidelines to accept. Remind them that the guidelines are theirs rather than yours. If someone violates a guideline, you will call them on it.
Ask the group to monitor your facilitation and to inform you if you allowing any deviation from the agreed upon guidelines. When someone mentions a deviation, treat it with the utmost care and respect. It’s the ultimate demonstration of the value you put on safety.
Regardless of the method used, you can never be absolutely certain that all the participants feel safe. If someone would have asked me how safe I felt during the meeting with Harry Fox, I would have voted neutral or safe so that Harry wouldn’t find out.
The best that you can do is to solicit and respect everyone’s ideas. The leader that models appropriate behavior in meeting after meeting is constantly renewing and enriching safety and productivity.
Be a leader. Care. Listen. Model the behavior you want.
A special thank you to Jean McLendon for making me aware of the importance of safety and how to measure it; Jerry Weinberg for suggesting that the number one isn’t nearly as evocative as the number zero for connoting the absence of safety; and Esther Derby, Don Gray, and Jerry Weinberg for sharing their feedback about this article.
convert this post to pdf. © 2005 Johanna Rothman (This article previously published in Better Software.)
The last few times I’ve taught project management, I’ve explained that multi-project context switching wastes time. The project managers agree with me. But then they ask the question, “How do I explain this to my management? They refuse to believe me.”
Managers, especially senior managers, don’t believe context switching wastes time because all they do is context switch. Senior managers frequently have several projects in the air, most of them waiting for input from other people. But that’s not how technical projects work. Most of the time, technical people are not in wait states, but can continue to work productively on projects. Senior managers don’t understand or remember that the work technical people perform is substantively different from the work they perform.
So to reach managers and convince them that context switching is a bad idea, make sure you speak their language. First, set the stage by explaining how technical work is different from management work. Next, help your manager determine the relative priority of each piece of work. Finally, block out the work, and keep your management apprised of the status.
Here?s one example I’ve used when explaining how technical work is different from management work. Assume you work for a bank, and you have three post-release fixes to complete. One fix is for the branches, for a particular type of new accounts. One fix is to change the format of particular data you send to the Federal Reserve. And the last fix is in the reporting software that the branches use to report a variety of measures to headquarters.
You’re the technical lead for a group of four other people(a total of five people), and each fix will take two calendar weeks to complete. That’s a cost of ten person-weeks for each fix, a total of 30 person-weeks. Because the fixes are in unrelated systems, you can’t batch any of them together. If you perform the work for each fix serially, at the end of six weeks, you’ll have all three fixes ready. (see Figure 1.)
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Weeks 6 |
| Start Fix 1 | Finish Fix 1 | Start Fix 2 | Finish Fix 2 | Start Fix 3 | Finish Fix |
Figure 1
If you context switch, the best case is the first fix is finished at Week5. The best case assumes that each person working on a fix spends the entire week working on a particular fix. Between each week is a bit of time context switching to remember the state of the fixing. In my experience, it’s more that the first fix would not be ready until about week seven, the second fix at week nine and the third at about week eleven ?if not later (see Figure2).
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Weeks 6 | Week 7 | Week 8 |
| Start Fix 1 | Start Fix 2 | Start Fix 3 | Work on Fix 1 | Finish Fix 1, Work on Fix 2 | Finish Fix 2 | Work on Fix 3 | Finish Fix 3 |
Figure 2
But that just represents the pressure on the technical staff. Don’t forget the pressure on senior management. In this example, in between their meetings, presentation development, document review, voice mail, and more meetings, three people are calling your VP and leaving urgent voicemails, emails, or stopping by your VP’s office.
Stacy represents the Federal Reserve auditor. She says, “I really need that fix for the Fed, and I need it right away. Your guys are working on my fix, right?” Betty represents the branch managers. She’s left your VP several emails and voicemails, each saying “Another call from a branch manager. This problem is costing us a fortune in back-office support to create those accounts with those workarounds.” And Dan, the CFO, represents the Board when he says, “We need the data from the branches. And we need it before the end of the quarter, so we can get ready for the end-of-quarter financials.”
Your VP is under tremendous pressure to fix all of these problems at the same time. So, first explain how you work, and how working on one fix at a time will get one customer off your VP’s back. Now, help your VP determine the relative priority of each fix.
Each of these three fixes is critically important to the welfare of this organization. And, because there are a limited number of people, management will have to choose a relative priority for each fix. One question I like to ask about priority is, “What are the consequences to the organization if we select this project first?” Then I ask the same question as we review the project list.
Typically, I ask about consequences and risks in terms of regulatory issues, loss of customers, revenue, and ongoing operations costs. Your organization might rank these issues in a different order or modify this list. Then I ask about the data that says this project is urgent. When I worked with this client, we called Stacy and asked about the auditor?s needs for the data. Stacy was being proactive, but the real deadline was another quarter away.
Next, we called Dan, and asked, “Would you rather save this much money in back-office work or receive the branch reports?” Of course, Dan said both, and we explained he had a choice of one. If he didn’t make the choice, we would. He chose saving money in the back-office, a choice that surprised both my client and me.
I’ve been in situations where we really did need to have three things done at virtually the same time. In that case, we staffed each fix with its own project staff, and stopped working on new development work. Now we have three projects in priority order: fix the accounts, then the reports, and finally implement the data format changes.
As you proceed with your projects, make sure you maintain progress on each project. Since you?re not context switching, it’s easier to do that, especially on smaller projects like fixes. Report your progress to management periodically, so they understand you are making progress.
Some of you may be saying, “Well, now I know how to do this for small projects. But I?m managing three big projects, all with the same thirty people. Each project is a year long. How the heck do I stop context switching on these projects?”
First, perform risk analysis for all of the projects, developing a list of projects in relative priority. For larger projects, your management may not be able to or willing to define the relative priority for each project using the issues of regulation, loss of customers, loss of revenue, enhancement of revenue, or reducing operations costs. Two projects may appear quite similar. In that case, either consider how you prioritize projects (which may be out of your control) or consider changing how you develop projects (in your control).
One technique I’ve used is to move to month-long iterations when two projects are competing for the same people at the same time. Even after attempting risk analysis, if my management still can’t make a decision, I either assign half the people on one project and half to the other, or I select one project. Either way, everyone works on their assigned project for one month, and shows some visible progress. Then I ask management to look at the progress we?ve made. One technique to accomplish this is to implement by feature. If no one looks at the demo or our visible progress, I stop work on that project and move everyone to the other project. If management reviews our progress, I verify that this project is still the highest priority,and continue work. If I’ve staffed both projects with half the people, and management is happy about our progress, we continue with that staffing. Otherwise, if this is enough project work on this project for now, we move to the other project.
Context switching at a one-month boundary isn’t great, but it’s better than the alternatives. But in order for this to work, you need to show demo-able software. It doesn?t have to be release-able, but people outside your project have to be able to see your progress.
Context switching is insanity, because it guarantees everything will be late. You don?t have to live with multi-project context switching. It requires an understanding of the differences in work between technical people and management. You may need to lead the risk analysis and ordering of projects. And when you’ve selected a project and started working,make sure you can show people your progress at reasonable time periods. It’s hard work to stop multi-project context switching. But the rewards are worth it.
I thank Dwayne Philips and Leo Hepis for their review.
convert this post to pdf. ©2004 Johanna Rothman www.jrothman.com
Introduction
If you’ve hired new people or transferred people into your group, you know that they’re not immediately productive when they start. If you’re lucky, they start to be useful in a month, but you most likely spend closer to six months or even a year before they raise the entire group’s productivity. One technique for bringing a new employee up to speed quickly is to assign that person to a buddy, someone who will mentor the new employee through the first few days and weeks on the job.
If you’d like to bring new hires up to speed quickly, or if you’d like to cross-train your group, try a buddy system.
A buddy system at work is nothing like the buddy system you might have experienced in a pool when you were a kid. You didn’t get into the pool without your buddy, and when the whistle blew, you and your buddy found each other. You and your swim buddy were there to watch over each other, to make sure you both knew where the one was. This is not your child’s swim-buddy system.
A buddy system at work is a technique to help already capable staff learn how to apply their skills more quickly, to reduce the floundering that occurs at work when a new hire starts.
Here’s how to think about the knowledge necessary for work:
Functional skills: what the person knows about their job (development, testing, project management, writing, etc.) People learn these skills at school and on the job.
Product Domain Expertise: how people understand the product and the product domain, and how they apply those skills to the product. People learn about the product and its internals by working with products.
Tools and Technology: how well the person knows the tools of the trade: compilers, testing tools, defect tracking tools, databases, and so on. People may learn some basic skills, but most skills are learned on the job.
Industry Knowledge: what the person knows about the kinds of people likely to buy your system, and the general expectations of the your users. People learn about the industry by working in it, on the job learning.
Your new hire already has the functional skills?that’s why you hired that person. But the new employee may need product domain expertise, both in the problems the customer has and in how your product solves those problems. Your new hire needs to know how you’ve customized the tools and technology you use. The more you can help new staff understand your local environment, the faster they will adapt to your environment, and the more quickly they will contribute to the overall efforts.
Creating a buddy system requires that you have people who are willing and able to mentor others. In addition to the mentors, you’ll need to document a few key pieces of information: the physical layout of the building and the security, where the tools are located and how to use them, where the project information lives, and some information about the product internals. The more documentation you have, the less the new staff will interrupt the experienced staff.
The documentation doesn’t have to be a huge honking binder. In fact, if you can keep the information to one web page or one to two printed pages, the information will look accessible and not threatening to the new hire.
When someone new starts at work, that person needs to know everything, from how to use the phone and voicemail systems, where the bathrooms are, where the lab equipment is, to how to use the tools of the trade, such as the defect tracking system or the configuration management system, or even the compilers.
When you first assign a buddy to a new person, the buddy acts as a guide, to explain where everything is. If you’ve never had a buddy system in place, this is a good time to document the locations of everything, including the physical facilities and tools. Once the locations are documented, the buddy can explain once where to discover more information, and you’ve already farther ahead for the next new person.
On the first day, it’s helpful if the buddy can take the new employee to lunch, preferably with a group of people in your cafeteria. If you have no cafeteria, choose a lunch location that most people use. Sometime during the first day, the buddy can demo your products or applications to the new hire.
After the first few days, the new person knows where the cafeteria and the bathrooms are, and has probably started reading product and tool documentation. The buddy is available to answer questions about which platforms to make sure to compile on before checking in code, or how you use certain databases, where specific tools are, and so on.
During the first few weeks, discussing architectural or design tradeoffs with new developers, test strategies and choices with new testers, or project monitoring specifics with new project managers will help the new employee understand the context of how you work, which choices you’ve already made, and how to make sure the new employee’s work fits into your environment. As the discussion moves past the basics, the buddy has moved from guide to mentor.
You may choose to have a formal ending to the buddy relationship after one month. If so, one way I’ve found useful is to mark the new hire’s 1-month anniversary in a group meeting and say, “John is now experienced enough to not need the formal services of a buddy. Thank you Steve, for taking on the role of the buddy. John, you can ask questions of any of us at any time, and hopefully you can take on the role of a buddy to a future new hire.”
Even when you’ve planned for a buddy system, things can go wrong. Here are some common problems:
The buddy assigned doesn’t want to be a buddy. Some people don’t want the responsibility of helping someone new acclimate into a new job. Sometimes, they’re not temperamentally suited for the role (such as people who are so shy or introverted they have a difficult time speaking in public), or they are on the critical path for some deliverable, or they don’t feel as if they know everything the new person needs to know. If your employee doesn’t want to be a buddy, don’t demand that that the employee be a buddy. Instead, understand why your employee is reluctant, and work on that problem. One caveat: if the employee is too shy or introverted to easily speak with a new hire, find other ways that employee can help new hires. Don’t demand someone perform the buddy role when they are nervous around new people.
The buddy inflicts help on the new hire. Some people are so inspired by their buddy role they give unsolicited advice about the new hire’s work. The buddy needs to provide advice about how the work is performed at your organization, not how to design or how to test or anything else, unless the new employee has requested peer review.
The buddy performs the new hire’s work. Another form of inspiration is to take over the new hire’s work. One of the common reasons I hear for this is, “It would take me less time to do it myself.” Well of course it would. That doesn?t mean one employee can or should take over the work of another employee. The first few months are when you can expect the new hire to be less productive. Don’t allow a buddy to short-circuit the new hire’s learning experience.
The buddy stops being a buddy before the new hire is ready. If the buddy takes a vacation or has a trip during the first crucial weeks, the new hire is left stranded. The new hire and the buddy have already created a relationship. If the new hire has to create another relationship with a substitute buddy, the new hire is less likely to ask the necessary questions.
If you’re concerned about single points of knowledge in your environment, you can also use a buddy system for cross training. In this case, the buddy assumes the new person only needs product domain expertise, or alternative techniques to applying functional skills to the new product domain. When you use a buddy system for cross training, make sure the two people develop a list of milestones where the already-knowledgeable person performs less and less work over time. That way you and the person learning this area both have feedback about how well the new person is learning the product.
When I use a buddy system for cross training, I assume it will take the people about three months to transition the product knowledge, unless you have very short releases.
Creating a buddy system for a new hire isn’t difficult, but does need to be handled with care. Make sure you’ve chosen a buddy who is willing. Create the minimum set of documentation, and revise it as you hire new people. Set an end date for the formal buddy relationship. Watch for pitfalls so you can guide both the experienced and new employees.
A buddy system can dramatically reduce the time a new hire requires to be productive. A new hire will need to ask questions anyway, so make sure you have an effective system in place to deal with those questions.
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:
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. ©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:
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. ©2005 Johanna Rothman
This article was originally published on Stickyminds.com
Your CIO has two projects he wants finished in the next month. “We can share this project manager and that test team on both of these high-priority projects,” he declares confidently. “The projects are small enough that the teams should be able to make progress.” Two weeks later, the CIO realizes neither project is progressing the way he’d envisioned. What?s going on?
The short answer is that putting the same people on two high-priority projects only creates the illusion of progress. Here’s what really happened.
The project manager worked mornings on Project 1 and afternoons on Project 2. Part of the test group also chose to work mornings and afternoons. But the other part of the test group used Monday and Tuesday for Project 1 and the rest of the week for Project 2 because of the way they needed to work with the developers. The first problem was that the project team, including the project manager and the testers, didn’t work on the same project at the same time.
The project manager and the testers only maintained their time organization for the first week. After the first week, the project manager was an obstacle to both projects, because when he was working on one project he was needed on the other project. Work from Project 1 piled up when he was on Project 2 and vice versa. By the start of the third week, the project manager had not cleared any obstacles for either of the project teams.
The testers couldn’t help the projects make progress either. One of the testers who split his project work into mornings and afternoons discovered a problem that required test data from one of the Monday/Tuesday testers. It was bad enough that the testers had to wait on each other for information, but the developers had to wait for the testers, too. The developers would start to fix problems then have to wait more than a week for the testers to verify them.
In this case, the multi-projecting caused people to be far less productive than if they’d been assigned to only one project at a time.
People pay a context-switching cost when they switch from one project to another. Even if they try to assign half of their time to one project and half to the other, they can’t. People need time to stop thinking about one project and start thinking about the other —particularly the details of where they left off. Multi-projecting doesn’t create more time in the day; it wastes time.
When people divide their time during the day, they switch context more often (at least once per day), paying the context-switching price more often. In the above example, the people who divided their time into mornings and afternoons paid a higher cost than the people who assigned different days for different projects did. The people who switched context only once a week paid the cost less often.
If you’re not sure how much time is wasted by multi-projecting, consider this: The relationship between number of tasks and wasted time is directly related. As the number of tasks increase so do the number of wasted hours. For example, as Gerald Weinberg indicated in his book Quality Software Management, Vol. 1: Systems Thinking, a person who works on two tasks only spends about 40% of her time on each task, wasting 20% of her time. With more concurrent tasks, it’s even worse: a person involved with four tasks spend only 10% of her time on each task, wasting 60% of this person’s time! Clearly, multi-projecting is not a technique for finishing projects quickly.
So what could this CIO do to complete both high-priority projects in the desired timeframe?
In this case, the problem of two small, short-duration projects using the same staff with unplanned and unplannable interactions, the CIO could first decide which project is higher priority. The CIO could then assign the entire team to that project, and, using release criteria to make sure the minimum work is done on the first project, as people come off of that project, start them on the next one.
People do not multitask easily because of the context-switching cost. It is easier and more productive for people to continue working on the same project, at the same level, for as long as possible. It costs time and brainpower to switch to another project or to another activity. Rank your projects, and make sure people know what done means, so they only do the minimum necessary. Don’t fool yourself with an illusion of progress; make the progress real.
Acknowledgements:
I thank Elisabeth Hendrickson and Frank Patrick for their reviews of this column.
convert this post to pdf. ©2002-2003 Esther Derby, www.estherderby.com
People who work in software are smart people. We take pride in our ability to understand complex information and solve difficult problems.
What about that other IQ, our Influence Quotient?
To some of us, influence is a dirty word. We think of influence peddling, organizational politics or strong arm tactics along the lines of “I made him an offer he couldn’t refuse.” But much of the work we do depends on our ability to work through and with other people, and that means influence. You don’t have to be in charge to have influence; the elements of influence are available to us every day.
Let’s eavesdrop on two conversations to see what we can learn about influence.
Brandon has been charged with designing a new table structure for the next product release. He’s also been told to reduce the pain of installing new versions of the software for existing customers. He knows there are two requirements in the backlog that will require table updates: one requirement is scheduled for this release and one for the next. He’s figured out how to design the table to accommodate both requirements with one table change, which means customers will need to do only one database conversion, instead of two.
Brandon needs to convince Cindy that his idea is the right approach, so he stops by her desk and walks through his design:
Cindy: “You can’t do the tables that way, Brandon,”
Brandon: “Let me tell you why I designed it this way?”
Cindy (cutting Brandon off): “We’ll have to write lots more code in the application with this table set up. Did you think of that?”
Brandon: “It might take another access call, Cindy, but in the long run, it provides much more flexibility.”
Cindy: “We’re going to have to write 10% more code, at least. And then we’ll have to test it all. It’s a bad idea.”
Brandon: “I don’t agree, Cindy. It’s not going to take that much more code. And there are several advantages to this design.”
Cindy: “Do you really want us to blow our project deadlines? Is that what you want?”
Brandon (trailing off): “No, of course, I don’t want you to miss your deadlines…”
Brandon felt like he was being pressed into a corner and it felt like Cindy was picking a fight.
After a couple more brow-beatings from Cindy, Brandon gave up and re-designed the tables the way she wanted them. Arguing with Cindy wasn’t worth it.
Cindy, however, felt a little twinge of pride. She believed that she had exerted her influence and moved Brandon to see things her way.
Cindy is exhibiting one sort of influence, perhaps the sort that gives influence a bad name: browbeating and emotional manipulation.
Brandon is missing the influence boat, too. He didn’t ask Cindy what she needed or what her concerns were to see if they had some common ground.
Brandon made two other mistakes:
In another part of the country, Jason and Tom are working on a virtually identical project:
Jason: ?Tom, the customers are really screaming about having to convert their databases with every release. I think I’ve found a way to eliminate a conversion for the next release. Is this a good time to walk through my design??
Tom: “Sure, show me what you’ve got.”
Jason walked through the design.
Tom : “Well, the way you have it set up, we’ll have to write another call every time we access this table.”
Jason : “Ah. That’s true. When I did the analysis I saw there would be an extra call. Can you tell me more about the impact you think that will have?”
Tom : “Well, I’m worried about writing and testing those calls. We’re already on a really tight schedule.”
Jason : “Can you tell me more about that?”
Tom: “The project manager is sweating the deadline. We just got hit with a big new feature, and we don’t need one more thing to make us late.”
Jason: “Oh, so your concern is that the extra coding and testing will make you miss your project dates.”
Tom: “Yep, I don’t see how we can add this to the plate.”
Jason: “I see. Well, what if we talk to the project manager about the trade-offs and see if we can shift something around to make this work.”
Tom: ?Well, all right. I?ll agree to have the conversation with the project manager.?
Ok, so maybe Cindy would need Prozac to be this mellow. But most people will hear more and be willing to cooperate when they feel like you have heard their concerns and understand that your goals intersect with their goals.
Here’s what Jason did:
So what’s your IQ? What strategies do you use to work through and with people? When have they worked best, and when have they backfired?
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.
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.
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:
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.
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:
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.
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:
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.
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.?
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.