Congratulations, you’re considered a “Technical Lead”. Maybe you were promoted and it’s your official title. Maybe you’re just really productive and your manager informally considers you the “lead” on the team. Some companies have formal hierarchies with official ranks and titles. Some may have flattened informal structures, some may be in the middle. Regardless of your environment and how you got here, people are now using the “leader” buzzword to describe you. How should you behave now? What do you need to do differently? What do you need to keep doing? I’ve attempted to distill this down into 5 behaviors that make great technical leaders.
Technical Excellence
You don’t need to be the rock star coder on your team. You don’t need the best and the fastest. Because, being the best and the fastest doesn’t necessarily translate into leadership. I’ve worked with younger developers that can code circles around me. They seem to have a deeper understanding of the languages and tools and code flows faster from their brain to the keyboard. This is not bad and does not make you an imposter. Being a leader blend of other skills. Speed is just one aspect. However, you do need need a level of excellence and competence that your team can respect and learn from because you’re leading from the front. Your code and architecture needs to be clean, understandable and creating value. I recommend following Bob Martin’s principles at all times. Anything you write needs to be an example for the rest of the team to follow. Remember, your team will ultimately ignore what you say and imitate what you do. If your code is crap, don’t be surprised when everyone else writes crap.
Vision
Your job is not to sling code all day. This one is particularly hard, because as an engineer I enjoy writing code. When I’m cranking out code I feel that I’m adding value. At times you’ll need to dig deep into an issue or help code a difficult part of the project. However, as a lead if you’re buried in an IDE all day you’re obstructing your vision. You need to maintain situational awareness of the overall landscape. Without any foresight your team will be chaotically reacting instead of anticipating and thoughtfully responding. Spend enough time out of the trenches so you can collect, process and organize information about work that is headed your way. This enables you to understand the work, prioritize effectively and make informed decisions. This creates a sense of control, safety and predictability for you team. Ironically, you’ll free up time and mental energy to be more involved in the code.
Communication
I tend to be an introvert and the old me hated talking. My social abilities or lack thereof was a factor in why I was chose software engineering as a career. I incorrectly assumed working in software meant I would never have to talk to people. It would just be me and the computer and the computer would do whatever I programmed it to do. This was a bad assumption. I soon realized the engineers that advanced in their careers were all outstanding communicators. I was amazed at how well they could code, but also how clearly and concisely convey information to others. What was really impressive was how well they could tailor their communication to their audience. Tailoring their speech to each audience conveying a lot of information in as few words as possible. They could speak low level tech details with other engineers, business outcomes and strategy to stakeholders, or report achievements and impediments to management. Apart from being great talkers, they were great listeners too. Listening is the other side of the communication coin. I refer to a former colleague of mine as “the best communicator I’ve ever worked with” What set this individual apart was how well he listened in addition to the qualities I just mentioned. Whenever you spoke to him you truly felt heard, understood and valued. Because he listened so well, he was always well informed. So know your audience, speak clearly and concisely, and listen when people speak to you.
Trust
In my opinion, the lack of trust is the biggest hindrance to engineering teams. Lack of trust is a reason why we have massive bureaucracies, energy draining processes, and dysfunctional work environments that suck the joy out of building software. As a leader it’s important that people trust you and you reciprocate that trust. You may not be able to change your entire organization, but you can change you’re immediate circle within your sphere of influence. Here are some guidelines to build trust.
Don’t ask others to do something you are not willing to do yourself.
Shield your team from non-essential time wasting activities.
You can’t know everything, seek their input and opinions. Demonstrate they are heard and understood.
Let them influence decisions. If a decision proves to be incorrect, support them.
Show them mistakes are opportunities for growth not punishment. Most decision are reversible anyway.
Titles and promotions aren’t your primary motivator. Building excellent software is.
Build Others
Time is the most scarce and non-renewable resource there is. Once it’s gone you can never get it back. You have a finite number of hours in your day and many different things will compete for that time. You need time to eat, sleep, pursue hobbies and take care of your family. Even if you could work 24 hours, you’re still limited to 24 hours so your effectiveness has hard limit. The way you scale is by building up others. You need a team and you need to be raising the skill level of that team. This is hard and it requires practicing the other qualities we just talked about. Vision, trust, communication, and technical excellence. Wayne Gretzky is the greatest hockey player of all time not because he holds the NHL’s record for most career goals, but for how he made everyone on his team better. He additionally holds the NHL record for most career assists. In hockey, the assist is credited to the last 2 players who enabled the goal to happen. This is what made him so valuable, he enabled everyone else to be their best. So how does that translate to software.
Don’t hoard knowledge. Hoarded knowledge does not give you job security.
It makes you a liability. Actively share what you learn
Delegate effectively. If a task is easy for you, teach someone else how to do it
Don’t micromanage. If you’re team can do something 80% as well as you, leave them alone.
Give your team room to make mistakes.
When they make mistakes, use them as learning opportunities.
Conclusion
Practice these qualities daily and you’ll find your team is healthier, happier, more effective and you’ll become a leader people will choose to follow.