The Foundation of Technical Leadership

I’m a front-end architect, but I’m also known as a technical leader, subject matter expert, and a number of other things. I came into my current agency with five years of design and development management experience; yet when it came time to choose a path for my career with the company, I went the technical route.

I have to confess I had no idea what a technical leader really does. I figured it out, eventually.

Technical experts are not necessarily technical leaders. Both have outstanding technical skills; the difference is in how others relate to you. Are you a person that others want to follow? That’s the question that really matters. Here are some of the soft skills that set a technical leader apart from a technical expert.

Help like it’s your job#section2

Your authority in a technical leadership position—or any leadership position—is going to arise from what you can do for (or to) other people. Healthy authority here stems from you being known as a tried-and-true problem-solver for everyone. The goal is for other people to seek you out, not for you to be chasing down people for code reviews. For this to happen, intelligence and skill are not enough—you need to make a point of being helpful.

For the technical leader, if you’re too busy to help, you’re not doing your job—and I don’t just mean help someone when they come by and ask for help. You may have to set an expectation with your supervisor that helping others is a vital part of a technical leader’s job. But guess what? It might be billable time—check with your boss. Even if it’s not, try to estimate how much time it’s saving your coworkers. Numbers speak volumes.

The true measure of how helpful you are is the technical know-how of the entire team. If you’re awesome but your team can’t produce excellent work, you’re not a technical leader—you’re a high-level developer. There is a difference. Every bit of code you write, every bit of documentation you put together should be suitable to use as training for others on your team. When making a decision about how to solve a problem or what technologies to use, think about what will help future developers.

My job as front-end architect frequently involves not only writing clean code, but cleaning up others’ code to aid in reusability and comprehension by other developers. That large collection of functions might work better as an object, and it’ll probably be up to you to make that happen, whether through training or just doing it.

Speaking of training, it needs to be a passion. Experience with and aptitude for training were probably the biggest factors in me landing the position as front-end architect. Public speaking is a must. Writing documentation will probably fall on you. Every technical problem that comes your way should be viewed as an opportunity to train the person who brought it to you.

Helping others, whether they’re other developers, project managers, or clients, needs to become a passion for you if you’re an aspiring technical leader. This can take a lot of forms, but it should permeate into everything you do. That’s why this is rule number one.

Don’t throw a mattress into a swimming pool#section3

An infamous prank can teach us something about being a technical leader. Mattresses are easy to get into swimming pools; but once they’re in there, they become almost impossible to get out. Really, I worked the math on this: a queen-sized mattress, once waterlogged, will weigh over 2000 pounds.

A lot of things are easy to work into a codebase: frameworks, underlying code philosophies, even choices on what technology to use. But once a codebase is built on a foundation, it becomes nearly impossible to get that foundation out of there without rebuilding the entire codebase.

Shiny new framework seem like a good idea? You’d better hope everyone on your team knows how to use that framework, and that the framework’s around in six months. Don’t have time to go back and clean up that complex object you wrote to handle all the AJAX functionality? Don’t be surprised when people start writing unneeded workarounds because they don’t understand your code. Did you leave your code in a state that’s hard to read and modify? I want you to imagine a mattress being thrown into a swimming pool…

Failure to heed this command frequently results in you being the only person who can work on a particular project. That is never a good situation to be in.

Here is one of the big differences between a technical expert and a technical leader: a technical expert could easily overlook that consideration. A technical leader would take steps to ensure that it never happens.

As a technical expert, you’re an A player, and that expertise is needed everywhere; and as a technical leader, it’s your job to make sure you can supply it, whether that means training other developers, writing and documenting code to get other developers up to speed, or intentionally choosing frameworks and methodologies your team is already familiar with.

Jerry Weinberg, in The Psychology of Computer Programming, said, “If a programmer is indispensable, get rid of him as quickly as possible!” If you’re in a position where you’re indispensable to a long-term project, fixing that needs to be a top priority. You should never be tied down to one project, because your expertise is needed across the team.

Before building a codebase on anything, ask yourself what happens when you’re no longer working on the project. If the answer is they have to hire someone smarter than you or the project falls apart, don’t include it in the project.

And as a leader, you should be watching others to make sure they don’t make the same mistake. Remember, technology decisions usually fall on the technical leader, no matter who makes them.

You’re not the only expert in the room#section4

“Because the new program is written for OS 8 and can function twice as fast. Is that enough of a reason, Nancy Drew?”

