Skip to main content

Senior Software Developers as Mentors

Dave Nicolette
Reading: 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.

Next When Functional Programming Isn't

Dave Nicolette has been an IT professional since 1977. He has served in a variety of technical and managerial roles. He has worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Congruence Between Agile Process and Ecosystem

In a recent SoundNotes Q&A with Mike Cottmeyer, our Fearless Leader fielded questions on a range of topics related to organizational Transformation and Agility. One key point he made was that any process or method, such as Scrum, LeSS, SAFe, etc., is designed to operate under certain conditions. Each process or method assumes it will […]

Letting Go of the Waterfall, Embracing Agile,
and Mixed Martial Arts
w/ Brandon Dudley

In this episode of SoundNotes, LeadingAgile’s own Brandon Dudley—Senior Consultant—shares his experience making the shift from a Waterfall mindset to a more Agile way of thinking and working. Brandon got his start in traditional, PMI-centric, project management working in the auto industry in Detroit. His introduction to Agile didn’t involve the hard break that many […]

Completeness & Correctness = Predictability

Completeness & Correctness = Predictability Video Transcript: When we think about organizations, one of the challenges for us as a consulting organization is when we engage with any particular company, we have to identify what that company values and what they’re trying to be, as well as what environment they’re in, because that’s going to […]

Questioning Agile Dogma

When I first learned about Agile methods in 2002, the principles seemed to offer an ideal solution to many organizational issues common at the time. When I applied those principles in real-world situations, they worked remarkably well. Today, some of the same principles seem to present impediments or unnecessary challenges for many teams and organizations. […]