Lessons Learned Transitioning to Lead Engineer
After a year at Bitmovin, I got the opportunity to lead a team. In this blogpost I reflect on the most important lessons I learned during the first 4 months.
There are already many articles like this out there. What I try to do different with this one is not only focusing on the lessons, but also on the mistakes I made. Putting my mistakes out there is hard, but I do this to show others in the same situation that a transition like that is not smooth sailing. That everyone makes mistakes, and figuring the whole thing out on the go is ok.
Most of the articles I've read on transitioning to team lead gave me the feeling those people were perfect in their new roles from day 1, which doesn't reflect reality. I hope this article provides a more realistic view on such a transition.
Before the transition started, my manager and I had to get on the same page about the role's expectations and requirements. We did that by defining a set of goals.
The most important ones from my manager were
- passing down focus on customer value to my reports and
- being available, quick responses for questions and in general not blocking the team
And of course I also had goals in mind myself
- Developing the skills of my team, give them space to grow
- Being less authoritative and eliminate micro management
After finalizing the list the transition could begin. My manager, who I'll call M for the remainder of this article, announced the news during the standup.
From one day to the next I was managing a team of 3 junior developers.
> Holding 1:1s
My first act as team lead was setting up 1:1s with each of the developers I’m mentoring, intended to better get to know each other. We knew each other as people and colleagues, but not in a manager/report way.
I asked if they have any expectations, about their (job-related) interests, what motivates them, how/where they want to improve and how I can help. Besides that I explained my 2 most important values, learning and autonomy, and how I imagine it to affect their work.
The first 1:1s continued to be like that. There was not yet much feedback I could give.
In general the goal of 1:1s is to give employees a safe space to address anything that they might not feel comfortable talking about in a more public setting. It's also a time for the manager to give feedback and to work on career progression together.
In my case the meetings were quite one-sided, driven by me. I gave some feedback and tried to spark conversations on how to improve. The people I’m mentoring usually didn’t have anything to talk about. It's hard to believe though that there is absolutely nothing to improve, that they agree with everything and all is perfect.
So the big question is how do you convey that it really is a safe space. That I'm here to help, and if they have a problem, I'll do my best to solve it. That nothing they say will come back to bite them.
Just telling the person isn’t gonna do the trick, I have to prove/show it.
I try to give feedback as objectively as possible, do my best to fix the problems they bring up, and show there's nothing to be worried about. But I'm only human, and there certainly are unintended ways of communicating that undermine my goal.
It got better over time, and I will continue working on it.
> Learning to Plan for Others
Planning is rarely done by individual contributors, let alone planning for multiple people. If anything, the person creating the plan might ask the individual contributor on how long a certain task will take.
Now I get to do the planning.
The priorities are loosely set by the product team. “Loosely”, because I can change them if I deem it to be the correct path of action, which depends on a variety of factors, including
- Technical aspects of the project
- Dependencies, to other teams or tasks
- Size and uncertainty of the issue
- Available people
Dependencies are usually quite obvious and the easiest way to plan for them is simply waiting until they're resolved. This doesn't always cut it though. There are cases when waiting for them to be finished would make it impossible for the team to meet the deadline. Then it's on me to figure out and decide how to move forward.
Factoring the technical aspects and dependencies in was natural for me, since I was already well versed in the projects.
The much more difficult part was taking other people into account, their knowledge, strengths and weaknesses. Not everyone will need the same time for the same task.
Considering these aspects will make the team more efficient, which is a good first step, but not enough in the long run.
As manager you should also have their interests in mind and balance exciting work. Giving one person all the engaging tasks while another is bored out of their mind is a bad way to manage people.
Besides interesting tasks, managers should also balance and shield their reports from organizational pressure, and let just enough through. The right amount of pressure can be immensely motivating, too much and people start to crumble, too little and they get bored.
To achieve that, it's paramount that you know the people reporting to you really well. Everyone reacts differently. Some get a sense of importance from working on a time critical task, others panic. But not only do different people have different pressure resistance, it's also not constant for the same person. It depends on a million factors, including factors outside of their work life, which makes figuring out the perfect amount quite tricky.
For me, as probably for many new engineering leads, the people aspects of planning and management were way more difficult than the technical side.
I worried a lot about everything mentioned above. The problem I had though was that I didn't know my team well enough. Only much later would I figure out that this was the source of the problem. In the beginning I couldn't consider any of that. I just didn't know what their different areas of expertise were or how they react under pressure.
After some time I started to get to know the developers reporting to me, started to see strengths and weaknesses and being able to consider them when assigning tasks. And the more time I spend with them, the better I get to know them and the better I can do this part of my job.
My message to all new engineering leads
Don't worry too much, take your time to properly get to know your reports. Even if it doesn't feel like it in the beginning, you will get better.
> Getting and Collecting More Information
Planning for other people and the future of the project needs information individual contributors usually don’t get. Like the plan for the coming months, upcoming hard deadlines, dependencies to other teams, and so on.
As any other project, the projects of the frontend department had a plan, a roadmap and scheduled issues. Which means in the beginning I was unaware of a lot of that information. I didn't know the plans, how they came into existence or why this was the order of importance and not something else.
This lack of knowledge led to me being insecure in my decisions and redirecting to my manager more than what needed to be.
Particularly in a young organization like Bitmovin, where communication paths were not yet well established, it can feel like being left out. A year ago, our only engineering office was in Klagenfurt, where every engineer knew each other. There was a lot of shared information that I, someone who started in a satellite office in Vienna, didn't know.
In fast growing startups it also happens often that new roles are not well defined. Many people do their job for the first time after all. This provides tremendous opportunity, but has the downside that the boundaries of new roles are not well defined. In a company like Google, which has 1000s of managers, everything is documented and you know exactly what you can and can't do.
Because of that I often didn't know if I can make a decision or not, but it created an exciting work environment where I could give input in areas that otherwise I'd likely be excluded from.
To solve my information dilemma I asked a lot of questions. Many of them were about how and where decisions are made. The result was that I got invited to more meetings where our projects are discussed, which helped me gain more insight into them and the information flow in the organization.
My knowledge about our projects grew continuously, as did my understanding of when, where and how decisions are made and who made them. Which in turn improved confidence in my own decisions.
> Thinking more like an Engineering Lead
People naturally focus on the areas they have expertise in and what their job description says. And this is how it should be. Developers focus on the projects they work with. To do their best work and improve the situation there.
In a lead position, I now get to see more of the company, receive more information and have more impact. My focus shifted from development to improving efficiency and effectiveness of the whole team and department.
This shift rearranged my priorities. Instead of focusing on small details, I focus on high-impact code, which will be difficult to change in the future, and give my team more freedom to make mistakes in other parts. I think even more about code structure and software architecture and started asking myself broader questions. Questions like
- What is the best way to manage the people reporting to me?
- How can I improve the team?
- How can I increase my own knowledge and effectiveness?
- How to get more knowledge into the team? What knowledge should we have and what is better done by other teams?
- What does it mean to be a good engineering lead?
- What does it mean to be a good developer?
Unfortunately they don't have one definitive answer. Everyone has to figure it out based on their unique situation.
I didn't have answers at first, but kept those questions in my mind. Borrowing the wisdom of others, by reading books and articles, gave me starting points and helped me develop my own practices.
I'll never be done finding new ones however, circumstances shift, and so do the practices.
>> What are the Characteristics of a Good Developer?
One of the most important questions is what a good developer is for me, which was surprisingly difficult to define. Especially because I personally believe it's about aspects that transcend technologies. It's easy to say the more expertise people have in the technologies we use, the better they are. And to some extent that's true. But software engineering is not static, the technology landscape is always changing, and developers need to adapt. If they know every single line of the React framework, and tomorrow we switch to Svelte, that knowledge becomes useless.
For now I came up with 4 major points:
- Just because it is implemented a certain way, doesn’t mean it is good. You never know why it's implemented the way it is. Maybe there were requirements that aren't there any more. Maybe the person implementing it was under high pressure and took some shortcuts. Maybe that person lacked some knowledge and did the best they could. And maybe it really was the perfect implementation at the time, but new technologies or features made even better ones available.
Improve their skills
- If they find code that uses features they don’t quite understand, they should investigate it.
- If they work on a problem and think a new feature/technology would be the perfect solution, they investigate and learn about it. Even if it won't be used now, it'll help for the future.
Trying to find the root cause
- They don't just fix an issue somewhere, they try to find the right place. It should make sense to be there. Otherwise no one will be able to understand it in the future.
- They also try to thoroughly understand problems before fixing them. Nobody learns by doing blind, shot in the dark, fixes.
Strive to understand what technologies can/should be used for
- This includes all kinds of technologies, libraries, frameworks, but also databases and languages.
- The "should be used for" is a subset of "can be used for". It's a learning process and can never be perfectly achieved, but that's what a software developer should strive for.
These are not the only things I'm looking for, but It's difficult to put a finger on and articulate them, so this is the list I currently have. I'll extend it over time.
>> Expectations and Recognizing Performance Improvement
Knowing what a good developer looks like is one thing, knowing what to expect and being able to recognize performance improvement another.
Developers are not assembly line workers, churning out the same product over and over. Every task is different, which makes it difficult to see how performance changes.
There are 3 categories making up an individuals performance:
- The What: speed and quality of their work
The How: communication, autonomy, learning
- How do they achieve results? Do they communicate well with their peers? Can they work on their own, or interrupt their peers every 2 minutes? Do they improve their knowledge?
The impact on the team
- Do they have ideas that improves the team? Do they drag the team down?
Deciphering their work into these separate parts and evaluating them was impossible for me at first. I tried, but just couldn't see if there was any change.
Many weeks later, in which I got to know the people working with me better and as I reviewed more and more of their code, started to see patterns, started to identify which areas each one is good and where they should work on.
But this still didn't mean I could see the improvement in those areas. I just got a clearer picture of them as people in the workplace. It took months for me to be able to recognize how they got better.
This is another area where I was overzealous and tried to do too much right at the start. I tried to see performance changes when I wasn't ready yet.
You don't take weekly inventory about the skills of your team anyway. Performance is reviewed every year or at most every few months. It's not necessary for change to happen in 2 weeks. And the change that does happen in that timeframe is insignificant. The big picture counts.
> Optimizing Work
A team lead's performance is measured by the performance of the whole team, including their reports. With increased team size the importance of enabling the team increases, while that of the lead developer's individual contributions decreases.
Missing information can slow down engineers to a standstill. The more they have to stop and ask, the slower they'll be. Consequently, the more information they receive beforehand, the faster they'll be.
Ideally a developer is able to receive a task and fully implement it without needing further clarification. Depending on the environment this can happen more or less often. The amount of questions not only depends on the upfront information, but also on how much autonomy engineers have. The more decisions they’re allowed to make, the more questions they can answer themselves.
Inevitably, questions will arise though. How you react to them determines the effectiveness of your team.
It goes without saying that quick responses help staying focused. And for simple questions with clear answers this is easily done.
Then there are questions without clear answers, only trade offs, where you can give guidance but nothing more. These have the potential to morph into discussions and substantially interrupt your own work. The key for those is to find a balance of responding immediately or waiting until it works better for you, referring them to someone else who might be a better discussion partner in this case, or just letting them make a decision. All of that is a valid response.
The third kind are the ones you can't answer at all. Usually about high-impact product decisions or code you don't know about. There are 2 ways to deal with them. Either you figure it out yourself and pass it on, or you tell them who else can help.
With the former you also receive the knowledge and you get the chance to intervene if it gets too complicated. The latter makes developers more independent and gives you more time.
In the beginning I focused too much on increasing my team's autonomy and time for my own work. I left questions unanswered until convenient for me and often redirected them to other people for the ones I couldn't answer. This eroded confidence in my ability to answer questions and led to them asking other people from the get-go. Which in turn made me unaware of the difficulties they faced.
At some point I fixed it by focusing more on assisting my team than doing my own contributions, which had profound consequences on the relationship I built with them.
>> Project Efficiency and Task Reassignment
The more time you spend working in a specific project, the more experienced you become. The more you know its architecture, good and bad parts.
I'm responsible for 4 projects and my team can potentially work on all of them. Introducing devs to a new project creates overhead though, keeping up with its changes and frequent context switches can significantly reduce efficiency. Which is particularly true for part-time employees.
In my team it naturally happened that engineers were mostly working on the same projects, but sometimes tasks of a project they rarely work on got assigned to them. This was when inefficiency struck.
Because of that I decided that each developer only works on the 2 or 3 projects they're most comfortable with.
But sometimes it happens that the only open issue in the sprint is for a project the developer is not familiar with. To follow through with that decision and keep efficiency high in these cases, I need to reassign tasks on which work has already started to the free developer, so the other one can start working on the open issue. Personally I never even considered it as an option. A nudge from M made me reevaluate my position and realize that it is nothing bad, especially in the face of critical tasks.
> Relapse to Old Behaviors
There's no transition to a new role without relapsing to the behaviors of the old. There was one week in which we received a very critical dev task with a hard deadline. Unfortunately I was the only one with enough knowledge about our codebase and our technologies to achieve it.
So I dove right in. To fully concentrate on it, I ignored basically all other responsibilities. Deflected questions and redirected them to other people, delayed PR reviews and didn't check the progress of my team. After all, M was sitting right next to me. If there was something going wrong, he'd notice.
The implementation was done on Thursday. On Friday I realized that I neglected the most important work of my role to focus on my task.
What I should've done was splitting it up, dividing work between the developers I’m managing and myself. Doing it like that would've been faster, I wouldn't have slowed down my team and gave them good learning opportunities.
Much later I figured out why this happened. I didn't trust my direct reports enough.
It's often said that trust has to be earned. But there's also the other side. For trust to be earned, it also has to be given.
If one isn't ready to trust, it'll never exist. Regardless how much the other does to earn it. Those are two sides of the same coin.
And I didn't fully trust the engineers reporting to me.
>> A Nudge from M
What helped me realize it was the implementation of a big new feature. Something that had great impact on the existing codebase.
Usually I would've done it on my own, implementing it while figuring out how it fits best into the existing codebase. But in this case there was pressure on it. M saw that I was trying to do it alone and told me clearly that it won't work like that. That it should not be necessary for me to work overtime to achieve it. That's why I have a team to help me.
So I split the issue into smaller ones and included my team. I removed roadblocks, decided on and implemented the overall architecture and my reports implemented the actual feature.
This way worked quite well and at the time I thought it was the way to divide tasks between us.
This incident, about 2 months in, was a turning point for me. Up until that point I was still an individual contributor at heart, just one with more impact. Reflecting on it later made me realize everything I wrote about trusting my team.
>> Trusting My Team
After some more time I started to understand that even if I focus only on high-level work, I'm still often the bottleneck for the team and limit their chances of growth.
Mulling it over I realized that I don't have to do any task myself. My reports are competent people. There's often just a small hint in the right direction required for them to be able to solve tasks I previously thought I have to do myself.
I moved away from thinking
It's faster if I do it myself.
It’s fitting that the last lesson I wrote down is also the most important of all. If you don't remember anything else from this blogpost, remember to trust your team.
At this point let me recap a bit.
In the beginning I was overwhelmed. I didn't expect the change I have to make to be so substantial. Particularly people management I expected to be not as difficult as it actually turned out to be.
What also surprised me was how many important aspects there are that cannot be done perfectly, or even well, in the beginning. I worried about doing a bad job when all I needed was more experience. Thinking consciously about them, as well as reading books and articles, helped, but it still takes time to get the necessary experience to put that knowledge into action.
The more time passed the more I also started to trust myself. I'm doing more without M's prior consent and have the feeling I got more trust from him now.
> Final Words
Transitioning to a management position from individual contributor is not something you can read about in a book and then just do. A lot will be different than you expect. Every organization, every person, is unique.
It comes littered with new challenges, frustrations and doubts. Some problems can be solved by thinking about them yourself, some with the help of your manager and for some you have to wait and get more experience. On top of that it's hard to know if you're doing a good job.
Even with all of that, having more impact and being able to help people further their careers is extremely rewarding and I wouldn't want to miss it.