©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.
Buddies arent just for the pool
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 skillsthat’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.
Requirements for a buddy system
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.
Evolution of the buddy from guide into mentor
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.”
Pitfalls or common traps
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 doesnt 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.
Use a buddy system for cross training
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.
Summary
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.
