Teach, don't solve

New or inexperienced managers tend to fall into the trap of solving problems for their team.  This frequently occurs when an engineer asks for validation of a technical solution. Given normal delivery pressure, you want to quickly get the problem corrected or solution implemented.  The perceived easy path typically goes something like one of the following two ways:

1. It's good.  Make this tweak and go for it.  Let me know when you are done.
2. You really missed it.  Here is how you need to do this. (You then return to your office where you solve the problem and the engineer watches you)

Either may be efficient in the short term, but neither is a teaching moment. Watching someone else do something is a poor substitute for engaging the person in the learning experience. To increase learning, engage your engineer in the solution process. 

Regardless of whether the solution is right or wrong (as if it is ever that black and white), ask the following questions:

• What are the aspects of the problem that lead you to this solution?  What are the downsides to this solution?
• What alternatives did you consider?  What is your rationale for rejecting those?
• How will this solution impact…? Insert what is appropriate, such as implementation, maintenance, upgrading to a future version, workflow.
• Now that we've discussed this a bit, what parts of the solution will you change? Why?

Your goal as a manager is to promote independence and critical thinking skills. Solving the problem on behalf of the engineer builds neither.