Developer to Team Leader: What you’re Not Told
As many engineers have experienced before, I faced a dilemma. It was whether to continue being focused on the pursuit of technical excellency or to give a try to the managerial side of the industry. I wondered if it was possible for me to have a bit of both sides at the same time, so I decided I would like to take on the challenges of becoming a team leader.
The team leader role is defined in a different way, depending on the workplace. Here at Docplanner, being a team leader means that part of my time is still reserved for coding, while the other one is devoted to helping the team in staying motivated, being efficient, and in the best possible condition for achieving the goals the team has, as well as, each one’s professional goals.
I read quite a lot about what to do when you want to become a team leader and about the set of skills required to be a good one. But when the time came for me to step up into my new role, a few surprises were waiting just around the corner.
“The greatest leader is not necessarily the one who does the greatest things. He is the one that gets the people to do the greatest things.”
— Ronald Reagan
Leading is not about giving orders
The one concept I had clear is that leading is quite the opposite of giving orders: leaders are expected to empower the people around them and help them grow.
I knew I would have to learn how to set clear goals for my teammates and help them succeed. I would need to be a role model of team values, and most importantly, I should always have in mind that I am a part of the team, not a boss.
Change how you plan your days
During my first days as a team leader, I found out I had to allocate a lot of my time for meetings with other colleagues interviews with candidates. The time I had available for coding felt like non-existent, although looking at my schedule, it was there. After years of doing tasks that produced tangible results (lines of code, working software), I was leaving the office every day feeling I hadn’t been productive at all — until I was advised to read Maker’s schedule, manager’s schedule by Paul Graham.
After understanding that the issue was with how I set up my hours, I tried to have all my meetings as close to each other as possible, allowing for longer chunks of time I could use to work on my coding tasks.
I also learned to pay attention to the time of the day I set my meetings with people who are running in the maker’s schedule: having them directly before or after lunchtime works best, or just after another meeting if there’s any. It’s important to avoid splitting long periods in their schedule into smaller chunks whenever possible.
You truly have to manage your time
As a developer, you can expect to be working on a project where there is someone who decides which features need to be developed and which tasks have the highest priority — name it a client, a stakeholder, or, in my case, a product owner.
As a team leader, you don’t get to be told what needs to be done next, you have to figure it out. I have regular 1 to 1 meetings with other team members where I get to know about people’s ambitions, concerns, and how they are doing in general. I get feedback about the processes and conventions we follow, and I am told which ones are working, which ones need to be reviewed, and where do we lack something. I also constantly question if said processes are still providing value to the team, even if nobody else mentions it. Based on all that information, I learned to prioritize that kind of issues and to decide how much time I need to devote to finding solutions to them.
Empower your peers
Even if the amount of time I had available for coding decreased a lot, I found it very difficult to stop taking ownership of every task I was presented with. I had to change my mindset, and I forced myself to think about the impact of the tasks in the big picture instead of trying to be in control of every minor detail.
I stopped doing tasks “just because I was the one who knew how to do them.” Delegating tasks not only allowed me to concentrate on getting comfortable with my new, different assignments that required my attention. It also meant that others would gain expertise in some of our projects they previously didn’t have knowledge of. This expertise allowed people to find new areas of interest and decreased the company’s bus factor.
You provide value in a different way
If you have a tendency to fall victim to the impostor syndrome, here it is where it will kick in. It did for me. I struggled a lot when managing the part of my time to be dedicated to coding. It was obvious that I didn’t have as much time for it than when I was a full-time developer.
On the one hand, if I took responsibilities over large tasks that were dependencies for other ones, I felt I would be a blocker for the rest of the team, since I couldn’t keep up with their coding speed, and they would end up having to wait for me to finish. On the other hand, completing only short, simple tasks felt like I was providing very little value to the team, if any.
Fortunately, I have colleagues with broad experience in leading and mentoring people. It was of great help for me to have talks with them, share my concerns, and listen to how they measure and give value to the time they spend on meetings and performing management tasks.
You don’t need to have answers for everything
As a team leader, I now get exposed to a wide variety of problems that affect individual developers or the entire team, and I am expected to take ownership of finding solutions. That does not mean I am required to be a know-it-all and to have an answer to every question immediately.
When I don’t know how to solve a particular issue, I can still take ownership of it by asking other people who might have some ideas. I can make sure that the agreed solution gets put in practice and measure if the changes are having any impact. In fact, most of the problems require the entire team to reach consensus and agree on the preferred actions to take, so single-handedly deciding on a solution is not even an option.
Summary — How to jump in the new role in less than a tweet:
- Start slow.
- Delegate some of your tasks. You need to make room for new ones.
- Trust your team.
- Understand how projects fit in the big picture.
- Don’t worry if you go home feeling you haven’t done anything useful (do worry if this continues once you are established in the new role!).
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
