Heard a great podcast the other day from the team at Manager Tools, entitled “THE Development Question”. I’m sorry to say that I can’t find it on their website, but it did show up in Podcast Addict for me, so hopefully you can pick it up and give it a listen. I’ll sum up the gist here, but it’s really intended to be a starting point for this blog post. In essence, Manager Tools says that when a direct approaches you (the manager) with a question, one of the best responses you can offer is another question:
“What do you think we should do?”
Their point is not that management is a game of Questions Only, but that leaders want to develop others and development comes through actions; employees have lots of reasons for asking questions, but a good manager should realize that employees need to be empowered and able to take action for most situations. If an employee is constantly waiting on approval from the manager, then the manager becomes the bottleneck.
Mulling on this a couple days made me realize that there’s a potential hazard for most new technical managers related to the issue of employee development; are we doing enough to make our employees better engineers than we were? Let me walk you through my thinking:
- Most new technical managers were promoted to their position from within their company, and it was usually because they were the best operator (i.e, someone who was skilled at their job as an engineer).
- Most new technical managers have a tough time separating themselves from their prior responsibilities, particularly if those prior responsibilities were very hands-on with a product\service\effort that’s still in use today (e.g., as a developer, John wrote most of the code for the current application; as a manager, John still finds himself supporting that code).
- If you were the best at what you did, that means that the people you now manage weren’t. Actual skill level is debatable, but most of us take a lot of pride in what we do. Pride can overemphasize our own accomplishments, while downplaying the accomplishments of others.
This is a problem for technical management, because the goal of a good manager is NOT to solve problems, but rather to increase efficiency. Efficiency is best achieved by distribution; in other words, you as a technical manager could learn how to improve your own technical skills by 10%, but if your employees don’t grow, your team’s not really making progress. On the other hand, if you invest in your directs’ growth and each f them improves their technical skills by 10%, it’s a bigger bang for your buck (unless you only have one employee; if that’s the case, polish your resume).
Here’s the kicker: Sacrificing your technical skills while building the skills of your employees will pay off more in the long run than continuing to build your own technical knowledge alone. You WANT your employees to be better engineers than you were because you gain the advantage of the increased skills that brings to the table distributed and magnified by the number of employees you have. I’m not saying that you should completely give up your passion for technology; it’s helpful for managers to understand the challenges their employee’s face without necessarily being an expert (that’s a fundamental principle of Lean Thinking; “go see” management). However, you should strive to be the least technical person on your team by encouraging the growth of the rest of your team.
So let me ask you: “What are you doing to develop your employees today?”