18 months ago I was promoted Technical Lead of the team where I was working as Senior Fullstack Engineer.
To some extent nothing really changed in my daily activities: even before getting the title, I was already reviewing code, assigning tasks and taking care of supporting and coaching my team mates.
On the other hand, a lot changed in the perception of my role in the team and in the expectations I had from being a Tech Lead.
I have a strong personality with some rough edges, I really genuinely love to help and coach, but sometimes I also get quite vocal ( and passionate ) easily. If it can be acceptable to be a bit too blunt as a peer developer, as a lead you have to be much more careful.
I immediately recognized that I had to work on my people and communication skills.
Also, being officially in charge of people forced me to reconsider my role of Individual Contributor and the expectations I had from other team members.
I am just at the start of my leadership journey, but the last 18 months were already full of a lot of challenges, doubts and learnings. I am sharing them here, to give some advice in anyone willing to become a Technical Lead and to get some feedbacks and hints from more experienced Leads and Managers.
Output vs Outcome
The main difference between being an Individual Contributor and being a Technical Lead goes down to the difference between Output and Outcome. This is kinda still hard for me to accept, but this post from Yan Cui - The Burning Monk really opened my eyes and accompanied me long before and during my leadership journey.
We might have been ninja coders, 10x developers, programming rockstars but the fact is, now that we are technical leaders, we will be coding less, and trust me, we will feel less productive. But, as the post linked above properly sums it up:
the impact you create by helping 10 engineers be 10% better would be an order of magnitude greater than your maximum output as an individual.
Accountability and Responsibility
I am a strong believer and advocate of Extreme Ownership.
As an engineer, I always committed in meeting the deadlines and respecting the estimates. Deliver bug free code and good quality, anticipate problems and propose solutions.
As a Tech Lead I felt I had the responsibility for everything any team member does.
This does not have to be like that.
Each team member is responsible for what he does, and how he does that.
He owns the feature he is implementing.
If you don't trust your team members and you feel responsible for every line of code they write, you end up micromanaging.
This is not good for you and not good for your team.
For you because you are dragged down by details and can't focus on your objectives and team goals.
For your team members because you are preventing them to really take ownership, express themselves in their work, learn and grow.
Of course, if something bad happens, you might be held accountable for it (and you should not just waterfall the blame down to your team), but there is a big difference between being accountable and being responsible for.
Performance and Team Speed
The difference between the best performer and the worst performer in a team can be huge. (check out the Bell curve I mention in this post)
Both because of the output and responsibility issues described above, our tendency could be to try raise the bar and demand that everyone works his ass off, based to our standards.
Even though raising the bar, aiming high and be demanding can be challenging and motivating for someone, for some other can be draining and have the opposite effect.
We must learn and embrace the fact that people have different skills, different learning curves, different drive and motivation, different life goals.
Accept the differences.
Acknowledge everyone's effort.
Quoting again Yan Cui:
You are not there to make everyone become like the top performer (or become like you) rather, what you can aim is that they become better version of themselves.
You can show them how to code better (or properly) , how to learn faster, you can guide them. You can lead them by example.
But you can't and should not expect everyone embrace the change in the same way and speed as you.
You have to slow down if you want to go faster
This is true as a contributor. - if you want to become faster, you have to learn and practice, and this can bring to you being slower for a while. But if you stick to it, you will see the benefit and realize how fast you became.
In just 3 words: Sharpen your Axe
The same is true as a Lead: not only because of course you still need to get used to the new things, new topics, new ways of working and organizing your work and meetings. But in general because you need to count in the time for your team members.
You need time to talk to people.
You need to understand their needs.
You need to respect their pace.
Don't rush in your communication style. Be precise, be patient, let the information sink in, listen.
And resist the urge of transferring all your technical knowledge at once, the very next day you are in charge.
I thought that if I throw at people everything I know, in the form of workshops, brown bag sessions, collective code reviews, pair programming and sort, they would learn faster, they would become faster and better in their coding skills.
But that is wrong.
All this could be overwhelming. Confusion and insecurity can start to spread in the team instead of increased performance, motivation and team spirit.
Like in sports, you can work out and train a lot, always pushing your limits, but you have also to give your body a rest day, respect the regeneration time needed by your muscles. Otherwise instead of becoming stronger and faster, you just get weaker and more prone to injuries.
Leave time to assimilate the learnings, for people to understand and embrace the changes ( a paradigm, a process), for the progresses to show.
Reject the urge of trying to speed things up. Be patient.
The fruits of your work will come.
and if they don't... just accept it.
The fruit's of your actions
One day I was discussing some of my concerns with my Director of Engineering and at some point he mention the Bhagavad Gita:
"You have a right to your actions, but never to your actions´ fruit. Act for the action's sake."
I did not really get that at first, so after our chat, I researched it a bit.
“It's the action, not the fruit of the action, that's important. You have to do the right thing. It may not be in your power, may not be in your time, that there'll be any fruit. But that doesn't mean you stop doing the right thing. You may never know what results come from your action. But if you do nothing, there will be no result.”
I must say I am not 100% satisfied with this quote, applied to leading (or teaching) people. Because in my opinion with "fruits of your actions" it refers more to the rewards than the effects, but I absolutely agree the we should do the right thing, irregardless of the results.
And, the point I guess my Director wanted to make is,
focus on what you can control - which is the input. Let the output figure itself out.
Do whatever you can do. Give people your guidance, your knowledge, your support. You can't blame yourself too much if they don't pick it up.
Be impatient on the quantity and quality of your actions, but patient on the return of those.
This brings us to the next , and as much philosophical, point,
Change comes from within
You can't force change onto people.
Sure you might have some authority and power in your team, but recurring to that rarely helps.
Sure, you could somehow, under some circumstances resolve to disciplinary actions - reprimands or even firing someone... but that is hardly the way a good lead/managers deals with challenges or conflicts.
Again, the key aspect here is Sharing your Vision and Leading by Example.
Leading by example
Especially in Leadership positions where the technical aspect is still strong, we must be an example of Best Practices, Motivation, Attitude.
We should share our knowledge, and show how things are ( or must be) done.
Show the way, don't bring them there by the hand (even less, push them or drag them! )
Mentor, support, enable, make decisions, guide people, listen to them and most of all, be patient if they need time to pick up everything I pass to them.
This sounds a lot of work!
Absolutely!
This is why, one of the most important thing is also,
Learning to delegate
This may vary from company to company or even from team to team, but as a tech lead you are very likely still coding a lot or at least taking care of code architecture or implementation design and code reviews.
When some feature turn out to be very critical, or there are nasty bugs in production, it is normal for you to jump in the trench. Very often though, there might be multiple things that have the highest priority.
As the most experienced person in the team, you feel you have to take care of all of them.
But multitasking is never good, learn to delegate.
Assign those high-prio tasks to your team members, guide them and provide advice but don't directly do all the things all by yourself.
Resist the urge to take over the task. yes, you probably would be faster, and it could even be better coded, but you are stealing the people in your team the opportunity to learn, improve, become more independent and increase their sense of ownership.
And here it comes, probably one of the hardest things that is requested to us experienced senior engineers moving to a technical leadership position is, as mentioned in this amazing and inspiring talk:
Allow team members freedom to do a worse job than you would
I know, it's hard, it's terrible ( and a bit arrogant), but it is true.
This does not mean lower your guard and give up quality, just accept the fact that for a greater good, for the sake of the project, to keep motivation high and maintain your mental health, you have to accept that other experienced or less experience developer can do a good enough work.
Simple recap with bullet points ( that I constantly still read out loud to myself every now and then when things get rough...)
- you are accountable, they are responsible
- listen
- be patient
- take your time
- enable people
- delegate
- lead by example
- let them learn at their own pace
- let them make mistakes
- be patient
- focus on the impact you have on the team, not on the output of the single task
- respect differences
- let them do a worse job than you do
- you are not entitled to the fruits of your action.
- be patient
Photo by Alfred Aloushy on Unsplash
Top comments (36)
Great post!
When I was transitioning from senior dev to a leading role and later on additionally to a scrum master, I was falling down a hole of "I feel unproductive" and felt like I had meetings all day now and didn't do really much productive. The section about that in your post phrased it perfectly and I can confirm to you that it takes some time but you'll get used to it and when you have the chance to code or be productive yourself in any way then, it'll be on an even higher level because of all the learnings you get from coaching others and from watching their growth :)
thanks for your comments.
as i wrote in the end of my post.. i have to repeat those things to myself often, because I must say I still have some doubts. and no week passes without me thinking... maybe it would be better if I just code. that is what i do best.
but then I also see the impact I have as a technical lead, sometime is a question I make during a meeting, sometimes is just giving an hint on some technical issue, and I realize how much time and effort I spared to my team with that.
Yeah. I perfectly know those leads that are far away from the trenches, had many in my career and I definetely don't want to become one of them. Will try my best, and if doesn't work, I can always be back to coding. ( on the other hand, tech leads and engineering managers are needed, so why not trying to be one that is really useful, not only to the company but also to the team members? )
This is a great response.
Just because many have failed at the role doesn't mean we have to keep failing. It just means we need to grow from their mistakes.
I've been working 7 years as a software engineer, and I've been programming for 15 years now. I've seen outdated washed out leaders that just fill their spot and warm their chairs, and I've been honored with bright committed involved tech leads that have inspired and pushed me above and beyond.
I can only aspire to be a fraction as good as they are, and I'll be happy with my role.
They weren't the best at the minutia of day to day coding examples, but the moral in their decision making was impeccable, their ethics were remarkable, and they are to this day at the top of their game in knowledge of design patterns and best practices. All of this is framework agnostic and goes beyond coding. And that is what to me makes a great tech leader awesome.
This is really great, thanks for sharing your experience. Slow down to go faster really works in various aspects other than leading a team, that I've tried 👏
Last year I was thrown into this position when the start up I was working for grew it's frontend team from 1 (just me) to 4 or 5 at a time.
This year I've been naturally gravitating to this role after joining another startup where the same thing happened, except that the original front end engineer evolved into eng director, and the frontend team is now made of 10 engineers and growing.
The challenges are twice as daunting with twice as many people, and I've found this article are opening and inspiring.
I love articles that are open and blunt about their sources, same as with books where I can trace a theory all the way back to its hypothesis. It makes me feel less stupid and more connected to the writer. They are people just like me, that read and think just like me, and don't come up with answers out of thin air.
Great job sir, thanks for the amazing read! I am looking forward for the next article on this series!
wow. congratulations for your quick progression!
Thanks for your kind words
I love it, especially the part on delegation. I had trouble in learning to delegate and give up on my urge in taking the bull by the horn by yourself.
Probably this is the hardest thing in transitioning, knowing you can do better and like you said, taking the bull by the horns. Been transitioning for 6 years by now and still doing so. I may offer a direction if that's ok with you. If the situation demands it, go ride the bull, but use it from a "leading by example" standpoint. Use that situation to teach, to show, get constant feedback while doing so, involve your team members in the resolution, show how responsibility (opinionated, of course) works, describe what you are doing and the principles behind. A good real-life battle is an tremendous use case for others to get a glimpse, a direction, an advice, a resolution for them to digest. Who knows, next time you'll end up with things delegating by themselves.
Agree! Thanks for the advice!
Thanks. I still think I have a lot to learn before I can say I have learned to delegate..😅
Yeah it's a ongoing process that i am still learning as well.
I'll share this. On my team a couple years ago in a retro, someone had an idea to maybe make one of us be labeled a "tech lead" and nominated person X. We all agreed, as this individual had some of the most experience with the code base, was bright and well organized.
He later moved on from the team and co-worker Y was given the "title". I did not congratulate him like everyone else did because I didn't know if he even wanted the role. He later told me he was thrown into it.
I myself am a natural born leader as my 4th grade teacher once told me and have been so in many different capacities for many years. Now I am Senior Software Engineer with over a decade of industry experience working independently single handedly built web sites/applications for clients and their business, worked on several start ups, contract and FT in large corporations and with dozens of developers across multiple teams globally.
I'll admit, I felt I was the one to assume the "title" next. But this wasn't an official promotion with a pay raise. Simply a title. Which really turned into becoming the "meeting man" and one to be called on at all times. He is no more talented or "rock star" than me or the others, but he's great and supportive so don't get me wrong.
I knew what this meant though for him or me. Less coding, more meetings and feeling less productive. I really enjoy coding and leading, and I do so by example. For me, all day meetings don't equal productivity the same way as does turning in clean code, improving processes and shipping new features/products to millions of users.
So in essence, we have two tech leads. One takes the meetings, one's in the tranches fighting for us engineers, for our developer experience, to have our voices heard and providing unique opportunities to learn and grow by example. Some people are just built different, what can I say 🤷🏽♂️
Now, if I had been asked or thrown into it, knowing what sacrifices come along, to give up part of my joy for more meetings, I'd need fair compensation.
To some important points on this post, I've too learned to be patient and when to pick and choose my battles. And overtime the ideas and proposals I dump on everyone fast out of the gate, some got pushed back but have gradually come to fruition and made positive impacts.
I even received a spotlight award last year announced in our department weekly standup from anonymous electors which came unexpectedly.
When you do good, people notice quietly and good comes back to you. Which in my case the form of a Snappy Gift, bonuses and new base salary only within two years of joining the company. 🙏🏽
Still coding and leading concurrently 🙂
thank you very much for you long comment.
i agree, and found myself in a similar position for many years. then i was finally offered the title and the compensation ;-)
Though sometimes I fear I could / should have stepped up in the career ladder before, I am happy that did not happen, because I had the opportunity to get much better as an engineer and to grow as a person.
I see myself in this article.
I recently was promoted as tech lead and my challenge now it is be mentor. Everybody ask me if this “evoluation” changed my routine, I always reply: no. Because I keep writing code, I still reading codes to review but now I need to change my mind because it’s now I need to make more mentoring and teaching than write code.
Thanks for your article. I bookmarked that it I will read again in many moments.
The hardest part is embracing this
Having that feeling to still be as technically productive as you were when you were an individual contributor can be mentally stressing, this is the huge problem I had the first time I took up this role from my former employer.
Thanks for sharing this insights.
Inspiring post!
So now you are the manager of a football team with a gang of individuals each having strengths and weaknesses. And you put them on the lineup according to the needs of the match and their personal skills. You're right, don't train a striker to a defender. Train the striker to shoot more precisely, with more power, and to automate his moves.
All the best and keep your mindset and attitude.
thanks for your comment. and very fitting analogy with the football team.
Great post on an important topic. I've seen it(and done it myself) where devs focus too much on coding when they should instead be leading the their team.
How do you satisfy your urge for coding as a lead? Do you have any hobby projects / have enough coding at work?
so far I am still coding quite a lot, it might be pair programming/mentoring or reviewing and refactoring. Something that is also satisfying is when new projects start and I take care of the architecture design and often set up a basic project with a proof of concept or blueprint so that the devs can go on implementing the features.