© 2001 Esther Derby and Johanna Rothman. This article was originally published in Cutter IT Journal, October 2001.
Suppose you are a manager in a software development organization that isn't achieving the financial results that senior management wants. The good news is that your management understands that one way to reduce costs is to increase effectiveness of the development processes rather than reduce head count. Your company is doing things right: senior management sponsored a comprehensive assessment and studied the report. There's been a careful analysis of the areas where improvement is warranted. You have a plan to roll out improvements and train the technical staff in the new processes.
You're set for success, right? Well, maybe. Improving software development requires us as mangers to change our management processes, too. What sort of changes are we talking about? Depending on where we start from, we may need to change our view of our role as managers, the way we carry out our roles, and/or the way we communicate. And we may need to change management processes within the organization — policies and reward systems.
So where do we start working on management change? On a purely pragmatic level, changing “us” is the area where we have the most direct influence. And it's often easier to motivate someone else to change their behavior if they've seen us change ours. In this article, we’ll show you a model we’ve found helpful and share some stories form our journeys as management change artists.
Process Improvement Requires a Shift in Management Practices
Implementing development improvements may require us to make a shift in our role as managers. Top-down management where the managers take all the responsibility — make all the plans, set all the schedules, specify all the work— and then check up on their staff to make sure the work was done in the specified manner is the norm in many companies. However, once a process improvement initiative is launched, managers find that their old management habits have to change.
One of the tenets of process improvement is to have people take responsibility for their work, measure their work, to see if the actual results are the desired results. Top-down communications short-circuits the control mechanism. Changing to a more collaborative communications style can be challenging, especially when we've grown up in this style and don't have other role models.
Tom, a software development manager, started reading about the Capability Maturity Model, and decided there were improvements he could make in his group. He gathered his team together, and talked about the kinds of things he wanted to do: hold inspections and reviews, perform nightly build and smoke tests, improve configuration management, and start the testing earlier in the project.
Tom’s technical staff was quite happy to do these changes — these were changes they'd been wanting for some time. One of the older engineers asked Tom, “Well, we can do those things, but we need to plan for them. That means you have to tell us what’s going on so we can plan our work. How are you doing to do that?”
Tom realized that he hadn’t been including his team on all his plans for the upcoming and current projects, and that he needed to change what he communicated when to the team, so they could do their work differently.
Tom also needed to change how he communicated. Tom was in the habit of just dropping by his engineers’ offices whenever he wanted to talk to them. He didn't really see the need to make an appointment (after all, who went to all the meetings and whose work was more important?). This arrangement worked well for Tom, but it didn’t work well at all for the engineers.
As Tom’s group started working more collaboratively, he noticed that the engineers weren't in their cubicles when he dropped by. Tom knew better than to interrupt an inspection, but he was having trouble getting information from his staff.
He decided to change his informal approach to a more formal approach in order get the information he needed when he needed it. Before implementing reviews and inspections, Tom had thought he was the only one who needed information in a timely fashion. Now he realized his entire group needed more information in a timely fashion.
Tom stopped dropping by his engineers’ offices, and scheduled one-on-one meetings with each person, and an “all hands” team meeting. Since they now had issues to discuss as a team, Tom changed the team meetings from status reports to team problem solving and planning sessions. Soon, Tom found he was spending less time on meetings, and more time on solving problems, both with his staff and with his management. A collaborative communications style was more suitable for their work than a need-to-know communications style.
As Tom's view of his role changed from sole decision-maker to facilitative leader his interaction with his team and his style of management changed, too.
If changing our view of management is a key to change, how do we go about it? How do we externalize our own mental models? Often the way we talk about or teams gives a clue to our internal management model. Trouble is, the clues are often easier for others to spot than to see in ourselves.
One of the biggest changes I (Johanna) made as a manager was to reframe how I thought of the people who worked with me. When I first became a manager, I thought of myself as the boss, the controller. As I gained more experience managing, I realized that in many ways, I was the support person to the people doing the work. I changed how I spoke of my staff. Instead of calling my group my “direct reports”, I called them my staff, or the people I worked with.
How do you view the people you work with? One of my colleagues, Jennifer, a childless woman in her thirties, consistently referred to her group of 20-somethings as “my kids”. After a couple of hours of hearing this, I asked her if she respected her team. “Of course”, she said. Then I asked why she referred to them in a less than respectful way, as if none of them were worthy of being her colleague. She didn’t have an immediate answer.
As managers, we have the managerial smarts and context to make the management decisions, but we frequently don’t have the technical expertise to be able to carry out all of those decisions. Even if we did have the expertise, we wouldn’t have the time. Effective change agent managers are willing to let their teams try something, assess the result, and change what’s not working, without having to run to the manager for every decision. That means that the manager and the team respect each other — that each staff member understands everyone else’s talents, strengths, and knowledge — and that the team works together to capitalize on the entire team’s strengths. Respecting your team and setting sufficiently wide boundaries are the hallmarks of an effective change-agent manager.
If you realize that you’re not respecting your team, or that you haven’t set sufficiently wide boundaries, then how do you change your behavior? One way to change your behavior is to recognize that you (and your staff) work differently under different emotional states. When Jennifer realized she was unconsciously setting herself above her staff, she became confused and had a difficult time making decisions until we spoke some more:
Jennifer: So, when I call my team “my kids”, that means I don’t respect them?
JR: Well, it might mean that, but it certainly means that you don’t believe they are working at the same level as you are.
Jennifer: Well, they’re not.
JR: No, they are not managers, but don’t at least some of them have superior technical skills to you? You hired them to do technical work, and you’ve been managing for a while now. Some of them must be great engineers, yes?
Jennifer: Well, yes, most of them are. But they’re still so young.
JR: What does that have to do with anything? If they were 20 years older than you, would you call them my parents?
Jennifer: Of course not.
JR: So, why do you call them your kids, if not to distance yourself?
Jennifer realized that because her team was so talented, she was concerned that she was not as good as they were. By calling her team her “kids”, she was making it easier to show them that she was the person in charge, and that she had value to the team. Once she realized this, she was able to decide what to do and changed her behavior.
We don’t always have a mirror to help us see ourselves as Johanna helped Jennifer see her assumptions and how they affect her relationship with the engineers. But we can start to listen to the way we talk and become more aware of our assumptions. Once we are aware, we can update our models and make choices about how to practice management.
A Model for Change
These two stories illustrate something worth noticing about change. Both Jennifer and Tom were going along, doing a reasonably good job, when something changed for them. For Jennifer, it was a realization that the way she used language and contained a clue about her attitude toward her group. Tom had to change his management practice and interaction with his team as he rolled out improvements.
For Jennifer and Tom, the change (which may seem small to us as outsiders) sent them into a bit of a spin. Both Tom and Jennifer experienced a period of time when their old way of doing things wasn't working, but the new way wasn't quite comfortable yet. Eventually, they figured something out, and incorporated new patterns of behavior. Jennifer and Tom were experiencing a normal human response to change.
We find that understanding this process of change is very helpful in implementing process improvements — or any change. On the face of it, an ” improvement” must be a better idea, a better way to do things. On a logical level, this may be true. What we are really asking of the technical staff is that they change — they way they work, the way they think about the work, the way they think about the work, the way they interact with us. Technical staff will experience the same responses that Jennifer and Tom did.
For many of us, it's confusing when a well-thought out, perfectly reasonable change provokes a strong response in the technical staff or in ourselves. When we are aware that this is a normal human process, we can make better plans and support people through the change.
The Change Model (Figure 1), developed by Virginia Satir, describes the stages of change:
Figure 1. The Satir Change model shows the predictable stages of change and how change affects performance over time.
- In old status quo, life is comfortable and feels “normal.” We're familiar and with our relationships and our tasks. Performance is predictable, though motivation may be low — we're unconsciously competent.
- Change is represented as a “foreign element”; something happens that changes the situation. For Jennifer, it was a realization about calling the engineers in her group “my kids.” For Tom it was opening up his planning process.
- When a change happens, our familiar patterns are shaken up. What used to work doesn't fit anymore. We may feel like beginners again, or that we're loosing something important. Satir called this period chaos. We realize we can’t go in old status quo, but we don’t know what else to do yet.
- Eventually, we have a transforming idea, and we figure out how to work with the foreign element. We understand there’s another way to work
- In integration, we incorporate the foreign element into our internal model.
- Though practice we learn how to function competently in the new situation sparked by the foreign element. We see this in sports and other physical activities all the time. We practice a piece the activity so that our muscles learn how to do all the pieces, so when we put it together, we're successful.
- As we gain mastery and establish a new status quo, we again become unconsciously competent.
Satir believed that this describes a universal process. Our experience bears that out — this is predictable pattern of how people (and organizations) experience change. And the change process has predictable effects on performance for individuals and organizations. The line across the Figure 1 shows a typical pattern for performance during a change: performance is erratic during chaos, and improves during integration and practice.
People go through this process at different rates depending on the change and individual characteristics. For some, the period of chaos may be momentary; for some it may be much longer. When a group goes through change (a department-wide process change, for example), the organizational system will reach a new status quo when the majority of the individuals in the organization have reached a new status quo.
What are the implications of this model for software process improvements? First, expect a period of stress and confusion for all those going through a change, both managers and technical staff. Understand that people may try to reject a change — not because they’re “resisters,” but to relieve the stress and anxiety of the chaos stage and return to a familiar old status quo. People need support during this period of change in order to stay with the anxiety long enough for the new process or method to have a chance. Change agent managers can also limit the number of changes that staff has to absorb. Changes that come one at a time with some space in between are more likely to succeed than changes that are piled on top of each other all at once. If possible, plan a simple, small change first to give a positive experience with change and built confidence for the next change. Avoid the temptation to throw out the new method when the inevitable (and temporary) drop in performance hits.
Plan time so that people can reorient themselves and integrate the new process or method. Provide opportunities for people to practice and gain mastery. Hooking up groups of people who are going through the same sort of change process can be helpful — they can support and learn from each other as they incorporate the new process. People will still experience some ups and downs, but most likely not everyone will be in a dip at the same time, and they will be able to buoy each other up.
Once a new status quo is established, it's time to get people thinking about the next change before the low motivation of old status quo sets in.
Plan for Success — Analyze the Organizational Risks
If this is a normal human process we will all get through it and emerge on the other side confident in our new skill, right? Not always. Like any other journey, things can get off track. We've seen a number of improvement initiatives that didn't succeed because existing management processes and policies worked against the change.
Let's take another look at the change model. Figure 2 shows a different view of the model  that demonstrates how an organization (or individual) can revert to chaos or old status quo at each stage of the change process.
Cretinous Cost Cutting
At Cerivion (a corporate pseudonym), the technology department identified an imperative to move to a new development language that implemented OO concepts to build their next generation of products. Cerivion's development group sent staff to training and then planned to hire additional people OO experts on contract to coach and mentor the current staff as they gained experience.
Cerivion also had a corporate initiative to reduce costs. What's an obvious and easy place to cut development costs, one of the first places that corporate cost cutters look? Employee salaries and contractor wages. The folks in the accounting department (who didn't have expertise in software development) did a salary survey to establish the average rate for contract developers. The survey included all classes and skills of developers, from COBOL programmers to developers with specific and rare expertise. From the salary survey, the accounting department established a policy that capped the rate the development managers could pay contract developers at $75. However, the going hourly rate for people with the desired expertise in the geographic area was $150.
The rate cap made it nearly impossible for development managers to hire the mentors they needed to develop their own mastery in the new language. Cerivion developers implemented the language, but were unable to use its full capabilities.
Cerivion was able to make the transformation — understand how the new language would fit into their existing technology portfolio and how it would support moving forward with new products. Still, developers didn't have the support they needed to practice and gain mastery with OO design constructs. On paper this change looked like a success: the language was implemented. But without implementing the OO constructs, Cerivion incurred the financial and performance cost of the change without realizing the benefits in increased capability.
Figure 2. The Flow of Change shows how an individual or organization can revert to Chaos or the Old Status Quo at any stage of the change process .
Putting Your Money Where Your Mouth…Isn’t
At American Unifeed (another corporate pseudonym) an effort to implement technical reviews was stymied by performance systems that rewarded meeting interim milestones and delivering on the original schedule and budget. In most cases, implementing the practice add costs and extend schedules during initial implementation, as staff members learn new skills or add additional rigor. For projects already under way, new tasks associated with new processes have probably not been included in scope or budget.
American Unifeed senior management decided to implement technical reviews on all projects, but project managers who had performance targets and bonus set prior to the review initiative were unwilling to jeopardize rewards by incurring the initial overhead of reviews. While we may argue that this is shortsighted, a reward system that is not aligned to corporate objectives can do just that: reward short-term goals (e.g. meeting original schedule and budget targets on individual projects) at the expense of longer term goals (e.g. reduced defects and rework or more predictable project performance across many projects).
American Unifeed wasn't able to accommodate the change within the existing model. Because the reward system actively incented people against implementing practices with perceived short-term schedule impacts, the new practices were rejected.
Giving Credit Where Credit Isn’t Due
Informal and nonmonetary rewards can affect morale and progress in an improvement effort, too. Companies often bestow “engineer of the year” awards, or hold dinners and highlight activities and accomplishments of a select few individuals. However, software projects are always composed of teams of more than one person. When teams do the work in collaboration, it’s quite difficult to choose one specific person to award; in fact, it’s inappropriate to choose one person from the team to reward.
Most software process improvements are team efforts are also team efforts (e.g. inspections and reviews), and it’s impossible to simultaneously reward an individual’s effort and reward improvement work.
I (Johanna) once worked at a company where engineers were publicly rewarded for their work. Unfortunately, testers, writers, and project managers were never awarded anything for their work, although it was an “Engineering Awards Night”, and we were all part of engineering. The day after one of these events, one of the writers sent a flaming e-mail to the all-engineering list, saying that if management didn’t appreciate that other people contributed to the development of the product, they could take their awards and hide them in a certain part of management’s collective anatomy.
One of the managers came to investigate, and discovered that the writer had actually influenced the product architecture and test architecture. In fact, the writer had been the most influential person on the product, and if there was one person to reward, the writer should have been the one to reward. Instead, the writer wanted group acknowledgement of the team’s efforts.
Singular rewards are generally inappropriate, and can lead to disgruntled and unhappy employees. Software projects are collaborative, and the reward system needs to recognize that collaboration.
Obstacles Are Not the Final Word
Organizational stumbling blocks can exist in any organization. This doesn't mean that managers should give up on making changes if corporate systems aren't aligned to support the development process improvements. It does mean that change agent managers need to look for ways to smooth the path for implementing improvements. Forearmed with knowledge of likely obstacles, managers can identify options that reduce the inhibiting effect or strengthen a supporting effect to compensate.
For example, Cerivion development managers could have looked at other options to fund mentoring. Perhaps they could have negotiated an exception to the contractor rate cap, created a budget that covered incremental costs of the change effort. They might have decided to change their strategy to include hiring people who had the expertise they wanted to establish. These are strategies that we've seen work at other companies.
American Unifeed faced a reward system that didn't motivate the behavior they were looking for. American Unifeed might have exempted projects that were already underway, renegotiated performance targets or implemented reviews in a smaller way, using pilot projects to demonstrate the value of reviews and work out the kinks.
These alternative are all strategies that we've seen used successfully by change agent mangers who identified systemic obstacles before rolling out a change effort. Even when managers consider the organization and try to understand the force field surrounding the change, we probably won't identify every factor or every thing that could go wrong. In this aspect, change projects benefit from the same sort of risk management and ongoing assessment that would be used on any development project.
Who’s Blocking the Change?
Sometimes, we’re our own worst enemies when it comes to process improvement. A single manager can seem to derail a change or keep the organization in a familiar (and not always comfortable) status quo. Sad to say, sometimes managers are not part of the solution in implementing improvements, we're part of the problem.
In one company, one person succeeded in quashing a bug triage. Faye, a test manager, was implementing bug triage for her product group, which involved negotiating defect severity levels with her key stakeholder, Ruth. Ruth agreed to the severity levels, but when it came time for bug triage meetings, she declared the meetings were a waste of time, a ploy that allowed the developers to avoid attention to detail. Ruth insisted that all defects, no matter how minor, be fixed before the product was installed.
Because the team had limited resources the developers and testers did an internal prioritization based on their perception of business impact and severity levels. The team worked on critical bugs first.
Ruth generated new bug reports for each unfixed error found in the next test run. With each test, Ruth ratcheted up her invective in reporting minor bugs that the team had decided to defer while they worked on critical defects.
After several weeks of testing, both developers and testers were resentful and angry. On the next project, the team reverted to their previous practice of fixing defects in the order they were logged, whether they were important to fix or not. The team's attempt at rational allocation of resources (fixing high severity bugs first) was undermined by Ruth's behavior.
David was a VP of engineering who wanted his managers to make better estimates and ship products sooner. David hired Johanna to help him get his managers to improve estimates. When Johanna asked the managers for data on estimates and actuals, they refused to turn over the data.
Puzzled, Johanna asked why. “We know how to estimate,” the manager replied. “What we need is to have David stop lopping 20% off the top of every estimate we give him. We need him to believe that we're competent and know how to do a good job. We need him to believe we truly want to do the best we can.”
David believed that his managers needed to be “pushed” to do a good job. He felt that if he cut the estimates by 20% managers and staff would “give their all” to meet the goal — and if he didn't the work would expand to fill the available hours.
The result was that every manager in the organization inflated estimates by at least 20%, knowing that the extra would be chopped. Sending a realistic estimate to David would result in an impossible schedule when he did his standard 20% chop. None of the managers were willing to publicly track effort hours, knowing that David would push for another reduction in the name of “stretch goals.” None of the managers were willing to try to measure and improve knowing that whatever they did, David would continue to chop 20% off the top.
L’Etat C’est Moi
NewBoard (another pseudonymous enterprise), started up as a very closely held organization. The CEO was accustomed to making the decisions. As the organization grew, he delegated some of the decision-making, but ridiculed his managers when they made mistakes.
Eventually, the managers at NewBoard (and the staff, who witnessed the ridicule) became risk averse. Every decision was made by consensus, and the goal was not to make the best decision, but to make the decision that would keep the CEO happy.
The managers at NewBoard, don’t see themselves as risk-averse. They see themselves taking educated risks, working carefully to eliminate the unknowns before they make a decision, and aligning every decision with the strategy laid out by the CEO.
Implementing improvements at NewBoard is risky. If the change doesn’t have immediate results (remember the predictable dip in performance seen in Figure 1?) or the CEO doesn't like it, the improvement is halted. The manager is berated in front of his or her peers, and probably looses any influence and status he or she had. Some managers have lost their jobs for making improvements that turned out to be unpopular with the CEO.
Changing Internal Management Models
We may recognize colleagues in these stories, and we may even see a glimmer of ourselves. None of us is perfect, and if we haven't had the luxury of mentoring and coaching as managers, we may not know any other way to manage. In organizations where managers punish mistakes or believe people are lazy and need to be pushed and threatened to do good work software process improvement will have a hard time taking hold.
When mangers like Ruth and David predominate or in environments where mistakes aren't tolerated, shifting the management culture becomes the first step in implementing software process improvements. We have learned, as did Jennifer and Tom in our early examples, that our internal models of management drive much of our management behavior. And we are in charge our own internal models: we can change as we take in new information (as Tom did) or when someone holds a mirror up for us (as Johanna did for Jennifer).
How can a change agent shift someone else's internal model or image of management? A frontal assault seldom works. But with gentleness and respect, change agent managers can sometimes influence another manager's view. Sometimes having a neutral outsider facilitate data gathering and reflection can help. In some cases, it's most productive to work on a small change and win others by attraction — it's hard to argue with results.
Before the rollout happens, we, as managers, need to examine our part in making improvements stick. The first place we need to look is at ourselves. Are our management practices supporting the change? Are we willing to make changes along with the technical staff? Are our management practices and systems supporting the change or working against it? The changes we make in management communication, management action and organizational factors will smooth the way for real and effective improvements to our software processes.
We wish to thank Dale Emery and Steve Smith for reviewing early versions of this article.
- Satir, Virginia, et al. The Satir Model: Family Therapy and Beyond. Science and Behavior Books, 1991.
- Weinberg, Gerald M. and Dani Weinberg. “Readings for Leading Organizational Change.” Weinberg and Weinberg, photocopy.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.