How to balance guiding someone vs micromanaging someone?

Question

Recently my manager has made me more of a lead role in helping shape some of the new devs on the team. I have a lot of experience with the codebase they are dealing with and so he sometimes simply lets me assign issues out.

Most of the time there are some issues of various complexity. I have no problem giving out ones that are extremely simple, but for ones that require understanding more parts of the codebase I will generally add some thoughts onto the ticket to give them a better understanding of what might be going on.

Recently for some issues, some of the new devs will naturally ask a lot of questions. I have a really bad habit of inevitably telling them what the fix should be.

What is a good balance for this? While I do want them to figure the issue out on their own, I also feel weird withholding information from them. At the same time, I think there is value to letting them figure it out on their own even if it means they might take a while to understand what's going on. Also what is the right way to respond to someone who asks a very basic question that I feel they should be able to figure out on their own?

Answer 1

Do you have documentation, or are you the docs? If the latter - too bad, they're going to refer to the docs as much as they can and you're going to have to answer. Of course, you could start writing down all you know and then referring them to that so in time you'll be less necessary.

In the other case, refer them to the docs, and refer them to the areas of code they need to look in. If you add in some architectural knowledge that will help but then, once you've shown them where to look, leave them to it.

Another thing that helps is code reviews. Tell them to come up with whatever solution they think is best but to bring it to you for checking before any coding starts. That helps them gain confidence in that they've worked it out correctly before making a mess. When they get better at knowing the system, move your code review focus to actual code after they solution is coded, and use the opportunity to explain any areas they got wrong or (more likely) could be done better or more in keeping with the codebase.

In time they'll get more confident and autonomous.

Answer 2

It sounds like you have natural educator tendencies. But it also sounds like you are either a little new to applying them, or lack encouragement to stick to your principles. Being an educator (or team leader--which has many similarities) requires persistence on your part to not give answers. There are several positive educative approaches you can use:

-Act as a sounding board to those who are expressing problems. In this case you may not even need to actively react but simply passively receive.

-Discuss the problem presented to you by your colleagues. Either pretending to seek clarification on it, or genuinely confirming what the problem is. Through this indirectly the answer may arise.

-When posed with a question, mention that you are "not sure" and they might want to try or check such and such a location, then excuse yourself from the situation and tell them you will return shortly; when you return ask them if they got anywhere with their seeking.

-Final point--and this one is gold. I almost feel like not revealing it here. Vocalize your own internal thinking processes when you are at work. Your colleagues will overhear what you say and learn to be more independent.