Senior Software Developers as Mentors

Senior Developers as Mentors

In most organizations, nearly all the challenging technical tasks are assigned to the senior-most team membrers. Tasks that pertain to a particular area of the code base usually fall to the team members most familiar with that area.

That approach ensures teams will never be able to perform more effectively than the senior technical team member can perform alone. It creates “islands of knowledge” and prevents junior staff members from learning.

It’s noteworthy that leaders who claim to be interested in organizational improvement also tend to assign just about all the work to a handful of senior technical staff. Why?

Most IT organizations have more work to do than they have capacity. They are always scrambling to get things done. People worry that there’s “no time” for improvement. There’s just barely enough time to rush through tasks, and the senior-most team members are the ones who can rush the fastest.

A Better Way?

LeadingAgile generally recommends that senior technical team members take responsibility for mentoring and guiding junior colleagues, rather than taking on the more challenging tasks themselves. That approach ensures teams will improve their delivery effectiveness over time, as knowledge spreads across all team members.

This approach has proven to be effective in multiple situations. But, like any good idea, it can be taken beyond the point of diminishing returns.

Going Too Far

A client of mine several years ago had an unusual situation. It’s the only time I’ve seen this situation.

One team supported a call center solution. The solution comprised several components, including COTS products like Avaya, Siebel, a workflow automation package, and various add-ons, as well as custom components, including a large suite of Windows batch files and a Windows thick client application that presented a consolidated view of data from the other products in the solution. It was a complicated solution that called for specialized skills in particular areas, not least the Avaya and Siebel platforms in addition to two different database management systems.

The solution was supported by a single team of 20 people. Of course, we expect to find a range of technical skills and levels of proficiency on any team. But this team was exceptional in that regard. There were four “senior” team members and sixteen “junior” members. The four senior members were all contractors. The sixteen junior members were all employees.

I can almost hear you saying, “But that’s not a unique situation!”

You’re right. Here’s the unique part: None of the sixteen junior team members had any previous experience in software work. None had a university degree or a certificate from a technical school. None were self-taught computer hobbyists. They were not just “junior,” they had absolutely no background working with computer systems.

Why Hire People with No Background?

They were military veterans. Management’s view was that military veterans were likely to have high ethical standards and a strong work ethic. They were likely to be reliable and trustworthy. They were likely to be willing and eager to learn. The four contractors could mentor the veterans and help them learn on the job.

All those assumptions were true, except the last. The four contractors were the only people on the team who had any ability to do any of the work. They assigned the simplest tasks to the junior team members, and spent their time doing literally all the “real” work. However simple the tasks may have been, the junior team members had no idea how to approach them. All they could do was to wait for one of the four contractors to find a free moment to help them.

When a contractor found a free moment, he didn’t “help” the junior team member. He simply completed the task himself. It was much faster than mentoring, and the team had far too much work to do. There was no time for teaching.

The idea of learning on the job is great, but in the software field a person needs at least a basic foundation on which to build. Entry-level programmers have been exposed to a lot of things in school and/or on their own, even if not in depth. They know what a compiler is, what a database is, what a network is. They will have done some programming to complete class assignments.

They won’t have experience with large code bases, with complicated solutions involving multiple COTS products, or with making changes to code while others are making changes to the same code. But they will have something to stand on.

A person with no background at all really has no chance of getting anywhere in a learn-on-the-job situation. They don’t know enough to guess what to try. They don’t know enough to know what questions to ask. The knowledge gap is simply too large to fill in with on-the-job mentoring.

Climbing a Tree

Imagine a tall tree. The tree has many limbs, but the lowest limb is high off the ground.

Now imagine a person who is asked to climb the tree. She is already standing on the lowest limb. From that position, she can reach two or three other limbs, and begin pulling herself up. When she needs help, others in the tree are able to reach her easily, and won’t have to climb down in order to help her up.

Imagine a second person who is asked to climb the same tree. He is standing on the ground. The lowest limb is higher than he can reach. Others who are in the tree are too high and too busy to climb down and help him up.

If only he had attended a coding bootcamp or a technical school, he would at least be on that lowest limb to start with.

Advice?

So, how did I advise the manager of that team? I suggested that the four contractors be given no work assignments at all. I observed that the only times they added value were the times when they were helping the junior team members. Therefore, it made sense to make helping the junior team members their full-time job.

It made a difference. A couple of the veterans had taken the initiative to do tutorials, read books, and try things to see what would happen. They had aptitude and they were learning. Once the senior team members were explicitly assigned to do nothing but guide them, they progressed quickly.

But the other fourteen didn’t get anywhere. The problem was that they had an insufficient foundation to begin with.

Conclusion

That single case doesn’t invalidate the idea of hiring junior people and using senior people to mentor them on the job.

We still believe it’s valuable to have senior technical staff spend a good deal of their time mentoring junior colleagues. The value outweighs the cost.

The take-away from the anecdote is that there’s junior and there’s junior. There has to be a foundation, at least. It could be a university degree or it could be years of self-learning by a person who took an interest in programming as a child. But it has to be something rather than nothing.