Most software developers start their careers writing code.
They have a boss who assigns them tasks. They complete those tasks. The more tasks they complete, the better they get at completing tasks. So their boss gives them harder tasks. Eventually, they get so good at completing tasks their boss decides they should be in charge of other software developers who aren't as good at completing tasks. This is usually done with the hope that their task-completing prowess will rub off on their new subordinates.
This is the point at which a programmer becomes a manager.
All too often, it is also the point at which the Peter Principle kicks in:
"Every employee tends to rise to his level of incompetence."
Different Skill Sets
The problem is that writing code and leading people require vastly different skill sets:
- Writing code is "me"-centered.
- Leading people is "other"-centered.
With this short series of articles on leadership, I hope to fill in the gaps so that you can successfully make the transition from writing code to leading people.
After four years at West Point and two yearlong combat deployments–one leading 20 soldiers as a platoon leader and the other as second in command of a 175-soldier company–I learned a few things about leadership.
I've distilled that experience and knowledge into six leadership principles:
- You can delegate authority, but not responsibility.
- Give credit. Take blame.
- Leaders serve their subordinates (not the other way around).
- When in charge, be in charge.
- Knowing what you don't know is more important than knowing what you do.
- Be yourself.
Be sure to check back as I expand on each of these principles in future articles.