"The last senior dev who got internally promoted currently has an allowance of 50% of his time for helping more junior devs understand things. Fifty percent! The intention is to get his senior dev knowledge and experience out of his head and into the heads of five other people; growing ourselves five more senior devs."

I am pretty senior and I like mentoring people. But the incentives are generally the other way: If as an IC I transfer my experience to new people I almost get no credit. The manager of the group gets credit for building a good team but I have to justify my salary compared to the people I mentored. So sometimes I wonder if it would be smarter to keep knowledge to myself so I can look better.

I certainly sympathise. In a strong culture, when you mentored someone, their achievements and success would reflect on you. The boss would see your cohort doing well, and give you a pay rise for your fantastically valuable contribution to the company. "Thank you, maxxxxx, for making these junior software engineers 50% more effective," the boss would say. "Why, you've had the same effect as hiring two or three more people!"

But if your culture involves ranking and paying people only relative to each other, I can understand the need to protect yourself. And everybody loses :( The company loses, you lose, the potential mentees lose :(

Another factor is that by mentoring my own output goes down a lot. If I get interrupted several times a day to help then I get nothing done on my own stuff. I think on overall it's still a big gain for the team but I look worse.

That calls for setting clear boundaries, and proactively checking in/interrupting your mentee when it's a good time for you to take a break.

I like metrics based on how much time the other person has and expects to waste not being able to do anything productive, which strongly suggests you should give him at least two things he can be doing, an obvious second one being reading documentation or otherwise researching necessary stuff he doesn't yet know. After a certain number of hours it's worth an interruption.

And there's the reverse effect that teaching someone else forces you to better learn the subject, so you should gain some extra productivity from this.

If the saying "A rising tide lifts all boats" doesn't hold in your company, I'd say that's definitely a dysfunction.

Isn't that pretty common? "A rising tide lifts only the boats of a privileged few"?

> almost get no credit

Delivered four senior developers in order to accelerate our team's velocity...

that's what my resume says.

I never even considered that. Thank you. I'm going to have to remember to add more "soft skills" and accomplishments to my resume.

Anything you do at work that is not a regular part of your job is on your resume. If you get called out on it being bullshit, then you remove it.

> that's what my resume says.

Which implies it was only valuable to future companies you worked for. Those that actually believe in mentoring, which seems to be rare based on what others are saying and my own experiences.

Um, no, it doesn't imply that at all. The current company values it; he also figured out how to explain it to a future company.

This is great, but only when you've already got enough knowledge and experience within the organisation to enable it. That's where you really need to hire senior developers. Trying to grow a team of juniors into a team of seniors without enough guidance, grows teams of expert beginners, which is way worse for both the team and the organisation in the long run. You won't be able to hire or retain seniors in that sort of environment as they'll see it for what it is and leave.

However, that's not to say training people up shouldn't be done! I've seen some wonderful developers grow from junior to senior and it's always great to see it happen. Just make sure the organisation is in a position to do it well, otherwise you're doing both them and the juniors a disservice.

That's a good point. One of the places I worked hired a ton of juniors and placed them under "senior" team leads, but the leads were too few, not exactly all-stars, and code quality was all over the place. I tried to have a positive influence on some of the eager new hires, with varying success (mostly because I wasn't very senior either, just a little further along than they were).

Eventually the environment became frustrating enough that I had to move on. Great people, really friendly environment, and even a product I believed in, but it felt so bad to keep having to read through awful, giant, bug-ridden code reviews with the same old rookie mistakes. I only had enough influence within my own team to slow the rate of bad code entering master, but it still came alarmingly fast. I think nobody from my team is still at that company. I really hope management has turned it around since.

Maybe I'm just a grump, but: 5% is pretty low number for training people up. Perhaps that's just the "hit the books on your own, but during work time" portion? If it includes other things (talking people though a project that's on the edge of their capabilities, discussing the architecture of important project from an educational perspective, ...) then it seems pretty low.

EDIT: non-phone spelling

It is, I believe from talking to others and my own experience, significantly higher than the average (outside the mystical FAANG etc).

The average is basically zero.

Talking people through things at the edge of their capabilities and discussing the architecture etc that they need to know; that's just doing the actual job, surely.

5% = 2 hours out of the entire week

It's basically 4 conversations and that's it.

5% is pretty low to basically nothing. I agree.

It's very low and, from my own experience, significantly higher than average.

My experiences are almost entirely UK based, outside big name or hip companies.

True. Usually training is 0%.

We are trying to build our own internal training program. Beyond the language-specific training, what books/courses have you found that are super useful. For example, would you ask someone to learn design patterns or something like that ?