From Engineer to Tech Lead - Doubts and Challenges

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