How to Be an Insanely Effective Tech Lead
The first responsibility of a tech lead is to define reality. The last is to say thank you
I’m sure every developer worth their salt would like to be a tech lead at some point in time. After all, it’s one of the most coveted and influential positions in software development. That said, being a good tech lead is not something everyone is capable of.
Understanding and leading a team of talented developers, from the greenest to the most experienced, is much more than handing out free soda and beer on Friday. In fact, being a tech lead is like being in the dead center of a triangular battlefield in which bullets are being fired at you from all three directions. Your job is not only to dodge the bullets but also to make sure the three sides don’t kill each other (and the project)! You are the only common thread responsible for:
- Managing the band of developers working with you.
- Managing the leadership above you: Project managers, senior project managers, architects, etc.
- Managing the customer by making the right technical decisions at the right time.
That’s why not all software developers can be good tech leads. Imposing a tech lead position on a senior developer just based on experience can be one of the worst decisions management can make.
First and foremost it’s important to be honest with yourself and understand what drives you. Is it writing code? Is it designing software? Or, is it helping others to get better results, negotiating deadlines with stakeholders, and convincing your business team that code refactoring is not a waste of time?
Your answers will decide whether you would be a good tech lead or a bad one. In the end, it all boils down to leadership. As management guru and author Peter Drucker says:
“Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership.”
Here are some great habits of insanely effective tech leads.
“If you have knowledge, let others light their candles in it.”
— Margaret Fuller
From my experience, being good at technology is the most sustainable way to gain respect among your team members. That being said, being good at technology and not sharing your knowledge is a surefire recipe for disaster.
Bad leads refuse to share their knowledge for multiple reasons:
“What if my teammate gets ahead of me?”
“What if they ridicule my knowledge?”
“Why should I share my knowledge? Let them learn the hard way.”
Whatever the reason, the final impact is on the project and team morale, both of which are affected negatively by the lead’s stubborn attitude. Knowledge is half the battle and sharing it is the other half. Your team will have no use for you if you opt to be selfish. Good leads talk to their developers and show them how to solve problems. They not only tell them how to fix the problem but also explain why they fixed it that way.
Don’t get into a situation where the team stops asking you questions. Communication is the lifeline of a successful project.
Know Your Team
“Ingredients to success: know what you do well, know what to do well, and know someone who’s swell.”
— Criss Jami
Have you ever been to a supermarket and noticed the difference in service when you call the attendant by name, rather than barking “hey you?” In most cases, the service not only improves but you get a genuine smile to boot.
While there are no set rules or project requirements to call people by their first names (in fact, in software-project limbo, people are referred to as resources), getting a bit personal at work is required as part of our journey as Homo sapiens. We‘re humans, we have names, and we’re unique.
Good tech leads establish an informal mode of communication, along with formal rules, so that people can talk about their problems. Then, the tech lead gets to hear about them before they get worse. For example, knowing a person is about to quit two days before, as opposed to two months, makes a big difference.
You don’t have to like your co-workers, but you at least need to know them. Knowing developers’ abilities and limitations, combined with knowing what they are interested in, will make you plan your development in a better way.
Admit You Don’t Know Everything
“People who think they know everything are a great annoyance to those of us who do.”
— Isaac Asimov
We all know that “with great power comes great responsibility.” But the flip side of power is corruption. If you want to know the real nature of a person, give them a little power and see if they misuse it. Bad team leads misuse the power they have over their teams.
You’re probably a technical whiz kid, but even you will not know everything about your technology. It’s practically impossible. On the other hand, the greenest kid in the room might come up with a sustainable, performance-effective solution to the problem at hand. Good tech leads don’t impose their solutions on the team. Rather they cultivate a sort of democracy in which the best solution wins.
Bad leads, on the other hand, assume they always know more than their developers. They come across as overconfident, domineering types who want it done their way, even if their way is wrong. They don’t like reasoning, because most of the time they are unreasonable.
Remember, as a tech lead, your job is to make sure everyone contributes their best to the project, not simply obeys their boss.
Don’t Be a Pushover
In contrast to the “I-know-everything” type, the pushover can’t make up their mind. No new feature is too insignificant for consensus and debate. And no project kicks off without a painful, exhaustive discussion of requirements, considering the opinions of everybody in the team.
Remember, for projects to function, tech leads need to make the right decision at the right time. There will be tradeoffs involved. Not everybody will be happy, but that’s what’s required in the best interest of the project and customer. It’s easy to think that people will like you more if you do whatever they want, but in fact, it’s quite the opposite. People don’t appreciate pushovers — they use them.
I’m not telling you to stop consulting the team. It’s always a great idea to keep the team involved in the decision-making process. But there will be times when the discussion needs to cease and decisions have to be made. These are the times a good tech lead needs to take control and stand out.
Don’t Bend Under Pressure
Remember the triangular battlefield we spoke about earlier? Bad tech leads get overwhelmed by pressure and do the wrong things.
Code is like food. It can be fast, good, or cheap. Pick any two. A tech lead overwhelmed by pressure tries to get the team to do all three things at once. They give little notice for urgent requests and rarely want to talk about what it actually takes to create software that does its job. They’re driven by deadlines and commitments made by somebody else, and the team beneath them bears the brunt.
Remember, as a tech lead, you always have two choices — your commitment versus your fear. Your commitment is the date and deadline given to you to complete your work. The most important thing you have is your word, your trust. You have to make it happen, come what may. That’s where you earn respect. You experience fear when someone else makes a commitment on your behalf.
A good tech lead is all about “getting real,” and communicating that reality to all stakeholders up and down the chain. If that locker functionality will take two weeks—it’ll take two weeks. If the archiving feature isn’t available in the software, it’s not available. Simple as that! They don’t hide anything or set unrealistic expectations.
Remember, being a good tech lead is not about making perfect decisions. It’s more about giving better explanations supporting the decisions you make. You don’t need to make the right decision 100% of the time. But you need to make decisions—which are at least 80% right—and stand by them, come what may.
“You can’t make decisions based on fear and the possibility of what might happen.”
— Michelle Obama