One of the hardest lessons I had to learn when I became a manager was where to put my ego.
As an individual contributor, success had been visible and personal. I could point to the code I wrote, the system I designed, or the problem I solved. The deliverable carried my fingerprints.
Management changed the scoreboard.
My output was no longer the most important output. The team wrote the code, solved the problems, and shipped the product. If I continued measuring myself by what I personally delivered, management would always feel like a lesser version of the work I used to do.
I had to learn that a manager contributes differently.
The coach who wins a championship feels just as good as the players. If the coach selected the system, prepared the team, developed the players, made adjustments, and created the conditions for the win, then the championship is also the coach’s achievement.
The players own their execution. The coach owns the environment that helped make the execution possible.
Software management works the same way.
The Old Scoreboard Stops Working
High-performing developers receive constant evidence that they are valuable. They solve the difficult issue. They know the part of the codebase nobody else understands. They finish work quickly. Their pull requests are clean. Other developers ask for their help.
Promotion removes much of that immediate proof.
The new manager spends time in planning, one-on-ones, stakeholder discussions, hiring, conflict resolution, and work allocation. At the end of the week, there may be no class, service, or feature with the manager’s name on it.
That can feel like failure to someone whose professional identity was built on personal delivery.
Organizations often make the problem worse by promoting the strongest contributor without teaching them that management is a different profession. The person receives a new title, more meetings, and responsibility for other people. Nobody explains that the skills producing success have changed.
The result is predictable. The new manager keeps using the old scoreboard.
They take over difficult work because completing it feels productive. They make technical decisions for the team because being correct feels useful. They judge developers by whether those developers work the way they did. They become frustrated that management does not provide the same satisfaction as building.
The promotion changed the role. It did not change the person’s definition of success.
Two Developers Who Stepped Back
I have had two developers join my teams after leaving management roles. Both had concluded that management was not for them.
Their paths were similar. They had been successful individual contributors, moved into management, and discovered that the job did not feel like success. They returned to development because it gave them familiar work and a familiar measure of competence.
The first developer believed he simply was not cut out to manage.
After about a year working under me, he saw the problem differently. He had not failed because he lacked leadership potential. He had been applying individual-contributor skills to a management job.
He knew how to solve technical problems. He had not learned how to orchestrate people and work toward a shared outcome. He knew how to improve his own performance. He had not learned personnel development: understanding what another developer needed, giving useful feedback, creating growth opportunities, and helping someone become more capable over time.
Management had asked him for skills nobody had taught him.
Once he understood the difference, he could see that he did possess the raw ability. He needed a different operating model and time to practice it.
The second developer disliked management because he did not feel as successful as he had as an individual contributor. His problem was the scoreboard.
We talked about relocating his ego from his own deliverables to the performance of the team. If a developer learned a new skill, that counted. If a specialist helped someone else become effective, that counted. If the team shipped reliably or solved problems without needing him to take over, that counted too.
This mindset was new to him.
He had not realized that a manager could take legitimate pride in team output without stealing credit from the people who produced it. The coach and the players contribute to the same victory in different ways.
Both developers eventually moved back into management roles. Both have been successful.
Stepping back was not proof they had failed. It gave them space to learn the profession before trying it again.
Great Players Are Not Automatically Great Coaches
Michael Jordan remains a useful extreme for understanding the difference between contribution and management.
Jordan was one of the greatest individual performers in sports. He scored, defended, prepared obsessively, demanded excellence, and changed the standard for everyone around him. His teammates knew he would deliver and felt pressure to match him.
Those qualities helped make him extraordinary on the court. They do not automatically describe a good coach. The behaviors tolerated from an elite peer can become destructive when backed by organizational authority. A teammate can challenge another teammate in a way that lands differently from a manager controlling compensation, promotion, and continued employment.
Phil Jackson and Steve Kerr show the other side of the lesson. Their greatest professional impact came through systems, roles, communication, and the development of other people. Jackson won 11 championships as a head coach. Kerr built championship teams around movement, spacing, and the strengths of players such as Stephen Curry.
The coach has a different unit of work. The coach studies the players, chooses the system, creates roles, develops capability, and adjusts when the current arrangement stops working. The coach remains accountable for the performance without personally producing every point.
A development manager does the same. The manager needs to understand the product, the business goals, the strengths of the developers, and the constraints around the work. The manager creates the conditions in which individual ability becomes coordinated delivery.
This is why promoting the top contributor is not a development plan. Technical excellence provides credibility and domain judgment, but it does not teach orchestration, coaching, patience, feedback, or the ability to measure success through someone else’s growth.
What Managerial Success Looks Like
The managerial scoreboard is less immediate than the individual-contributor scoreboard, but it is not vague.
You can see it in the people and systems around you. A junior developer can handle work that required senior help six months ago. A specialist learns to teach instead of becoming a permanent bottleneck. The team shares ownership rather than dividing the codebase into personal territories. Work is right-sized, priorities remain stable long enough to finish, and releases become predictable. Developers raise risks early because feedback is useful instead of punitive.
The strongest signal is what happens when the manager is not present. A manager who must personally intervene in every difficult situation has created dependency, not leadership.
The job is to make the team more capable, not to remain the most capable person in every conversation.
This requires an emotional adjustment. You have to let someone else write the elegant solution. You have to guide without taking over. You have to celebrate a result that carries none of your fingerprints while recognizing the work you did to make it possible.
That lesson was difficult for me. It was difficult for the two developers I mentored. It is difficult for many high performers because it asks them to release the proof of competence that built their careers.
Choose Managers for the Next Job
The best candidate for management may be a strong individual contributor. Domain knowledge, credibility, discipline, and sound judgment all matter.
They are not enough.
Choose managers for their ability to learn the next profession, not merely for excellence in the current one. Look for curiosity about people, patience with development, comfort sharing credit, willingness to give direct feedback, and the ability to arrange work around the strengths of others.
Then teach them.
Do not hand a top developer a team and assume technical talent will turn into leadership through proximity. Explain the new scoreboard. Give them models for orchestration and personnel development. Let them practice before the stakes become unforgiving.
A championship team needs great players. It also needs someone who understands that the victory is produced differently from the sideline.
Receipts
- Two management returns: Two developers joined my teams after leaving management roles and returning to individual-contributor work. Both later re-entered management after mentorship and have been successful.
- First lesson: One developer realized after roughly a year that he had not lacked management potential. He had been applying individual-contributor skills to a role requiring orchestration and personnel development.
- Second lesson: Another developer learned to measure managerial success through team performance and employee growth rather than personal deliverables.
- Basketball record: The NBA’s list of coaches with the most championships documents Phil Jackson’s 11 titles and Steve Kerr’s four.