Most experienced professionals value the opportunity to mentor others; not so for some elite technologists
To enable more people in a technical team to do work, more people have to know how to do it. But for many engineers, training doesn't come natural.
This is Part 1 in my Series on Managing Engineers
Is one-on-one training a rational activity, or just a feel-good strategy from the HR department? Many engineers don't believe in the value of training and mentoring junior people because they perceive no personal benefit in training junior people. But there are benefits for everyone involved.
The reasons high-tech engineers have for not mentoring others are distinctive to the field.
- Time Calculus: The time and effort to do a task they've done is less than the time and effort to explain it to somebody else then to ask them to do it. For example: suppose a 2-hour routine-cognitive task requires three hours of training. It's easier just to do it than to train someone else in how to do it.
- Mathematical, Non-Verbal People: For some people, it's much easier to control a computer and get the problem done than clearly express ideas verbally.
- Hero Syndrome: The senior person likes to be the one to solve problems because they get their self-worth. And the Customers (those who need the help) would rather just get the problem solved the fastest way possible.
- Too Much Variety in tasks. Some organizations rarely solve the same problem twice. In these cases, the trainable skills are relatively few.
- Weak Junior Staff. Sometimes the people available to train aren't trainable (brains) or coachable (pride). This is the responsibility of organization to find appropriate staff.
- Job Protection. There's a myth that some people won't train others because the would-be trainer would thus be subject to losing their job. I'm not sure I've seen real evidence of this.
- Technology changes too fast. Technical skills have a very short lifetime: what you learn today may be good for about two years, according to IT World.
- My other trainee is a compiler. Many senior technicians argue that automating the task is a better than training someone else to do it; often that is true. But our desire to write code must be tempered by reality: code doesn't last very long, and will need humans to maintain it. As Alan Perlis famously said, "It is easier to write an incorrect program than understand a correct one." Without another human's review of the problem, you may be solving the wrong problem.
Good Reasons to Train and Mentor Junior Engineers
“In learning you will teach, and in teaching you will learn.”
― Phil Collins
Despite the objections listed above, there are ample good reasons to train and mentor junior engineers.
- Explaining a practical art to another human is good for humanity, by enabling more people to do more useful work.
- The Teacher Learns. Explaining and answering questions increases the capabilities of the trainer substantially. The effort to verbally explain a system or technology forces the explainer to crystalize a model of the system they may have not had earlier. (My knowledge of SIP, VoIP Call Control, and RTP grew vastly as I was forced by teaching to verbalize my knowledge, and confront areas I didn't understand.)
- Senior Staff should focus on the Hardest Problems. After the training is done, the time/effort for the senior staff is substantially reduced. Suppose that two hour task required three hours of training; now when the task needs to be repeated, the junior staff can complete it. This makes the senior staff more available for the challenging problems for which they are distinctively qualified. When senior staff are doing the easy stuff, they're usually leaving the harder problems unconsidered.
- Technology is fundamentally about improving efficiency through use of effective tools, and having more processors capable of completing a task makes the clients more efficient than having to wait on a single-threaded processor. By having only one person capable of providing the work, you're creating a bottleneck and failure mode for the rest of the world.
- Redundant Array of Imperfect Humans (RAIH): Everybody gets sick or needs a holiday. By mentoring someone else, you're making it easier for yourself to get a break. You may not want to take a break, but eventually you're going to get sick, die, take vacation, or get a better job.
- Pair Programming Benefits. Even when automating a task, you can get benefit by bringing in somebody else. There are many documented benefits of pair programming; the Mentoring benefit is key. (Yes, pair programming takes more person-hours -- but only about 15%. And for that 15% you get better results.)
- Fundamental principles change little. While technology moves fast, key fundamentals that don't: the Buffer (1950s); Interrupt (1950s); Relational Database (1960s); Packet-Switched Networking (1960s); Structured Programming (1960s); multi-user Operating Systems and Security (1970s); Digital Audio and Video (1960s - 1980s).
How to Accomplish Mentoring & Training
“You cannot help people permanently by doing for them, what they could and should do for themselves.”
― Abraham Lincoln
When you decide to start training another technician, start with the right assumptions.
- I cannot learn for you.
- I cannot replace your own curiosity.
- If you won't ask questions, you're probably not teachable.
- You can't learn by watching or listening: you have to learn by doing.
More on this in a future post.
