Engineering Ladder - Being in The Middle Sucks?

You might be wondering to what "middle" am I referring to?

It's the middle I'm currently in, the middle of the Engineering Ladder, focusing on the Tech Lead role. This role sits between the Developer/Individual Contributor and "higher" roles like Staff Engineer (SE) or Engineering Manager (EM), combining aspects of both.

A Tech Lead is still contributing to the code base and has its own fair share of tasks/milestones/deliverables, but he is not anymore working "on its own". He has a team of people to lead, to watch over the codebase/architecture, to approve technical specifications, to watch over the product and more.

As I'm diving into this role, I wanted to give you my cent or two on what I think is the most interesting part of the role "upgrade". It's about the Tech Leads relationships to both the Developers on one and the SEs and EMs on the other side.

Just to be clear, this won't be 1:1 to all Tech Lead roles, their responsibilities and their descriptions. This is just my point of view on being a Tech Lead at Productive and the way we see this role.

Tech Lead - baby EM?

If you read books or posts about management, you probably read something like:

Being a Tech Lead is an exercise in leading without authority.

The without authority part is pretty true imo. Your work starts to depend on other people but at the same time you don't really have some authority over them. You can and must have the situation in control but if the situation gets out of hand, you can't resolve it on your own - you need your EM. Again, this depends on the level that your company expects you to work on as a TL.

For me and the way I see it, the most interesting and challenging part of being a Tech Lead is exactly that, the subtle intro to a management role.

It's a role where you should really start thinking a lot about the people you work with.

Several relations come into play and thats mostly bcz you have to watch both up and down from where you're standing.

Looking up the 🪜 - Staff Engineers and Engineering Managers

Your relationship with your EM must be build on solid ground. Your EM has to be a person you enjoy working with, you have a lot to learn from and a person you respect for the things he has done and still is doing. If you are not on the same page, it's less likely that you will benefit from this relationship as much as you could in a "good setup".
In my case, both of my EMs over the time were people I worked with from the first day in Productive. Over the years while working here, I learned a lot from them. The technical aspect is not as important here as the whole overview on how they get things done is - how do they approach problems and how do they solve them.
Other than having a good relationship with you SE/EMs, the main point here is that you have to trust their calls and support them publicly, to help them set those ideas in action. If you don't believe that what they are doing is going to help either you, your team or your organization, you will do a "bad job" here. That's because you in the first place won't accept those new ideas and implement them into your workflows and processes. How could we then expect the rest of our team to do so? One should lead by example.

Looking down the 🪜 - Software Engineers

On the other side, you also have to have really good relations with the people you "manage", the people in your team. In my case, being a TL for the Core Team, there are 3 Backend (BE) and 4 Frontend (FE) engineers (including me and the FE TL).
It is essential for us to know the strengths and weaknesses of our peers so that we could assign them the tasks in which they will prosper and in which they could learn and gain knowledge.
You also need to know them in order to know how to best approach them and to set your EMs ideas in motion. How to present those ideas to them in a way that they also see a benefit in them and not just "something new" they have to do.
These relationships and the work you make on this front will tell you if you are fit to be in management or not. Working with people is not for everyone and those who do it should do it for the right reasons - and that's basically to do it for the people you are managing and seeing them grow.

Looking at yourself 🪞

This is really important. Don't forget to look on yourself - on your motivation, on your moral and your overall "standards".
You could be great with both your SE/EM and your team members, but you shouldn't just be a proxy between them.
Have your opinions, question your EMs ideas, question your team members and look at things without bias. Not everything proposed by any side should be accepted blindly - as I said before, you should know all the details of the changes you are implementing so that you could expect people to follow.
For each idea that you are working on you should know what is the thing/problem your are solving, how are you solving it, what are the benefits of doing this and what could you come by down the road.
Those are the topics that you will most likely be going over with your EM.

What to take home from this 🙃

Ask for Feedback

What I think that people in this role, actually any new position, would benefit the most is feedback

For me, feedback is always welcome. Often times I even ask for it before the scheduled 1-on-1s, 360s or other kinds of performance reviews.

It should be pretty obvious when a newly promoted TL starts doing some of his new chores and that can go in both directions. Anyway it goes, it's great when your EM has your back. When he shares positive feedback about the good things you are doing and how to make the "bad" things better, how to handle them in a more appropriate way.

So my dear EMs, watch on your TLs, look out what they are doing, tailor your 1-on-1's to check the progress and their thoughts. Try remembering when you went thru this phase and what helped you to adjust to this new role.

Tell the people around you what's up

I noticed that my communication to some of my peers lately changed. In our chat there was a lot more work related messages - asking for status updates, asking for estimates, proposing them changes in their workflows, asking for explanations on decision, ... But I never actually told them why did I start making all those questions, asking for answers and started giving advice on workflows/processes.

So I wrote them a message explaining that now, as a TL and owner of some milestones, I have to have a better overview of their work and that we will have to communicate more often.
That I will probably be annoying them with status checks on tasks - trying not to micromanage tho.
That they can involve me in their Github Pull Requests (PRs) where they usually wouldn't - not as a reviewer, just as a subscriber.
I told them that I'm here to help them get unstuck with their task, at least try to help and to further delegate the issue.
That they can always ping me if they needed advice.
And I ended it with - "give me feedback at any point, correct me if doing something wrong or if you don't agree with me on something".

And when I start a conversation with someone new, this is now one of the first messages I start the conversation with.

That seems to be working well so far.

All in all

Ain't gonna lie, this really is a journey with a lot of downs and occasional ups. It's a change that sets you far out of your comfort zone. Just when you think you figured something out, you spot a flaw and find yourself two steps back.

Thoughts of going back to being an individual contributor sound great most the times you hit a low 😅 But if you remember how you learned any new thing, that probably looked a lot like this: you get out of your comfort zone, fail a few or a lot of times but eventually you figure it out. We must get out of our comfort zone to learn and to grow.

Ultimately, this trip to management is not irreversible, you can always take a step back and give it another shot later. Reflect to this experience and try to get the max out of it so that you know better next time.

So, does it suck to be in the middle?

If you ask me, depends on the day 😅 I would say no it doesn't, but damn, it sure isn't easy.