I spend a lot of time thinking about how people lead. And when I say that, I don’t mean how people manage. I want to know how effective people make things happen. Sometimes they are also managers. Sometimes they are not.
Of course, I’m not the only one, there has been an ocean of ink spilled on the topic. There is less, though, specifically about ways that coders can lead.
Every job and every career has its own unique challenges, but I’ve rarely seen a field where there is such a breadth of leadership options as there is in coding.
As I thought about some of the people I’ve worked with in the past, I realized that there are lots of different ways to be effective. And, perhaps more interesting still, it is nearly impossible to find someone that is effective in all ways even as it is certainly the case that some individuals can lead in more than one way.
The crucial point is that there can be many leaders. And not all of them will receive an official job title that designates them as such. That’s a good thing. It’s important nonetheless to recognize the value of each type.
Here, then, is a brief sketch of different type of ways leadership can manifest itself in coders.
This is an easy example. A technical leader is often the smartest person in the room (code-wise). They know a thousand different patterns and paradigms. It seems as if they’ve memorized all the man pages, seeming to pull out flags and options that no one knew existed.
The trick with technical leaders, is that they should be spending time with technical decisions. A common mistake is to move them into human leadership roles because they are good at technical things.
This makes no sense.
Now there are technical leaders that are also good in other realms and if they want to manage humans and interactions, awesome. For many, perhaps most, technical leaders, they should spend time making technical decisions.
In coding, at least, we have ways to recognize these individuals. There are programmers and senior programmers and architects and, why not, senior architects. This is great. Let them build amazing things. Let someone else send emails.
The diplomat is a coder that can communicate. Not only do they work well with other departments (sales, design, management, etc.), people in those departments like talking to the coder.
Diplomats represent a unique subset of the coder world were everyone is assumed to be pale introverts. Without them, an engineering team would have a hard time functioning. This doesn’t mean that coders shouldn’t interact with groups outside their tribe if they aren’t diplomats; everyone should be able to communicate. This just means that diplomats do it very well.
Diplomats are great people to send to meetings because not only are they good at representing their teammates, they actively enjoy learning about other groups and how they are contributing to the project. In other words, don’t make the mistake of sending only technical leaders to meetings. Diplomats, even if they are relatively inexperienced, are made for this environment.
Another unfortunate and persistent stereotype is that of the coder as sarcastic misanthrope. Hell, it’s even an snl sketch.
But of course, not all developers are like that. Some lift people up, make them excited about whatever is being worked on. They are the energizers.
Energizers make stand ups fun. They get animated when talking about their project and get excited to hear about everyone else’s project. Most coders start out as energizers and then after implementing the same functionality over and over slowly lose some of their passion.
Energizers don’t. Energizers still find joy in whatever they do. As a result, they are great people to have as mentors for new developers because they never lost that new developer feeling. They are also great individuals to give talks or lead training because their enthusiasm is infectious so every new concept or technique will be presented with excitement.
They are close to diplomats, but not quite the same. Sometimes their passions are focused just on the technical and so they may not fit well with other departments. They won’t be bad, they just won’t be quite the same.
Put them in a position where they can make people excited. They will lift everyone’s spirit.
This is pretty obvious. Some people are good in a pinch. Not only do they stay calm under pressure, they actually get excited by it. They usually have two abilities:
1) They can quickly diagnose and solve the problem.
2) They keep everyone else calm while they do.
They way they lead is obvious; they are people to go to in times of crisis. Yet, they shouldn’t be limited to the on-call phone. They are also good people to put in charge of sensitive projects or tight deadlines because they can move quickly and efficiently and they don’t get burnt out afterward.
The unexpected realm of leadership is for sensitive projects, think PCI Compliance. They can be better with these projects because they’ve seen a lot of the scenarios before. They can handle the pressure that comes with high profile projects. And they spend time thinking about all the individual pieces and how they can go wrong.
It’s hard to incorporate coders that are good at crisis management into a workflow. Crises by definition are unexpected and unplanned. Still, knowing who can handle it when it comes up is helpful.
Processor’s are good at strategy. They are curious not just about how the code gets written, but also about the project flow. This doesn’t necessarily mean they only care about applying agile principles or anything like that. Coders that are good at process may also be good at organizing their own projects so that they consistently hit deadlines. They may also be better at looking at the overall program flow. In short, they like looking at the big picture.
Most are immediately recognizable because of their ridiculously complicated dev set up. They have hundreds of tools with hundreds of customizations and yet they somehow have everything memorized and move with exceptional speed. They are not just interested in how parts work, but how systems interact.
Since they are so interested in flow and interactions, they usually need some time to, well, process. They are good people to talk to when something that already exists needs to be analyzed and updated. They take in the information, synthesize it and can come up with good suggestions.
They can be good at organizing workflow and can see which parts of the system don’t return value and where bottlenecks currently exist. Why are there so many bugs in a certain component? How come there is always a lag after a big project before the next one is underway? Why do deployments take so long?
The processor may have ideas.
Everyone’s a mix
These are, I’m sure, gross simplifications. And nearly every developer is a mix of at least two or more of these styles.
The important thing to note is that they are all important to an organization. So when looking for leadership on coding projects. Remember, don’t always pick the most knowledgeable coder. Don’t pick the one that is most chatty with other departments. Pick the individual that will have the greatest impact. Give them a chance to use their best abilities. Everyone will benefit.