If your organization is starting or revamping a mentorship program, the following tips can help. But it's important to note that not every senior developer makes a good mentor, and there's no shame in knowing your limitations. If you don't think you can fully commit to being a good mentor, or you don't think you have the necessary skills or traits to be one, say something. It's better to admit that you aren't cut out for the task than to force yourself to do it and waste time and probably alienate a promising new employee.
1: Make mentoring a priority
I think the key ingredient in a successful mentoring relationship is giving the relationship priority above anything other than an emergency. The inability to give the relationship priority is what makes true mentoring scenarios so rare. If you don't make the mentorship a priority, new hires quickly sense they're not important. They also quickly figure out that when they go to you for help, they're slowing you down from attending to your "real" priorities. The result? They don't come to you for help, and they try to do things on their own. Basically, you're no longer their mentor.
2: Have a road map
I've seen a number of mentoring programs sink because there is no plan. Someone is hired, and a more experienced developer is assigned to show that person the ropes. The experienced developer wasn't told about this new mentoring role until 9:05 AM on the new hire's first day. The would-be mentor takes the new hire on a tour of the building and introduces him or her to a few other teams — and that's the extent of "the ropes." The only thing the new employee usually learns is where to find the kitchen. You need to have a game plan with set goals (for the new hire and for the mentor) and a list of topics to cover; otherwise, you'll both feel lost and give up before you even start.
3: Be tolerant of mistakes
Working with entry-level developers can be frustrating. They are not familiar with writing code in a real-world environment with version control, unit tests, and automated build tools. Also, they may have been taught outdated habits by a professor who last worked on actual code in 1987. Often, entry-level developers don't realize that the way they were taught to approach a problem may not be the only choice. But if your reaction to mistakes is to treat the new developers like they're stupid or to blame (even if they are being stupid or are truly at fault), they probably won't respond well and won't be working with you much longer.
4: Assign appropriate projects
One of the worst things you can do is throw entry-level programmers at an extremely complex project, forcing them to sink or swim. Chances are, they'll sink. Even worse, they'll add this project to their resume and run out of there as fast as they can just to get away from you. On the other hand, don't create busywork for them. Let them work on nagging issues in current products or internal projects you never seem to have time to address. Once you gain confidence about what they can accomplish, you can assign a more difficult project.
5. Give and accept feedback
You can't successfully navigate a ship in the middle of an ocean without a compass. Likewise, new employees will not achieve the goal of becoming a productive member of the team without knowing where they've been and where they're going. This means you need to give feedback on a regular basis, and the feedback needs to be appropriate. For instance, being sarcastic to someone who made an honest mistake is not helpful. Feedback has to be a two-way street as well. You need to listen to find out what their concerns and questions are, and address them.
Rewarding experiences
If you're considering being a mentor, these relationships can be very rewarding. I hope these tips will help you the next time an entry-level developer is assigned to your department.
No comments:
Post a Comment