A great man doesn't seek to lead: he's called to it.
- Duke Leto, Dune -
After being a technical lead for three years in my current company I decided it was a good time to retrospect on it and share my experience and conclusions. I hope you find my experiences helpful.
Disclaimer: Any statement here are solely based on my experiences and knowledge. I am by no means a Leadership Coach so some conclusions I provide might be clash with some established ideas and conceptions. And that's ok, challenging what's established is always enriching!
Introduction
We are developers. By default we are not the most charismatic people in the world (this is why we are developers after all, otherwise we might have picked another less solitary profession). However, I felt like working up and improving certain soft skills at the same pace as technical skills could boost my career. I found the chance to be on that role and I took it. And I never could have been more certain.
During these years I learnt a lot. I made mistakes. I messed up. And on occasions maybe, and just maybe, I was right.
I'm going to highlight those aspects of the tech lead role I found the most challenging and important, and most of them, surprisingly, are not especially tech-related; most of them refer to communication with your team and behavioral aspects.
The topics I'm going to pinpoint in this article are:
- Communication and self-retrospection
- You are a selfless enabler
- "The teacher"
- It's not about being bossy
- Manners and feedback
- It's good to be a point of technical reference, but it's not mandatory
- Share ownership
- Ultimately, it's about being an actual leader
Communication and self-retrospection
It looks pretty obvious, but communicating effectively is an essential part of being a tech lead. You will have to talk with a lot of people, from developers to clients, crossing product owners and testers in the path. You don't necessarily need to be always talkative, it is way more important to listen and understand foreign ideas while realizing that not everybody will understand your technical jargon.
When communicating with your team, sometimes you might be a grumpy furious monkey without being aware of it. This is why, from time to time, you should sit down and look at yourself from the outside in order to find gaps in your communication skills or behavior. Even when writing these lines I'm just realizing some communication mistakes I did several days ago which I was completely oblivious.
You are a selfless enabler
Tech Lead is a role meant to be selfless. Yes, we are all busy with our own share of work. But after all your teammates and you navigate in the same direction inside the context of the project. I like to think about it in an epic manner where you are a Spartan hoplite carrying a spear and a shield, but your shield is not meant to protect you, but your comrade at the left.
Is a fellow developer blocked and you can help? Go help him ASAP and, if you cannot do it right now for whatever reason, kindly tell him/her to meet up at a specific, later point in time to tackle the issue (note the word specific) or delegate the responsibility to another team member.
Neither you should hoard knowledge. I remember a debate with a former colleague from another company where he defended that, if you are good, it's better to keep your knowledge and best practices for yourself, with the statement that most people he shared his knowledge with were ungrateful and took advantage of that knowledge to step over him. Clearly a resentment from a past experience that sometimes gives you a lesson learned that, when you ponder about it with a good heart you think to yourself "that's a sad way to think about it".
Even if you had any experience like that, I prefer to "flow in the good, selfless direction". Share your knowledge and eagerness to help by default, and if people are ungrateful and no one appreciates it, either you should reflect on how you are providing this help or maybe, just maybe, it could be time to move on to another job/place (yes, there are workplaces which are utter shitholes).
"The teacher"
This follows up a little bit the last statements of the previous section. Another of the roles I have at my current company is that of a "Technical Coach", bringing the more junior employees or new recruits up to speed on the project regarding the architecture of the software solution, best practices, coding techniques, etc.
When I was at university, I wanted to be a professor there, teaching Software Engineering to students, sharing my knowledge while researching something awesome. I just loved that idea, and I studied a master oriented towards a Ph.D. on the area of Software Engineering.
So, when I receive a question from one of my fellow dev mates, this part of me triggers and I just fire the cannon of knowledge and experience on the topic relentlessly, even when unrequested. Not all people are equal though, and while some will appreciate your wisdom, others will frown upon that.
You do not have to always be "the teacher". It's a bit like the classical advice you are given when flirting in your early 20's: do not go all out unless you are requested so and keep a juicy bait on the hook.
Even then, I have a personal conflict over this. I like the TV show Avatar: The last airbender, and one of my favorite characters is Uncle Iroh, the uncle of the main antagonist of the show. He spreads wisdom everywhere, even if his own nephew doesn't want it. Still, I love Iroh at heart. I would love any reader to share his opinionated view on this.
It's not about being bossy
The role is not meant to exercise authority and supremacy over others. I like flat hierarchical structures, since it promotes the feeling of ownership of the solution and the flowing of ideas from all directions in a team. Even though formally in your contract you are the technical lead, you are still one more developer and you must consider your fellow teammates as an equal.
Yes, as the tech lead you might be the only technical guy from your team invited to certain meetings for the sake of keeping noise under control. But that doesn't mean that you belong to the Bilderberg Club. Try to act as a voice and speaker for your team, not yourself.
A subtle, yet significant change I noted and changed: When introducing myself to either new job candidates at technical interviews or clients, I started stating my role as the Technical Lead of the development team. Recently, for the sake of that flat hierarchy inside the team, I changed that and started introducing myself simply as a software engineer or backend developer. It made me realize it's just not necessary to boast yourself at the slightest opportunity (unless by protocol they need you to introduce yourself as such)
This brought me to the following conclusion: Humility is a good quality for a leader. Your contributions to the conversations, your communication skills and your confidence will eventually give a clue to the rest of the team who is the leader.
As I was writing this though, a thought clashed my mind. In this era of big CEOs on big companies or big personalities where everybody thinks of them as true leaders, I perceive most of them are everything but humble. Just one more example that sometimes statements and lessons learned depend on perception.
Manners and feedback
Yes, you and your teammates are going to screw up. Someone will not follow gitflow to the line and have a polluted remote git repository. Some code will make you pour blood from your eyes when reviewing a pull request.
There are people, however, willing to improve and listen to feedback. If you find those, kindly address them and provide them with constructive feedback. People will appreciate it. Just remember this quote from Lincoln when giving "constructive feedback": "A drop of honey catches more flies than a gallon of gall".
AND REMEMBER, the same works the other way around. Feedback is a gift, a very difficult gift someone gives to you (it's always way easier to stay silent and let people fail). Take the time to appreciate it if you receive some.
It's good to be a point of technical reference, but it's not mandatory
There are a number of reasons you might have obtained the role of tech lead of a team: it may have been your technical prowess, your communication skills, a mix of both...
Remember though that you are not a walking encyclopedia: you do not know everything, nor you should force yourself to attain such state, nor you should look pedantic. It's ok to admit you don't know something. If a teammate is blocked though and you are required to solve a certain problem do what any other developer worth their salt would do: research, test and solve it.
Neither you need to be the role-model or that steadfast statue one-hundred percent of the time. We are humans after all: we laugh, we explain bad jokes that make our mates either fall from the chair or frown upon us, we may have bad days. Showing weakness it's ok (and in fact, deeply, people appreciate it, it makes you more approachable than keeping the barrier up all the time), just make sure you always keep cool and don't let any storm you generate fall upon your teammates.
Share ownership
As a tech lead, the definition of the architecture and implementation of parts of the software system are your responsibility. But that doesn't mean that you should define it on your own. It's a good idea to build something considering the input of your team. It's easier for developers to build something if they contributed to the solution actively.
Do not be afraid to share ownership and collaborate with others to build a software solution. They are not paying you to be a hero. While making developers feel like the project is their child is cool, it's actually not yours unless you are the owner of the company. They are paying you to promote best development practices inside the team, coach junior members and new recruits, and offer a working, maintainable solution to the problem at hand.
Ultimately, it's about being an actual leader
Even though your contract might state the word "lead", it's not enough. A leader is someone that people follow by their own will. Remember that a leader that people follow by force is not a leader, but a mere boss.
And trust me, it's way, way, way more rewarding for everybody if people follow you because they want to. Not everybody is going to like you and that's ok, try though that statistically most people like you or retrospect about why it's not that way.
Conclusions
I'm a developer at the core, but having had the opportunity to develop a good share of soft skills in the shape of technical leadership has been one of the most rewarding and personality-bending steps I ever took on my career. It has changed me for good: it boosted my communication skills both inside and outside the technical team and gave me the chance to be able to share the joy of facing new technical challenges with my team.
Nevertheless, being a technical lead (in fact, any leading position in general, not necessarily technical) is deeply bound to your own personality. If your personality clashes with some of the aspects required for the role (you're selfish and have a boundless evil ambition, or you prioritize yourself over your teammates), you'll eventually show up your true colors. So TL;DR: don't be an asshole.
Top comments (1)
Thank you for an article. As a developer moved to tech lead position I can relate. You didn't mentioned in the article but I am curious about deadlines. How do you approach timeline commitments?