It’s OK If You Aren’t The Smartest

Many people who end up working as Software Development Managers, Tech Leads, Chief Architects and other high-ranking software positions, have ended up there through time, hard work, and expert knowledge. They have demonstrated their skills, talents and knowledge on hundreds of occasions to many dozens of people throughout their careers. Eventually their extensive knowledge and superb skill have allowed them to take a leadership position in their organization.

Now we all know that some people end up in these positions almost by accident. It is clear to anyone who has worked with a person like this that they have the wrong job. People like this are an anomaly and I don’t want to discuss them. I’m sure there’s a fascinating, if somewhat twisted, set of instructions you could follow to get a promotion you don’t deserve, but for the purposes of this book I’m going to pretend that never happens.

Somewhere along their career path the skills of technical management have become more important to every software manager than their skills at writing code. You have probably seen this same thing happen in your career.

While each new opportunity moves you further and further from the direct act of writing code, your technical knowledge and skills never stop being important. It is impossible to manage or lead a group of technical contributors, be they engineers or software developers, without maintaining knowledge of the work your team is doing.

However, the day will come when you finally accept that you cannot keep up with the pace of technical growth maintained by the people you manage.

Sure you can keep up to date on all the technology being used by your team, and you can certainly keep a working knowledge of how everything fits together. You may even continue as the most appropriate person for large-scale system-architecture decisions. However, the facts are that everyone has the same 24-hours in a day, and that you need to spend much of yours doing non-coding tasks. This will eventually guarantee that someone on your team becomes more technically proficient than you.

The first time you recognize this is very scary.

Here you are, a successful software manager. You know that you’ve arrived at this position because you were consistently one of the top performers on your team. You wrote beautiful code, and you had superb technical insights. This is why you ended up where you are. And now your technical superiority is regularly challenged by one of the people on your own team. Should you feel threatened?

In a word: no. But accepting this involves a distinct shift in attitude.

Whether we admit it or not, technical people are very competitive with one another. We are always arguing and debating because we know this leads to the best solutions. It also leads to an unconscious competition that causes everyone on a team to rank their team members from “most gifted” to “simply adequate”. As a software manager, and one-time daily coder, you may still feel a part of this hidden ranking system. However, as the team manager, you need to recognize that you are no longer part of this contest. At least, not in the normal sense.

The developers on your team will still look at you for guidance and experience, but they probably aren’t looking for you to name the best design-pattern for a particular problem. Instead, they are looking for help in balancing priorities between tasks, in understanding the relative business merits of alternative product solutions, and in helping them understand the best processes to make the business successful. They may have a good idea about each of these things, but they will be looking to you for the last word. That is your job after all.

The real break-through moment for a new software manager comes when you realize that your value has changed. You are no longer the MVP (most-valuable-programmer). Instead, you have become the MVD (most-valuable-director). People are now looking to you for a different kind of expertise.

This “ah-ha” moment is a remarkable time for a new manager. Suddenly you are free to run your team in a completely different way. Instead of feeling threatened by that hyper-smart coder who can run rings around you with the latest dependancy-injection framework, you can encourage him to become even smarter. Instead of worrying that your coding skills aren’t as deep as they once were, you can work to make them as broad as possible. Instead of struggling to find time to attend every design meeting and code-review, you can step back and trust the brilliant people on your team to do their job.

This is a profound moment of personal self-discovery for many people. This is the time when you learn it’s OK to not be the smartest person on the team, in fact it’s probably best of you aren’t. This is the time when you can truly become a superb software manager.


4 thoughts on “It’s OK If You Aren’t The Smartest

  1. Nice post. I totally agree with the notion. I always felt that as a development team or project manager your job to a wide extent is to allow your “race horses to run as fast as they can by clearing the race track for them and remove any obstacles on the track”… in open source circles this also often is a bit linked to the herding of cats.. 😉

  2. Pingback: Hire the Smartest Person « Leading Software

  3. Yes, we likely don’t need or want the smartest coder to be assuming the leadership role. We want that person to arguably be the smartest in an entirely different skills-set. Those skills being in creating, managing, and developing the strength of the team through an ongoing team-building exercise. We likely also want our leaders to have skills in the areas of project management, and skills in being able to see the big-picture – to be able to balance the business side with the nurturing of the techincal outcomes.

    So I think we’re on the same page….nice post…


  4. I always struggled with the notion of smart being the measure of great programmers.

    Realizing you aren’t the smartest on the team, and don’t need to be, is liberating for the leader. But if the whole team is still lining up single file from “smartest” to whatever the opposite is. Then there are still a bunch more team members who need liberating.

    In one of your other posts you mention specialization. This comes into play here. On a small team with no specialization, “smart” is the only yard stick. As the team grows you can create opportunities for specialization so that different types of team members can find their niche, where they are the best. Smart is but one metric, and not a terribly interesting one.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s