How should I balance providing mentorship/learning for other devs with speed of development?
Whether it's mentoring a junior or writing documentation, I'm not sure how to best balance the level of information sharing with the speed of development - especially regarding new features or projects. At the moment, I share information as it's required or wanted, but I feel like it's easy for people to dismiss learning anything new, which leaves me uncertain as to whether or not I should push for others to learn about work or handle it on an as-needed basis. If this is related to a team's culture, then what kind of practices should I be advocating for?
Discussion
(1 comment)- 0a year agoMeta, Pinterest, Kosei
My answer depends a lot on your level of trust + tenure in the company. As a mid-level engineer, I've seen examples in both buckets:
- Have you been there a long time, everyone knows who you are, and organically comes to you asking for help?
- Or are you relatively new and still building up relationships with the team?
If you are more in bucket #2, my advice is to focus more on development. When you identify obvious knowledge gaps, you should answer people's questions, write a wiki/more permanent solution, and then share that with the team. This will be viewed as an extension of the solid eng work you've been doing anyway, and over time you'll move into bucket #1.
Now that you're in bucket #1, you have way more ability to influence the culture + direction of the team. Use your social capital to solicit feedback on what information people need to succeed in their job. At this point, you should be a partner to your manager to propose 2-3 action items that you can execute as a team. Your manager will certainly have opinions here, so you can work with them on prioritized action items. This playbook will almost certainly lead to promotion.
