by Oleg Sklyarov, Fullstack Developer at Skyeng company
For a developer, becoming a team leader can be a trap or open up opportunities for creating software. Two years ago, when I was a developer, I was thinking, “I want to be a team leader. It’s so cool, he’s in charge of everything and gets more money. It’s the next step after a senior.” Back then, no one could tell me how wrong I was. I had to find it out myself.
I’m naturally very organized. Whatever I do, I try to put things in order, create systems and processes. So I’ve always been inclined to take on more responsibilities than just coding. My first startup job, let’s call it T, was complete chaos in terms of development processes.
Now I probably wouldn’t work in a place like that, but at the time, I enjoyed the vibe. Just imagine it — numerous clients and a team leader who set tasks to the developers in person (and often privately). We would often miss deadlines and had to work late. Once, my boss called and asked me to come back to work at 8 p.m. to finish one feature — all because the deadline was “the next morning.” But at T, we were a family.
We also did everything ourselves — or at least tried to. I’ll never forget how I had to install Ubuntu on a rack server that we got from one of our investors. When I would turn it on, it sounded like a helicopter taking off!
At T, I became a CTO and managed a team of 10 people. So it was my first experience as a team leader.
Then I came to work at D — as a developer. And it was so different in every way when it came to processes.
They employed classic Scrum with sprints, burndown charts, demos, story points, planning, and backlog grooming. I was amazed by the quality of processes, but at first, I was just coding and minding my own business. Then I became friends with the Scrum master. I would ask him lots of questions, and he would willingly answer them and recommend good books.
My favorite was Scrum and XP from the Trenches by Henrik Kniberg. The process at D was based on its methods. As a result, both managers and sellers knew when to expect the result.
Then I joined Skyeng, also as a developer. Unlike my other jobs, it excels at continuous integration with features shipped every day. Within my team, we used a Kanban-like method.
We were also lucky to have our team leader, Petya. At our F2F meetings, we could discuss anything, from missing deadlines to setting up a task tracker. Sometimes I would just give feedback or he would give me advice.
That’s how Petya got to know I’d had some management experience at T and learned Scrum at D.
So one day, he offered me to host a stand-up.
A week later, I found out that Skyeng was starting a new product, and Petya with some people from our team would work on it. Those who stayed needed a new team leader.
Everything happened by itself — as if I was drawn to the role of a team leader by some sort of gravity.
When a company is looking for a team leader, they often pick someone who is
People like that make good managers, so they are usually the first candidates for an open vacancy. It worked this way for me and a couple of my colleagues from other companies. It’s funny that everyone pointed out that they made almost no effort to become team leaders.
But being appointed as a team leader is one thing, actually being a team leader is another.
The first few days are sheer joy and euphoria. You’re leading a team, you’re in charge, you have so many opportunities and so much responsibility! It was several years after I’d left T, I had more experience, worked on my mistakes, and got to know some advanced processes and methods. So I felt pretty confident about this second attempt at leadership.
But soon the euphoria wore off, leaving me face to face with the routine. I felt some changes.
I couldn't find Zen in my daily work any longer — so I had to focus on the bigger picture. As a team leader, you cannot see the result of your work immediately. It’s both a good thing and a bad thing.
As a developer, you have a build compiled, a task done, or a new feature shipped every day. That brings some sort of enjoyment — I’ve done my job, now I can have a rest.
As a team leader, you don’t get to present the result of your work very often: most of your days are like “planning — Zoom calls — emails — adding tasks to the backlog.” These small steps then create something big like a new app feature. You might not have written a single line of code in months, but as a team, you created something huge.
My team realized the Explore Topics section for the Skyeng app on iOS and Android with a level map for exercises, an energy scale for different types of students, daily goals, a progress tracker, various exercise mechanics, voicing, etc.
It’s all about delegating — you have to quit doing everything yourself. To become a team leader, you have to learn how to code through your developers.
An inexperienced team leader can easily become the bottleneck of a team. Developers do their best job when they’re not distracted, so they have a prioritized backlog, one stand-up, and a couple of calls per week. But when a new feature has to be added to the backlog, or there’s a critical bug, or a server is down, everyone comes to the team leader. His job is to connect people and make sure everything goes smoothly.
There’s a certain risk of becoming a call center operator — and it’s a sure way to burnout in a couple of months.
Here I’d like to say a thank you to my PM. He noticed my problem and recommended some team leader chats and channels, conference talks, etc.
I learned some practices to maintain focus. I informed people I would now check my emails 1–2 times a day, arrange meeting-free days, plan my day on paper (I tried to scale up this practice to the whole team, but developers aren’t big fans of such things). I changed my priorities only in the most critical cases. That way, I did everything on my to-do list.
I had to break my old habits and adopt new ones.
You cannot learn the team leader skills while you’re a developer. As a team leader, you’re a messenger between the business and the development team. Any company aims to make a profit so your clients always want many high-quality features in little time. Developers want to deliver high-quality features but with no rush. Your role as a team leader is to find a perfect balance between quality, speed, and quantity.
In order to do that, you have to build a trust-based relationship with your clients so that they understand what the team is doing, how long it will take, and how to help them meet the deadline. You need to work on your soft skills while also staying firm about your principles. All this along with setting up processes, formats, and the pipeline: how you get tasks, work on them, fix them, and ship them.
All these skills can be acquired. But you have to be ready that it’ll change your personality.
Two years ago, I thought that becoming a team leader would be a natural step in my career as a developer. Now I believe it’s more like a step in another direction. The outcome of such a step depends on the person — you’ll never know until you try.
You have to look at yourself in this role. Not for a couple of months, but for a half a year at least, better for a couple of years. There’s a good chance it’ll be hard and you’ll want to go back before getting any results. My advice is to set a deadline and say, “I’m not going to draw any conclusions before this deadline. I’ll give it a try and then decide whether I like it or not.” That's what I did.
I was a team lead for a year and a half (from September 2018 to February 2020). But I decided to resign and go back to development.
We all work remotely and communicate mostly through Slack — so every step is recorded. It all worked out as I said, and the person I recommended is now the team leader and I enjoy my daily Zen in another team.