Mixing
How to balance guiding someone vs micromanaging someone?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
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?
communication leadership micro-management
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
suggest improvements |Â
up vote
3
down vote
favorite
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?
communication leadership micro-management
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
2
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22
suggest improvements |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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?
communication leadership micro-management
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
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?
communication leadership micro-management
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
asked Feb 10 '16 at 22:23
Kevin Xu
2,02531124
2,02531124
2
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22
suggest improvements |Â
2
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22
2
2
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
suggest improvements |Â
up vote
2
down vote
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.
answered Feb 5 '17 at 3:59
Ootagu
37017
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
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.
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
suggest improvements |Â
up vote
11
down vote
accepted
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.
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
suggest improvements |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
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.
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
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.
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
answered Feb 10 '16 at 22:30
gbjbaanb
2,2261019
2,2261019
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
suggest improvements |Â
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
Code reviews are definitely a better approach than spoon feeding them the answer.
– AndreiROM
Feb 10 '16 at 23:14
2
2
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
This is good advice, and I would add one thing. Don't provide a lot of information up front when you are assigning the task. Give enough to understand what needs to be done, and save the rest for when they come and ask. It saves you time, and some folks might get the impression you don't trust them to figure it out if you give too much help right away.
– ColleenV
Feb 11 '16 at 16:00
1
1
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
+1 - In general, good teachers are willing to let students make mistakes.
– user8365
Feb 11 '16 at 16:46
suggest improvements |Â
up vote
2
down vote
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.
answered Feb 5 '17 at 3:59
Ootagu
37017
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
suggest improvements |Â
up vote
2
down vote
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.
answered Feb 5 '17 at 3:59
Ootagu
37017
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Feb 5 '17 at 3:59
Ootagu
37017
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.
answered Feb 5 '17 at 3:59
Ootagu
37017
answered Feb 5 '17 at 3:59
Ootagu
37017
answered Feb 5 '17 at 3:59
Ootagu
37017
answered Feb 5 '17 at 3:59
Ootagu
37017
37017
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
suggest improvements |Â
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
I love that final point (more because I totally listen in on what other engineers are saying and I have learned a lot from that)
– Kevin Xu
Mar 4 '17 at 9:40
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f61854%2fhow-to-balance-guiding-someone-vs-micromanaging-someone%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
"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?" "What have you tried so far?" That should really be a separate question though.
– Lilienthal♦
Feb 10 '16 at 23:51
Did the extra babysitting duties come with a pay rise?
– Kilisi
Feb 11 '16 at 7:38
@Kilisi I did get a raise but I do not think it's because of the babysitting -- it was because of a reorganization but that's a separate thing. I have talked about becoming more of a lead role because, well, I do the baby sitting already so they are testing the waters with this.
– Kevin Xu
Feb 11 '16 at 22:22