Here's a question for you. How do you develop someone who is technically brilliant but a little weak at managing people? Being brilliant at doing the work does not automatically make somebody brilliant at leading other people to do the work, and yet businesses make this mistake all the time.
You have your best salesperson, your best estimator, your best engineer, your best operator. They solve problems quickly, so you promote them, and suddenly they're a manager, and then we're surprised when they struggle. But why would they automatically know how to manage? You've changed their job.
Your best technical person is not automatically your best manager. It's a bit like taking the best violinist out of the orchestra, handing them the conductor's baton, and wondering why the orchestra doesn't play that well. Playing the violin and conducting an orchestra are completely different jobs. One is about your own performance, the other is about getting good performance from everybody around you.
Businesses regularly promote someone because they were excellent at the first job without properly teaching them the second. Before deciding somebody is not management material, ask a different question. Did we ever actually teach them how to conduct? And there's another difficulty. Very often, the qualities that make somebody technically outstanding are precisely the qualities that will get them into trouble as a manager.
They're fast, they know the answer, they spot mistakes immediately. They can usually do the job better than the people underneath them. So somebody brings them a problem, and they solve it. Something goes wrong, they take over. Someone is too slow, and they do it themselves.
In the short term, that feels extremely efficient, but gradually they become the answer to everything, and eventually they become an enormous bottleneck. The fastest way to solve today's problem can create tomorrow's dependency. Your employee brings you something that they are struggling with.
You can solve it in 10 minutes. They might take an hour. So naturally, you take it back, but you now have solved two things very differently. You've solved the immediate problem, and you've taught the employee that difficult problems belong with you. Do that repeatedly, and you create a team that becomes very good at escalating.
Before you take the problem back, ask, "Am I supporting this person or rescuing them?" This is one of the first things I would teach a technically brilliant new manager, and that's to stop answering quite so quickly. Someone asks, "What should I do?" Their instinct is to tell them.
Instead, they should try, "Well, what do you think? What have you tried? What options can you see? What do you recommend?" That can feel painfully slow to someone who already knows the answer, but something important is happening in the painful slowness. The manager is no longer simply solving the problem, they're developing the person, and that is the shift at the heart of management.
Before promotion, success may have meant personally produce excellent work. After promotion, success becomes something closer to build a team capable of consistently producing excellent work, and that is a completely different scorecard. Here's a sentence I hear from managers: "I haven't got anything done today.
I spent the whole day dealing with people." If you manage people, dealing with people may have been exactly what you were supposed to get done. Developing somebody, clarifying priorities, removing a blockage, having a difficult conversation, helping somebody make a better decision. Those things are not interruptions from management, they are management.
the problem is that many people are still measuring themselves against the measures of their old job. There is also a structural problem that businesses often overlook. Before the promotion, the person had a full-time technical job. After the promotion, they often still have most of the technical job.
But now we add on one-on-one meetings, recruitment, delegation, performance management, planning, conflict, and decision-making. So management gets squeezed around what everybody still privately regards as their real work. The person works longer, they become frustrated, and everybody wonders why that promotion didn't work.
But perhaps the business never really redesigned the role, it simply added management on top So if you want this person to become a manager, you have to make room for management. What should they stop doing? What can somebody else learn? What genuinely still requires their technical expertise?
And what are they still doing simply because they've always done it? Another major transition is learning the difference between a standard and a preference. A technically strong person often watches someone else perform a task and thinks, "That's not how I would do it." Fine, but is that wrong? Does it breach a safety requirement, a quality standard, a customer requirement, a deadline, an agreed process?
If not, it might simply be different. Managers who turn every personal preference into a compulsory standard create micromanagement very quickly. One question can eliminate an extraordinary amount of micromanagement: "Is this a standard or is it just my preference?" A technically brilliant manager watches somebody work and thinks, "This isn't how I would do it," but that doesn't necessarily mean it's wrong.
A standard, on the other hand, matters. Safety, quality, customer requirements, deadlines. A preference may simply mean, "I like doing it this way." If the result, however, meets the standard, the manager may need to let the other person do it differently. Delegation becomes much easier once you stop trying to create miniature versions of yourself And then we come to one of the hardest behaviors for a technical expert to learn: letting somebody else become capable.
Delegation is rarely efficient at the beginning. The manager says, "It would take me ten minutes to do this myself. It'll take me an hour to explain it, probably, today." But if they explain it, coach it, let the other person practice, that work may no longer require the manager in the future. If they keep choosing a ten-minute personal efficiency, they can remain the bottleneck forever.
And that is why I often talk about building shoulders. Who is learning decisions that currently come only to you? Who could take responsibility for something that you currently own? Who are you deliberately developing? Strong shoulders underneath a manager create room for that manager to grow. If you want to move up in a business, stop proving how indispensable you are.
A lot of capable managers accidentally build the opposite of what they need. Every difficult problem comes to them. Every important decision needs them. Every crisis proves how valuable they are. But if you want to grow, you need capable shoulders underneath you, people who can carry decisions, people who can solve problems, people who can take responsibility for work that once depended entirely on you.
Your next level does not depend on you becoming a bigger hero. It depends on you building shoulders. Because management is not just delegation. Technical people can also find difficult conversations surprisingly uncomfortable. They may handle a complex operational crisis without even blinking, but saying to someone, "You're not meeting the standard," can feel much harder.
So they wait. They compensate. They do the missing work themselves, and resentment grows. The better discipline is to manage evidence rather than irritation. What was expected? What's my evidence of what actually happened? How often? What is the pattern? What does the gap that I can see tell me? Why does that matter?
That evidence gives you the ability to have a management conversation Without evidence, you have frustration, and frustration just gives you frustration And the same applies to one-on-ones. A technically oriented manager can easily turn a one-on-one into, "Where's job A at? What happened with customer B? Have you finished C?"
But that isn't development. It's not a great one-on-one. A better one-on-one will really be asking, "What are you finding difficult? What are you learning? What do you want help thinking through? What are you trying to become better at?" A good one-on-one should leave your employee feeling more capable, not merely being supervised.
And perhaps one of the simplest management skills of all is silence. Ask a question and then stop talking. Don't answer it yourself three seconds later Technical experts are so used to speed. They're the knowledge workers. Development, on the other hand, sometimes requires allowing somebody else enough time to think. And if they say, "I don't know," and a lot of them will, don't immediately rescue them.
Instead, try, "Well, I can understand you might not know, but what's your best guess? What options can you see? If you did know, what might you say?" In this way, you're exercising somebody else's thinking muscle.
You're wanting to move them from - give it to me to talk me through how you're thinking about this. You want to move them from I'll fix it to what system stops this happening again? That's the transition from technical hero to manager, from best player to conductor. And they may become an excellent manager.
Their technical expertise gives them credibility, their judgment, their understanding of the standards, and enormous coaching potential. But only if that expertise becomes something that they use to make the people around them stronger, rather than something that keeps everybody dependent on them. So if you have somebody who is technically brilliant, who is struggling with management, don't start by asking whether you promoted the wrong person.
Start by asking, "Have we actually taught them the new job?"
You have your best salesperson, your best estimator, your best engineer, your best operator. They solve problems quickly, so you promote them, and suddenly they're a manager, and then we're surprised when they struggle. But why would they automatically know how to manage? You've changed their job.
Your best technical person is not automatically your best manager. It's a bit like taking the best violinist out of the orchestra, handing them the conductor's baton, and wondering why the orchestra doesn't play that well. Playing the violin and conducting an orchestra are completely different jobs. One is about your own performance, the other is about getting good performance from everybody around you.
Businesses regularly promote someone because they were excellent at the first job without properly teaching them the second. Before deciding somebody is not management material, ask a different question. Did we ever actually teach them how to conduct? And there's another difficulty. Very often, the qualities that make somebody technically outstanding are precisely the qualities that will get them into trouble as a manager.
They're fast, they know the answer, they spot mistakes immediately. They can usually do the job better than the people underneath them. So somebody brings them a problem, and they solve it. Something goes wrong, they take over. Someone is too slow, and they do it themselves.
In the short term, that feels extremely efficient, but gradually they become the answer to everything, and eventually they become an enormous bottleneck. The fastest way to solve today's problem can create tomorrow's dependency. Your employee brings you something that they are struggling with.
You can solve it in 10 minutes. They might take an hour. So naturally, you take it back, but you now have solved two things very differently. You've solved the immediate problem, and you've taught the employee that difficult problems belong with you. Do that repeatedly, and you create a team that becomes very good at escalating.
Before you take the problem back, ask, "Am I supporting this person or rescuing them?" This is one of the first things I would teach a technically brilliant new manager, and that's to stop answering quite so quickly. Someone asks, "What should I do?" Their instinct is to tell them.
Instead, they should try, "Well, what do you think? What have you tried? What options can you see? What do you recommend?" That can feel painfully slow to someone who already knows the answer, but something important is happening in the painful slowness. The manager is no longer simply solving the problem, they're developing the person, and that is the shift at the heart of management.
Before promotion, success may have meant personally produce excellent work. After promotion, success becomes something closer to build a team capable of consistently producing excellent work, and that is a completely different scorecard. Here's a sentence I hear from managers: "I haven't got anything done today.
I spent the whole day dealing with people." If you manage people, dealing with people may have been exactly what you were supposed to get done. Developing somebody, clarifying priorities, removing a blockage, having a difficult conversation, helping somebody make a better decision. Those things are not interruptions from management, they are management.
the problem is that many people are still measuring themselves against the measures of their old job. There is also a structural problem that businesses often overlook. Before the promotion, the person had a full-time technical job. After the promotion, they often still have most of the technical job.
But now we add on one-on-one meetings, recruitment, delegation, performance management, planning, conflict, and decision-making. So management gets squeezed around what everybody still privately regards as their real work. The person works longer, they become frustrated, and everybody wonders why that promotion didn't work.
But perhaps the business never really redesigned the role, it simply added management on top So if you want this person to become a manager, you have to make room for management. What should they stop doing? What can somebody else learn? What genuinely still requires their technical expertise?
And what are they still doing simply because they've always done it? Another major transition is learning the difference between a standard and a preference. A technically strong person often watches someone else perform a task and thinks, "That's not how I would do it." Fine, but is that wrong? Does it breach a safety requirement, a quality standard, a customer requirement, a deadline, an agreed process?
If not, it might simply be different. Managers who turn every personal preference into a compulsory standard create micromanagement very quickly. One question can eliminate an extraordinary amount of micromanagement: "Is this a standard or is it just my preference?" A technically brilliant manager watches somebody work and thinks, "This isn't how I would do it," but that doesn't necessarily mean it's wrong.
A standard, on the other hand, matters. Safety, quality, customer requirements, deadlines. A preference may simply mean, "I like doing it this way." If the result, however, meets the standard, the manager may need to let the other person do it differently. Delegation becomes much easier once you stop trying to create miniature versions of yourself And then we come to one of the hardest behaviors for a technical expert to learn: letting somebody else become capable.
Delegation is rarely efficient at the beginning. The manager says, "It would take me ten minutes to do this myself. It'll take me an hour to explain it, probably, today." But if they explain it, coach it, let the other person practice, that work may no longer require the manager in the future. If they keep choosing a ten-minute personal efficiency, they can remain the bottleneck forever.
And that is why I often talk about building shoulders. Who is learning decisions that currently come only to you? Who could take responsibility for something that you currently own? Who are you deliberately developing? Strong shoulders underneath a manager create room for that manager to grow. If you want to move up in a business, stop proving how indispensable you are.
A lot of capable managers accidentally build the opposite of what they need. Every difficult problem comes to them. Every important decision needs them. Every crisis proves how valuable they are. But if you want to grow, you need capable shoulders underneath you, people who can carry decisions, people who can solve problems, people who can take responsibility for work that once depended entirely on you.
Your next level does not depend on you becoming a bigger hero. It depends on you building shoulders. Because management is not just delegation. Technical people can also find difficult conversations surprisingly uncomfortable. They may handle a complex operational crisis without even blinking, but saying to someone, "You're not meeting the standard," can feel much harder.
So they wait. They compensate. They do the missing work themselves, and resentment grows. The better discipline is to manage evidence rather than irritation. What was expected? What's my evidence of what actually happened? How often? What is the pattern? What does the gap that I can see tell me? Why does that matter?
That evidence gives you the ability to have a management conversation Without evidence, you have frustration, and frustration just gives you frustration And the same applies to one-on-ones. A technically oriented manager can easily turn a one-on-one into, "Where's job A at? What happened with customer B? Have you finished C?"
But that isn't development. It's not a great one-on-one. A better one-on-one will really be asking, "What are you finding difficult? What are you learning? What do you want help thinking through? What are you trying to become better at?" A good one-on-one should leave your employee feeling more capable, not merely being supervised.
And perhaps one of the simplest management skills of all is silence. Ask a question and then stop talking. Don't answer it yourself three seconds later Technical experts are so used to speed. They're the knowledge workers. Development, on the other hand, sometimes requires allowing somebody else enough time to think. And if they say, "I don't know," and a lot of them will, don't immediately rescue them.
Instead, try, "Well, I can understand you might not know, but what's your best guess? What options can you see? If you did know, what might you say?" In this way, you're exercising somebody else's thinking muscle.
You're wanting to move them from - give it to me to talk me through how you're thinking about this. You want to move them from I'll fix it to what system stops this happening again? That's the transition from technical hero to manager, from best player to conductor. And they may become an excellent manager.
Their technical expertise gives them credibility, their judgment, their understanding of the standards, and enormous coaching potential. But only if that expertise becomes something that they use to make the people around them stronger, rather than something that keeps everybody dependent on them. So if you have somebody who is technically brilliant, who is struggling with management, don't start by asking whether you promoted the wrong person.
Start by asking, "Have we actually taught them the new job?"
