In a shop that is intended to be tight-knit and supportive, should it be part of the culture that senior developers are paired with junior developers as mentors? Or should this mentoring be something that is more organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement?
I think it should be encouraged but not required; seniors shouldn't be assigned to juniors or anything like that, or else you'll end up in Dilbert-land. The "mentor-mentee" relationship requires some level of friendship at its core, as well as a healthy dose of MUTUAL respect. You don't get that by just telling to people to go off and "ment".
should it be part of the culture that senior developers are paired with junior developers as mentors?
organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement
It won't happen often enough to actually help anyone.
Folks with existing relationships in the organizations will be perceived as cliques or elitists by new people. The cliques will not normally break down. We stick with people we know -- it's an essential element of human nature.
As a consultant for over 30 years (100's of client engagements) I can assert that new people are always outsiders. It isn't a feature of "culture" or "atmospherics". It's an essential feature of how people work. The consultants form their own clique because the established staff don't tend to include them in anything.
The only way to establish mentoring is to insert new people into the cliques.
Should senior developers be required to mentor junior developers?
Absolutely not. Some good senior developers are going to be horrible mentors and the matchup of personalities is a must have for successful mentor ship. I think, however, that senior developers should be required to make something about the development team better. That could be prototyping something on the side, improving a process or practice, pioneering new tools, presenting technical material to the group, leading a team or something else. In other words, they should have a responsibility for something that is bigger than the individual workshare.
Or should this mentoring be something that is more organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement?
Nope, don't agree with that take, either. I've seen too many situations where mentoring is expected to be "organic and spontaneous" and it happens all too rarely. I think organizations do need to take on the onus of giving mentorships a chance to get infectious - but it can't be forced. That's hard, but worthwhile. I think the organization could do things like:
- Informal meet-ups between potential mentors and potential proteges
- Suggested ways and opportunities for mentorship to be formally recognized by the organization (for example, if you are a place that has a charge number for virtually everything, create a charge number for mentor ship meetings - clarifying that this IS a viable part of the work)
- Training and support for mentors
- guidance to proteges for how to select a mentor and what to expect
- guidance to mentors on what to expect and what to offer
- Suggested (or enforced) patterns for mentorships with templates for participation - for example, it's much easier to give it a shot if you know in advance that your goal is a 3 month experience with weekly meetups and a goal of helping a new developer get up and going in the company. Not to say it won't develop into more... but it gives a place for folks to start.
I think that making it a requirement could potentially backfire, as some people just aren't wired that way, and would be very turned off by the idea. That being said, you should identify the people that you think are suited to be mentors, and approach them about taking a more active role in mentoring (if they aren't already). This lead-by-example approach could catch on and inspire more spontaneous mentoring.
You might also schedule regularly occurring group activities, which will help the team to jell. These could be completely social activities, like a team lunch, or activities that incorporate learning about programming, like a weekly programming book club.
You could also have regular "mini postmortems" on systems, which would function like a group code review. One benefit of doing the review in a group setting is that everyone can benefit from the feedback, rather than just the person who wrote the original code. You might need to get some volunteers who are comfortable having their code judged to get things started, and be sure to maintain civility.
I have been in environments that do things both ways.
The first job I had out of school, I was assigned a mentor. I didn't like the guy, and I certainly didn't agree with him on everything. I resented being forced to work with him, and I was pretty sure my employer had made a mistake, but in retrospect I learned a lot.
Fast forward a few years, and now I'm with a company that treats developers with an every-man-for-himself attitude. Developers are under tight deadlines, and few if any allowances are made for developers who spend time taking others under their wings to show them the ropes. I think it's a shame. I see how junior developers struggle with the same things I did, but without a mentor to help them out it takes them a lot longer.
I have developed a reputation as "the mentor" because new hires "seem to appreciate the help I'm able to provide them". As far as I can tell, this is a fancy HR way of saying that I am willing to tolerate mediocre productivity reviews so I can do the right thing, which is to enable junior developers to do their jobs effectively and to improve rapidly.
I think that's what our junior employees deserve, and with the benefit of hindsight and experience, I think that first company I worked for, and that guy that mentored me, had a lot more figured out than I thought at the time.
All of this is the long way of saying that while I wish you didn't have to assign mentors, it is probably the only fair way of spreading around the work. If you don't, you should give the people that do it their due. It is not easy work; it requires both interpersonal skills and engineering skill; and it is time-consuming.
I never liked the terms Junior and Senior programmers. For example, I've been programming for a while and although I have experience in some areas, I am very green in others. For example, we are moving to WPF and although I have tons of windows forms application experience, WPF is still new and foriegn to me. So although I am a "senior" programmer, you could hire someone off the street with way less 'total' experience and they could probably program a WPF application better and faster than me at this point.
Not to say I don't lots of good application design and architecture experience that could be applied to the WPF application, but I know my limits.
I guess you have to be willing to be the mentor at some times and the mentee at others.
If you have team members that are not afraid to be the mentor when they have the knowledge and a mentee at others when they need the knowledge, you will have a fruitful experience.
If you can foster that kind of development environment where developers are humble and are open to new ideas and help others along when needed, the sempai-kohai relationships will come out naturally.
Forcing mentoring will probably create a caste system which developers may resent each other. Its better to treat every developer equally on the same level.
This industry is very different. Senority is not always better.
Sometimes the seniors need to mentored by the juniors.
Senior developers should be expected to go beyond the churning out of code. However, the direction they go should not be the same for every senior developer.
Some are well-suited towards mentoring. Others aren't, and should be pursuing some other senior-level goal, whether it be planning and implementing architectural improvements, or evaluating new technology, or planning and leading process improvements (e.g. continuous integration, TDD, etc.)
Basically, a senior shouldn't just be someone who has been cutting code for a few years more than the juniors. It should be someone who is willing and able to take on additional responsibilities that will contribute to the success of the team. Mentoring juniors is important, but it's not the only important thing, and it's not something that everyone is well suited to.
Mandating such mentoring is counter-productive because human beings quite naturally strive against forced activities, actions and relationships. A better approach is to reward the people who do good mentoring, thus getting people to want to mentor.
Of course this brings up the problem of measuring "good" in this context. An imperfect, but easily-implemented solution might be to have the newcomers after a year (possibly anonymously) write the names of, say, the top three people who helped them integrate into the company and/or the code base. After that you can reward the people whose names get mentioned most. Monetary rewards won't work here, however. It's better to find some kind of social reward.
team leads structure, leading to code reviews should do the trick...
You'd have a senior member of your staff responsible for one or more juniors. I don't believe it should be spontaneous help, but rather a formal process; in the sense, that the senior member will be responsible for the quality of work produced by the new comers. This approach has 2 benefits (at least): instruct the seniors in management styles, and make sure the juniors produce quality code.
No, because that would imply the number of senior and junior developers be the same all the time. I could see encouraging those senior developers that want to be mentors but enforcing a pairing could be a really bad idea. The idea of supporting mentoring relationships is good and shouldn't be thrown out here.
Artificial encouragement isn't a bad idea here though. Telling all junior and senior developers that they are going to be mentees and mentors no matter what could be a bit religious and backfire quite quickly.
If there is a framework known within the company of how to handle mentoring that would be great. However, if that doesn't exist then the key becomes having a few different kinds of moments between the mentor and mentee:
- Current status - Where are things now? What is the current challenge that the mentor may provide assistance in resolving?
- Future state - What is wanted: A hint, a solution, questions to ask, who to ask?
- Retrospective - What worked and didn't work in making changes?
- Future changes - What will be tried in the future that may work better than what was done previously?
At least those are states that I can see and make sense from my view to take a logical top-down approach. Others may want something much more organic and free-form which can work as well. The key is to get an idea of how to get each side to have some skills that should be honed through the practice of communicating in this relationship. Each side should be gaining something from the relationship and there should be some common ground rules in having this kind of relationship as feedback is a big deal here.
How much time one spends in this is a fair question that realistically one has to look at what is being done and to what extent it is acceptable to spend time developing skills and building relationships. I could see some pairs wanting an hour a week to go through this while others may want a couple hours a day to cover this. Don't forget that there can be other interactions where a senior and junior may work together though not within a formal mentoring relationship.
I've seen a couple of different attempts at mentorship systems. The ones I liked best were ones where the senior dev had a specific set of tasks that they performed to help the junior dev, which paved the way for mentoring without requiring it. For example, an assigned senior dev one-on-one code-reviewer for the first six months could be very useful and would be likely to lead to mentorship. The ones that I disliked were the ones that felt like extra busywork and which didn't seem to be directly related to the work being done - e.g., meet with your assigned mentor for half an hour every week. This was especially annoying when the two members of the mentorship relationship generally didn't interact with each other during the week and didn't have anything to do with each other's projects. It felt very forced and touchy-feely rather than focused on growing professionally. The last thing you want is for a mentorship relationship to feel like a counseling session.
IME, you can't count on mentorship relationships developing, so providing a potential mentor by pairing a senior dev and a junior dev for a set of normal paired business activities (code reviews, debugging, pair programming, etc.), at least at first, is a great idea. Ideally, the senior member should be volunteering for the role and should be able to perceive some personal benefit. At my current company, senior devs are almost leads for their projects, and the benefit is that they are building up their own project's team. At the other company, mentors were often investigating the management track.
I think every company that hires young developers should have some sort of a reasonably effective mentoring program. But I'm not sure the default position should be every senior developer should do it for the simple reason that lots of developers, regardless of how good they are at developing, are lousy at mentoring. It goes with the territory unfortunately. Some of us just aren't great people people if you like.
On the other hand, where there are people who are good at it, they should get recognition for it, and not blackmarks because their actual development output falls while they are explaining some simple localised issue regarding, oh IDE implementation to some newbie who has always used NotePad and Javac, for example.
This requires some balanced management. I'm not certain it's common.
Generally mentor ships are good stepping ground for transition from senior to team lead or manager. It is more effective to link the mentorship to advancement in a PDP(Personal Development Plan) or what ever merit plan your company uses. Tying their pay increase and career development at least in part to their ability to pass on knowledge and groom new developers is key to building a strong IT Staff that can weather changes in management and staff turnover. Providing key goals and working with staff to help them improve is part of that growth into leadership. For those who think it is not fair to tie a seniors evaluation to a juniors performance that is part of the growth. In most cases you are not talking about a pay cut but rather reduced increase or slowed advancement. Seeing as part of that advancement is the ability to lead and teach those under your leadership this seems quite natural to me.
When I first came to the team I had the owner and a lead developer giving me instruction. I could ask either of them anything and they both would reply. Though, I was respectful enough to not keep bothering them unless I just couldn't figure it out in a timely manner.
It worked great but then again, you probably need nice people with a sense of humor to get this to work.