How to Be a Team Lead in 2020: Interview with Ivan Gromakovskii

Team lead work is full of nuances – you should wear an invisible helmet made from your experience, carry a sword made from your skills, and also be an open-minded leader who is followed by a group of people with different knowledge levels. Add here all the pros and cons of remote work, and you will be able to imagine the work-life of a Serokell team lead.

In this interview, we talk with Ivan Gromakovskii – a legend of the Serokell technical team. In Serokell, Ivan is famous for his punctuality and productivity. He didn’t mention it, but during his work here, he has participated in ZuriHac, gotten a nickname “the Machine”, and tried his hand at writing articles – we recently posted his comparison of GitHub and GitLab on our blog. Ivan is a team lead of several Serokell projects, and he certainly has something to say, enjoy!

Hi, Ivan! Let’s start at the point when you weren’t a team leader yet. Can you name something that you were already improving during your work as a developer?

When I just joined Serokell, I was working on a small project on my own, and the main goal for me was to learn Haskell because I had no “production” experience with this language before that, I only studied it at university. However, I had experience with imperative languages, so I treated it as “just another language”, even though a quite different one.

Apart from learning Haskell, I was improving my general programming skills: how to structure your code, make it reusable and understandable, how to work in a team and communicate with your colleagues.

How did your colleagues help you with mastering your skills?

Each of my colleagues knows/does something better than me, during our work we constantly learn from each other.

When I make a pull request, code reviewers may suggest an approach that never came to my mind. It works the opposite way as well: when I review someone’s code, I may learn about a new library, compiler extension, or how some complex thing works. When I can’t find a good solution to some problem or understand how something works, I can always ask in Slack, and my colleagues will help me figure things out.

There were numerous cases when I learned something during code review or Slack discussions. Sometimes people discover and share new tools or posts useful for my work. And, of course, by working in a team I can improve my communication skills and skills of being a “team player”.

Can you say that skill and knowledge base sharing between teammates help understand basic processes or learn advanced stuff (like, when you work on blockchain – do you need to know something about cryptography)?

Yes, of course, knowledge sharing is useful. Most often, it happens when someone gets a “research” task which requires delving into something complex. Later on, this person will usually write something about his research and everyone will be able to learn this “complex” topic and ask questions if they appear.

Sometimes we cover basic topics as well. For example, Kirill Elagin wrote some pages about copyright and licenses for internal use. I knew almost nothing about it, so these pages were very helpful for me to learn these basics. Also, we have good internal sources to learn from: practical materials and academic papers.

What new things have you learned during your work in Serokell?

• I learned Haskell from very basic knowledge to advanced.
• I think I became a much better developer in general: I write cleaner code, provide descriptive comments and commit messages, care about tests.
• I learned about the usefulness and importance of CI and code review and that pull requests are cool.
• I learned what to do with code after it’s written (deploy it or package and ship).
• I learned basic cryptography and a lot of things about blockchain, took a major part in developing a new blockchain from scratch.
• I learned how to be a team lead and how to manage tasks properly in a remote company.

What are the main skills for team leads?

First of all, in order to be a good team lead, you need great technical skills and knowledge. No matter what technical problem arises, you should be able to solve it. You should be really good with all the tools and technologies used in the project.

Apart from that, you should be able to take responsibility and make decisions. Team lead is the one that makes final decisions on behalf of the team. When a problem appears, you should take action to solve it. Ignoring it until someone explicitly asks you to handle it is not an option. You are the one who should explicitly ask someone.

Communication skills are no less important. You are a bridge between your team and upper management/your customers. You should clearly explain what needs to be done to the former and provide updates about your work to the latter.

What did you need to learn to become a team lead (that you didn’t know before)?

Of course, I had to improve all the “main skills for team leads” that I mentioned above. To be more specific, one of the things I had to learn was how to split big tasks coming from your customer/outer world into fine-grained tasks that can be independently assigned to multiple developers.

When you lead a team of multiple people, you must make sure that each of them has something to work on and there are no two people concurrently working on the same thing or two conflicting things.

Another thing is how to always be aware of what’s going on in your project, follow how the code evolves. I try to review as many pull requests as I can to always have up-to-date knowledge of our code. So whenever someone asks me to help with a new task, I don’t have to go and see how certain things are implemented in our code, I can start thinking about this task immediately.

How should the team lead help juniors with their tasks?

In Serokell, team leads pick appropriate tasks for juniors which shouldn’t be too hard (as too hard tasks may look scary and take too much time). At the same time, we help juniors grow and the complexity of tasks gradually increases over time.

The next step is to make sure that the person properly understands what needs to be done. Team leads explain what needs to be done, and juniors figure out how it should be done (asking your help only if necessary).

Code review is where the main action happens. I think that team leads should be calm and patient: sometimes juniors might misunderstand the task or come up with a wrong solution. Team leads explain what should be modified and provide guidance. I also review juniors’ code thoroughly and point out what can be improved — it is invaluable for their personal growth.

In our company, team leads provide feedback outside of code review as well, tell the person if they do something wrong or great. We ask them about their satisfaction with their work, maybe they dislike something (e. g. assigned tasks) but are too shy to say.

Is higher education that important for a developer nowadays?

I think higher education is useful to learn basic things that every developer should know. It also helps engineers learn new things faster. After some point, the usefulness of higher education decreases, at least for me.

I think the exact point depends on preferred tasks and domains: if you work on something scientific and like doing research, this point will likely be much further for you than for a person who develops simple web pages, for example.

It is important for a developer to constantly learn something new, but for me, it just naturally happens as part of my work when I need to use a new technology or when I just read a cool article.

As for other materials, I suggest you read «The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change». It’s a good source of practical tips for team leaders and everyone who wants to be a successful manager in the IT industry.

Thanks, Ivan! We wish you lots of luck with your future projects, stay cool and be happy!

Hey folks! We are trying our best to make the most relevant content about functional programming and management in the IT industry. If you have any suggestions on what topics to cover – mention us on Twitter, and we’ll discuss the topic with our engineers.