by Johanna Rothman. This article was originally published in Software Devleopment Magazine, December 1999.
I've had great managers, and I've had lousy managers. The great managers always seemed to be pushing forward, solving problems and thinking about better ways to do things. The lousy managers repeated their mistakes on project after project; they claimed to want to solve problems but didn't take the time to learn how to avoid repeating them.
When I became a manager, I wanted to foster an environment which encouraged problem solving and professional growth, where learning would be a part of the daily work I did with my staff.
The first change I made was to stop having roundtable status meetings—those boring encounters in which you, the manager, have serial one-on-one conversations with every employee. Ostensibly, you're informing each person of what everyone else is doing, but in reality, these meetings are solely for your benefit. Your staff could better get the intended benefit of those status meetings if you wrote an e-mail to the entire group explaining people's achievements and their current activities. Individual project status is more effectively tracked in a one-on-one meeting.
So what do you do if you've eliminated status meetings? You still get the group together periodically (weekly is good), but use the time to solve problems as a group, share lessons from past projects, study pieces of current work in detail and learn from experts. I've used these techniques—including mentoring, self-study and formal continuing education—for more than 10 years, and they work for me.
“Two heads are better than one” is a truism. That's why we do formal and informal peer reviews. Every group has problems at work, and some of those problems require more than one person's brainpower to solve. Why not take an hour once a week to explore those problems with your staff and see what solutions they can create as a group? You can facilitate brainstorming sessions, affinity grouping (silently grouping similar issues and naming that set of issues), or discussions about how to make something work better.
I've used this technique with both development and test groups. In one development group, we were working on bleeding-edge projects and couldn't always estimate when we would be finished. We started with a specific project and composed a list of questions that we could ask at certain milestones to know whether we'd really reached them. We then tried—unsuccessfully—to come up with generic questions for the same milestones, discovering in the process that the set of questions for the “complete prototyping” milestone for one performance-based project was different from a new algorithm project's “complete prototyping” milestone.
In another case, members of a test group came up with competing approaches for the automated test suite. One person wanted to keep all the tests independent, while another wanted to create dependencies within them. Instead of fighting about it, we used our problem-solving techniques to discover the real problem and come up with a solution. We realized that the same test suite was being used both for performance testing and functional testing. We chose a different architecture for the automated test suite and lived with the differences in testing until it was ready to use.
Group problem solving also can be useful as a team-building exercise when applied to the question: “What is the job we're supposed to do here, and how can we do it effectively?” Even on the occasions when my managers believed it was my job to define that, I received wonderful and necessary input from my staff.
One of the best and cheapest sources of learning is past experience. Project retrospectives (also called post-project reviews or post-mortems) are facilitated meetings that discover what worked and what needed improvement in a project. These are ideal learning opportunities. If you're not performing retrospectives now, start. You may hold a complete retrospective on an entire project or use mini-retrospectives to focus on one project portion or phase.
To effectively run a retrospective, use a facilitator who can keep the meeting moving along and maintain an impartial perspective on the issues. If you were not involved in the project, you can facilitate—otherwise, get another trusted manager or someone from outside your group.
Most retrospectives follow this pattern:
- Brainstorm about what happened during the project: what went well and should be repeated, what needed to change and what surprised you about the project.
- Group similar symptoms together to identify larger problems.
- Develop an action plan to address how to improve the areas that provide the most potential for doing more things efficiently and fewer things badly the next time.
The more retrospectives you do, the better you get at them. If you apply your lessons learned to the next project, you've taken a great stride toward continuous professional improvement.
Pride of Ownership
When people are excited about their work, they want to discuss it with others. Take advantage of that excitement by having staff members periodically present a small facet of their work to the group. This is not a status report; rather, it's an explanation of a technique, of how something works or of how it's tested.
I've had people explain how specific algorithms work, how they put together a test suite, or how they debugged a subtle coding error. These are instructional presentations, not hypothetical, visionary musings.
Once, when I was trying to get peer reviews accepted in an organization, two developers came to me and said they wanted to describe their alternative way of working in a two-person, real-time coding team. This work style is rare but extremely effective. We then contrasted that technique with more traditional peer-review techniques. No one in the group was willing to work the way this two-person team did, but some team members started asking them for informal peer reviews more often.
You're probably not clairvoyant, so you don't have perfect knowledge of what's going to happen in your company or in your industry during the next few years. However, you and your group are collectively smart. If your entire team determines the technologies and techniques each member should study, you can broaden the group's expertise. Alternatively, invite experts to advise on future issues critical to your group's success.
To create internal experts, first let staff members define the areas they want to learn about. Then, ask for volunteers to investigate individual items on the list. Schedule a report on the findings at another group meeting.
Some managers are reluctant to create internal experts. I've heard questions like “Our product is never going to be used on the World Wide Web—why does so-and-so want to know how to create web applications? If he learns, he'll leave.” There are two reasons to create internal experts. First, if your team members see you as someone who stands in the way of their learning, they will likely leave anyway. Second, specific expertise may not apply to your current product line, but at some point, this knowledge—or the way in which it was acquired—may be very applicable. You don't want to be stuck with people who aren't interested in learning new things, do you?
You may already have internal experts, especially for tools you are using in-house. I've found it useful, for instance, to have the defect tracking system administrator and the release engineer discuss with the team how they organize and administer defect tracking and configuration management. For other tools, organize an in-house user group through which users can share their problems, techniques and tricks.
Calling on Consultants
If your staff members are initially reluctant to increase their expertise, invite representatives from other departments or projects to give short talks. At commercial software companies, I've had marketing people talk about campaign lead times. That helped developers understand why being able to predict a schedule was so important. At information technology shops, I've had the users talk about how the applications we developed helped them. Many times, our customers utilized the products in ways we hadn't anticipated. In one case, we realized that the customers actually wanted small frequent releases, so they could figure out the next set of requirements and we could then plan the product's architecture.
Many years ago, when I was a software quality assurance manager, my group was having trouble testing a variety of network protocols. Few of the protocols worked the first time or even the second or third time. I envisioned an automated test suite we could use as a first-smoke test to see if the protocol was ready for testing. The idea sounded great, but how would we implement it? We decided to have different developers join the SQA group meetings to discuss the mechanisms and the advantages of their particular protocols. These talks were limited to an hour each so that we could absorb the material. This made the speakers focus on the necessary information and let us ask pertinent questions. We were eventually able to create smoke-test architecture, although the specific tests were different for every protocol.
Look to the Outside for Help
An outside expert's perspective is often invaluable. Almost every region of the United States has free or low-cost local professional society meetings, such as those held by the Institute of Electronic and Electrical Engineers (IEEE), Association for Computing Machinery (ACM), Software Process Improvement Networks (SPINs), and American Society for Quality (ASQ). During the meetings, industry, academic, and professional speakers explain technologies and techniques, give examples, and sometimes present experience reports. Look for ways to apply these scenarios to your own situation.
Consider inviting outside experts to come in and talk about specific technology or projects. These experts could be knowledgeable friends, colleagues, professional consultants, trainers or speakers.
Another approach is to select one or two people to attend a conference and write a trip report to share what they learned with the rest of the team. The more people you can send to conferences, the better your results will be. They will hear from people who work differently from the way they do, giving them the opportunity to consider applying new approaches.
Authors are also external experts. Create a professional library with book and periodical budgets. Each month one person chooses one book or periodical and reports on it. If people are concerned about spending too much time on preparing for the report, they can choose to read one article or one chapter, and report on just that. If you find a really good book, buy everyone a copy. Deciding which books you should buy for everyone that year could even become a contest.
My staff and I learned the most when one of us disagreed with an author about a particular problem. We prepared for the hourlong discussion by sending around our points of agreement and disagreement, and then we discussed those points in the meeting. Sometimes we ended up agreeing with the author, and sometimes not. Our initial disagreement and discussion taught us more than we could have learned alone.
Back to School
Creating a learning culture is something you model as a manager. Managers should learn themselves and reward those who acquire, apply and share new knowledge. I've seen numerous workshop evaluation forms that said, “Where's my management? My manager needs to hear this.”
Learning is not something you do occasionally—if you don't use the training budget, you lose it. Learning should be constant, and you can create the culture for making it happen.
Start with events you control, such as group meetings. Help people learn on their own and through others. Facilitate that learning by making your group meetings useful for learning. Add your lessons learned from previous projects, and you're well on your way.
This doesn't have to take a lot of your time. After all, you still have products to develop. Enlist the aid of your staff and spend just a little time on education over the course of each week.
When you get people thinking ahead, solving problems and challenging themselves, you get a much more productive staff.
And that's the whole point: creating an environment in which learning is an investment for the future.
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.