Most developers who don’t want to go into management think that their career path must lead them to become an “architect”. When pressed on what it means to be an architect, they usually describe the role of a technical leader: someone who sets the technical agenda, mentors others, tackles the most challenging issues, etc.
While that may very well be a worthwhile goal to shoot for, not everyone is destined to get there. The fact of the matter is, no one becomes a leader by edict. You’re only a leader if there are people willing to follow you. This is especially true in a meritocracy of software development teams. So if you really want to be a lead, understand what that entails.
To be a technical leader you need to be insightful, persuasive, and persistent. You need insight to find a Better Way to do something. You need persuasion to convince your peers and your managers to go along with your idea. And you need persistence to see your idea through.
Find a Better Way
A Better Way to do something is a way that leads to a cleaner code base, higher quality, shorter timelines, or a combination thereof. A Better Way is not necessarily about technical purity or elegance. As difficult as it may be difficult for geeks to acknowledge, a Better Way should be about impacting the bottom line. Lower costs, higher productivity, and even increased revenues are all measurable outcomes of doing something better.
I would guess that most environments are target rich. That is to say, it probably isn’t that difficult to find something that can be done better, more cheaply, more efficiently. Legacy code bases can be refactored to speed up implementation, caching systems can be designed to optimize performance, Continuous Integration processes can be implemented to increase quality.
Know Your Limits
Probably the toughest part of being a technical leader is keeping up. It’s a lot like oil extraction. A hundred years ago, extracting oil was almost literally a matter of punching a whole in the right place in the ground and putting a rudimentary pump in. These days, you’re either drilling in the open ocean or applying sophisticated processes to shale.
When your team is bad, it’s easy to find ways to lead. A simple presentation on unit testing can have a major impact on a team that’s never done that before. However, as your team gets better and low hanging fruit disapears, game changing ideas are harder to come by. Once everyone is TDDing, doing proper OO, and running CI all the time, finding a Better Way becomes more difficult.
So you need to step up your game and go after harder things. This can be a major challenge because things like implementing a new ORM, creating a proper domain model, or designing an advanced caching system require significant aptitude and experience. The truth is, not everyone can do it. Even if you are a good dev. And there is no shame in that.
After all, if writing software gives you a sense of great accomplishment and satisfaction, there is nothing wrong with “just” being a good developer. A Swiss watch maker probably doesn’t see himself as “just a watch maker” who secretly hopes to one day become a watch architect. He sees himself as a master of his craft who enjoys the process of creation and is validated by accomplishment, not title.
If you’re a dev who dreams of being a technical leader, my advice is to find a place that will give you the opportunity to earn it. If you think you can, embrace that opportunity. But please, be honest with yourself about your abilities and limitations.
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!