DEV Community

loading...
Cover image for From Engineer to Tech Lead - Doubts and Challenges

From Engineer to Tech Lead - Doubts and Challenges

Davide de Paolis
Sport addicted, productivity obsessed, avid learner, travel enthusiast, expat, 2 kids. πŸ‚βœˆπŸšžπŸŒπŸ“·πŸ–₯πŸ€˜πŸ‘¨β€πŸ‘©β€πŸ‘¦β€πŸ‘¦πŸš€ (Opinions are my own)
・8 min read

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

allow worse job

I know, it's hard, it's terrible ( and a bit arrogant), but it is true.

shocked

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

Discussion (35)

Collapse
darksmile92 profile image
Robin Kretzschmar

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 :)

Collapse
pjotre86 profile image
pjotre86 • Edited

I alway find it a pity when a good developer takes over a role like that and starts speaking like that (I heard most of these phrases many times before). I think the impact you can have as a developer is much higher, but in many companies you're being encouraged to take over one of these "leading" roles after some time. 2 years later they are usually outdated and lost touch "to the frontier". That's the point where they become in fact meaningless, but still have to be somehow respected because of their title. That's when regular devs just smile and nod at your phrases in 1on1s and go on with their work.
Sorry, I don't know you, maybe your different. But I just had the other kind...

Collapse
dvddpl profile image
Davide de Paolis Author

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? )

Collapse
naticaceres profile image
naticaceres

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.

Collapse
xapuu profile image
Xapuu

"That's when regular devs just smile and nod at your phrases in 1on1s and go on with their work." so true sometimes :D

Collapse
heytulsiprasad profile image
Tulsi Prasad

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 πŸ‘

Collapse
naticaceres profile image
naticaceres

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!

Collapse
dvddpl profile image
Davide de Paolis Author

wow. congratulations for your quick progression!
Thanks for your kind words

Collapse
justynclark profile image
Justyn Clark

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 πŸ™‚

Collapse
dvddpl profile image
Davide de Paolis Author

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.

When you do good, people notice quietly and good comes back to you.
I hope you will get all the recognition you deserve, and when the time comes you will realize you are not giving up part of your joy but just taking in some more and find joy in new things!

Collapse
tcelestino profile image
Tiago Celestino

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.

Collapse
steelwolf180 profile image
Max Ong Zong Bao

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.

Collapse
akizor profile image
Daniel Placinta

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.

Collapse
dvddpl profile image
Davide de Paolis Author

Agree! Thanks for the advice!

Collapse
dvddpl profile image
Davide de Paolis Author

Thanks. I still think I have a lot to learn before I can say I have learned to delegate..πŸ˜…

Collapse
steelwolf180 profile image
Max Ong Zong Bao

Yeah it's a ongoing process that i am still learning as well.

Collapse
kethmars profile image
kethmars

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?

Collapse
dvddpl profile image
Davide de Paolis Author

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.

Collapse
okonetchnikov profile image
Andrey Okonetchnikov

Thanks for writing it! It resonates so much with me as I’m also not an easy person to work with and I’m in the same situation right now. It’s been very challenging and almost led me to a burn out. Your post helped me realize I’m not alone in this boat. So thanks for that!

Collapse
aliadnan profile image
Ali Adnan

Great post . Thank you. This is so much helpful for me. I learned so many new things especially:
Focus on Impact and not personal output
"let them do a worse job than you do"
focus on actions , what you can control and not the "fruits of your actions" which are not always in your control

Collapse
olivierjm profile image
Olivier JM Maniraho

The hardest part is embracing this

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.

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.

Collapse
oaraujocesar profile image
CΓ©sar O. AraΓΊjo

That was a must read!

I'll save this article to read every time I need to remember something about being a Tech Leader! Thank you!

Collapse
sssrox profile image
Shyam

Good post.
Many times facing the situation being transition from Sr.Dev to Lead "Resist the urge to take over the task". It difficult as we are responsible for a quality delivery within committed deadlines and many times considering myself accountable for all the tasks leading to micro management

Collapse
maixuanhan profile image
Han Mai

Unicorned. I can't agree more. This make sense and it is totally opposite to what I've heard from some people recently. Thanks.

Collapse
dvddpl profile image
Davide de Paolis Author

Thanks.
Interesting... What did you hear from other people that transitioned to leadership positions?
Maybe I got I wrong all these months.πŸ˜…

Collapse
ben profile image
Ben Halpern

Nice post

Collapse
aaliceinw profile image
aaliceinw

Love your post. It provides a lot insight into what it means to lead after being a collaborator who may lead during implementation.

Thanks for sharing your experience.

Collapse
nhatnguyentim profile image
Hoang Nhat

Great great post, thanks for sharing. This is the position I am striving for, but if Techlead has less time coding, then how one can keep their skill sharpened? Thanks.

Collapse
dvddpl profile image
Davide de Paolis Author

that is the trickiest part. sometimes... when your skills get rusty... you transition to less technical leadership positions (people management), otherwise you might become one of those techlead/principals dynosaurs who are in charge for every architectural choice, but not really taken into account by the devs in the trenches, because they are too far away, from the projects and from the teckstack..

honestly I try to dedicate some time to keep my skills sharp,

  • be it coding or just reading articles,
  • making code reviews are always a good way to learn and stay close to the tech and the code base,
  • having pet projects Furthermore, something that i noticed even in the last few years is that thanks to all the experienced I gathered in different projects and different languages, I am able to grasp new stuff very quickly, I immediately get the gist of a new framework and are able to dig in the docs better and quicker, so even if I spend less time coding, I am still able to support my team members when they need technical support. Hope i can keep doing that, as projects and team size grow.
Collapse
nhatnguyentim profile image
Hoang Nhat • Edited

Thanks for your Great detail sharing, this part is the most concerned for me because I just love coding and currently work as Team Lead (technical) in my company. I really don't want to lose the coding part. Again, Thanks Davide.

Collapse
monacool profile image
monacool

Nice post, thanks!

Collapse
09_abdelmalek profile image
Abdelmalek_09

Thanks for posting this post , it's really contains a lot of information and tips

Collapse
minhpn profile image
MinhPN

Great post!
Sometime, I have a few questions into myself. That's what i need.
Thank to sharing!

Collapse
taitran profile image
Tai T.Dinh

Thanks for sharing

Collapse
bn_geek profile image
Mohcin Bounouara

I liked this blog post, my reading come in the time.