The Engineering manager position has been in place at Sudolabs for some time. Could you describe how you see your position and what it entails?

It’s all about working with the engineers you've been assigned. Assessing the level of their soft and hard skills and finding out how to use those effectively is an important part of the process. And also help them to develop in the right direction, in order to get them where they need to be, at a steady pace.

How many people are you currently managing?

At the moment, I am working with 10 people, but that number may increase as time goes on.

What is a typical work day like for you?

Last year, I worked predominantly on the Vareto project, serving not only as an engineering manager but also as a tech lead. However, my colleague has since taken over that role, so nowadays I interact with Vareto only to a small extent.

The above-mentioned project occupied a large portion of my day, and it wasn't just about catching up with the people involved, but also about looking after the project as a whole. My goal was to ensure that the team’s work and cooperation with Vareto goes well and that it will continue to be that way without my involvement.

But currently, my time is mostly dedicated to my engineering manager tasks, career ladder, 1-on-1s, hiring, and improving the processes of it all.

You put your own hands-on creating the career ladder, right?

I’m helping to create the career ladder design in general, evaluating and testing it, and I also came up with some examples for our objectives. But the ladder is overwhelmingly Pavol’s achievement (Pavol Madar, CTO). We are currently looking for the right user interface to use it with and most importantly, we’re constantly encouraging people to go through it and look for examples of their work that fit the career ladder objectives.

How do we set up learning in the company, how do the devs pick learning days, and what topics do they choose to study?

Devs have tremendous freedom within their 20 learning days as long as it's relevant to their work. In most cases, they make the choice themselves.

Among my direct reports, I introduced a learning calendar so they could choose a day mostly to dedicate to learning. If someone picks a date in advance, we can assume that they won't be available for their normal work at all, or maybe for a short time.

Using a calendar has two benefits:

Each team member knows about the other's learning days in advance, so their colleagues can plan accordingly - a consistent output is expected, so this is important. During some weeks, there might be a holiday, someone may take a day off, and someone might wish to have a learning day at the same time. Now they need to assess whether it is the right move. It can affect the team's output in a way that doesn't suit them. Learning can always be rescheduled, as long as they actually do it. And secondly, I can see what they’re learning.

The topics may be relevant to what we're currently dealing with, or to the company’s stack. It can also be something that complements your general knowledge, such as learning another programming language. More senior people or those who have been working here a bit longer sometimes do this. As of yet, I haven't seen a topic I wouldn't approve of.

Junior devs, of course, require suggestions on what they can improve or what would be beneficial to them. Weak spots can either be determined by self-evaluation during their 1-on-1 or by feedback from other team members and their tech leads. Since Sudolabs subscribes to many different online courses, finding quality sources of topics to learn is generally easy.

After taking a course, do team members share their knowledge, or does it remain more personal?

As of now, it's very individual, but we are working to improve our internal knowledge sharing. In any case, I'm always curious about what people have learned since our last 1-on-1. I ask about the topic, what they liked about it, and perhaps what was unclear to them. But this is rarely a problem, the courses are well done and the topics are straightforward.

From what you said I understand it's not really an easy position. Could tell me what is the most challenging part of it?

It’s definitely the prioritization of time. Whether you are helping your reports, the company, or improving an internal process, there are many things you can and should do. At the same time, a position like this simply cannot be scaled to too many reports, as they all deserve to have their 1-on-1 time.

How do you ensure that people move forward? In what way do devs receive feedback and subsequent salary reviews?

Practice is the main method of moving people forward. Though the theory is important, repetition is the key to success.

To me, involving people in doing things they haven't done before is crucial. Initially, it might not go well, but when they run into trouble, they always know who to reach out to: their colleagues, their tech leads, or myself. To some extent, allowing them to attempt to solve something, again and again, is necessary if they cannot figure it out.

In terms of feedback, we’re using these three ways:

There is the "immediate" feedback, where we praise something as soon as it occurs. If something unpleasant happens, we offer constructive criticism, which is confidential about 99% of the time - only the person concerned knows about it. Teams should always strive to praise each other publicly, so everyone knows when a great achievement happened. This takes place on Slack, in meetings, or during retrospectives.

Another one is the 360 feedback, which is private. We gather feedback from the reports’ colleagues, tech leads, or product managers. All of them are discussed constructively. When something bad happens, we seek to never create negative energy, and all of it is handled in a friendly manner.

We haven’t yet fully launched this initiative, but the performance review will become our third type of feedback. As part of the evaluation, developer skills are assessed according to their position within the career ladder. The position determines our compensation. The only thing that matters is whether the person has progressed in their career ladder objectives since their last performance review.

Outside your team, how do you participate in the direction of the company and the engineering lab?

At Sudolabs, everyone has a chance to affect the direction the company takes. Although our core values are already established, anyone can suggest improvements. For myself, time is a major limitation. Ideas and suggestions are easy to come up with, but implementing them is the tough part.

Some time ago, we streamlined our decision-making process using the “7 levels of delegation”. For instance, we have an Engineering Management working group to discuss and agree on all engineering-related issues. As a part of this, we hold weekly sync meetings during which we present new suggestions, examine progress on current tasks, and also discuss our 1-on-1 experiences.

3 top qualities and skills of an engineering manager?

That's a tough one. For myself, as well as others within Sudolabs, this position is quite new, and I still feel I lack the experience to comment.

But perhaps the most crucial aspect is to go beyond a purely work-based connection and cultivate relationships. Working with people in this capacity requires more than just being colleagues. So if that's a skill, I would consider it an important one.

Second, you need to be able to identify strengths and weaknesses. It's up to the engineering manager to identify the strengths and weaknesses and work with them accordingly - making the most of strengths and improving weaknesses. There are both introverts and extroverts among us. Some communicate early and often, then there are the silent types. Some have a better feel for technical solutions, others are better at testing things.

Lastly, you have to pick your battles wisely, because you have a limited amount of time and several people depend on you.

The Engineering Position is fairly new to Sudolabs. What created the need for the position?

The company is doing well, and because of the growth, we are able to hire more people. As a result, Sudolabs needs more engineering managers to help lead people and help them achieve our quality standards.

It's usually not necessary to manage these people; you mostly need to know their skills level, what experience they have, and how to cultivate it. It would be really hard for one person to accomplish this task by leading 20-30 people at a time. The amount of attention you can devote to something is limited. And to be honest, these days we still have a shortage of engineering managers.

The best ways to ensure that an engineering team remains motivated?

Ultimately, they must enjoy their work and find it fulfilling. It is true that developer jobs are well paid, but many people are drawn to engineering for their intrinsic rewards. They have found themselves in a field that they already enjoy and this needs to last.

But often, parts of this job aren't something you'd like to do, and we're trying to reduce these challenges or at least make them easier to handle. Their work should be an interesting experience, not a chore. Generally, they prefer moving horizontally (to other skills and projects) or vertically (to get better) rather than staying in the same place too long and that's something to keep in mind.