That’s the opening line of Nick Burns, Your Company’s Computer Guy, from the Saturday Night Live sketch with the same name. He’s a technical expert who shows up, verbally abuses you, fixes your computer, and then insults you some more before shouting, “Uh, you’re welcome!” It’s one of those funny-because-it’s-true things.

The stereotype of the tech expert who treats everyone else as inferiors is so prevalent that it’s worked its way into comedy skits, television shows, and watercooler conversations in businesses across the nation.

I’ve dealt with the guy (or gal). We all have. You know the guy, the one who won’t admit fault, who gets extremely defensive whenever others suggest their own ideas, who views his intellect as superior to others and lets others know it. In fact, everyone who works with developers has dealt with this person at some point.

It takes a lot more courage and self-awareness to admit that I’ve been that guy on more than one occasion. As a smart guy, I’ve built my self esteem on that intellect. So when my ideas are challenged, when my intellect is called into question, it feels like a direct assault on my self esteem. And it’s even worse when it’s someone less knowledgeable than me. How dare they question my knowledge! Don’t they know that I’m the technical expert?

Instead of viewing teammates as people who know less than you, try to view them as people who know more than you in different areas. Treat others as experts in other fields that you can learn from. That project manager may not know much about your object-oriented approach to the solution, but she’s probably an expert in how the project is going and how the client is feeling about things.

Once again, in The Psychology of Computer Programming, Weinberg said, “Treat people who know less than you with respect, deference, and patience.” Take it a step further. Don’t just treat them that way—think of them that way. You’d be amazed how much easier it is to work with equals rather than intellectually inferior minions—and a change in mindset might be all that’s required to make that difference.

Intelligence requires clarity#section5

It can be tempting to protect our expertise by making things appear more complicated than they are. But in reality, it doesn’t take a lot of intelligence to make something more complicated than it needs to be. It does, however, take a great deal of intelligence to take something complicated and make it easy to understand.

If other developers, and non-technical people, can’t understand your solution when you explain it in basic terms, you’ve got a problem. Please don’t hear that as “All good solutions should be simple,” because that’s not the case at all—but your explanations should be. Learn to think like a non-technical person so you can explain things in their terms. This will make you much more valuable as a technical leader.

And don’t take for granted that you’ll be around to explain your solutions. Sometimes, you’ll never see the person implementing your solution, but that email you sent three weeks ago will be. Work on your writing skills. Pick up a copy of Steven Pinker’s The Sense of Style and read up on persuasive writing. Start a blog and write a few articles on what your coding philosophies are.

The same principle extends to your code. If code is really hard to read, it’s usually not a sign that a really smart person wrote it; in fact, it usually means the opposite. Speaker and software engineer Martin Fowler once said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Remember: clarity is key. The perception of your intelligence is going to define the reality of your work experience, whether you like it or not.

You set the tone#section6

Imagine going to the doctor to explain some weird symptoms you’re having. You sit down on the examination bed, a bit nervous and a bit confused as to what’s actually going on. As you explain your condition, the doctor listens with widening eyes and shaking hands. And the more you explain, the worse it gets. This doctor is freaking out. When you finally finish, the doctor stammers, “I don’t know how to handle that!”

How would you feel? What would you do? If it were me, I’d start saying goodbye to loved ones, because that’s a bad, bad sign. I’d be in a full-blown panic based on the doctor’s reaction.

Now imagine a project manager comes to you and starts explaining the weird functionality needed for a particularly tricky project. As you listen, it becomes clear that this is completely new territory for you, as well as for the company. You’re not even sure if what they’re asking is possible.

How do you respond? Are you going to be the crazy doctor above? If you are, I can assure you the project manager will be just as scared as you are, if not more so.

I’m not saying you should lie and make something up, because that’s even worse. But learning to say “I don’t know” without a hint of panic in your voice is an art that will calm down project teams, clients, supervisors, and anyone else involved in a project. (Hint: it usually involves immediately following up with, “but I’ll check it out.”)

As a technical leader, people will follow your emotional lead as well as your technical lead. They’ll look to you not only for the answers, but for the appropriate level of concern. If people leave meetings with you more worried than they were before, it’s probably time to take a look at how your reactions are influencing them.

Real technical leadership#section7

Technical leadership is just as people-centric as other types of leadership, and knowing how your actions impact others can make all the difference in the world in moving from technical expert to technical leader. Remember: getting people to follow your lead can be even more important than knowing how to solve technical problems. Ignoring people can be career suicide for a technical leader—influencing them is where magic really happens.