10x Engineeres and Where to Find Them with Elin Brusberg from Vitec Megler |🎙️#49
How to build your team? How to manage engineers and developers? Can you hire one magical being that can do it all and forget all about it? (Spoiler: No, no you can’t). In episode 49 of DevOps Accents Leo and Pablo talk to Elin Brusberg, Head of Development at Vitec Megler. In this episode:
- 10x developer — what is that?
- Building a functioning team vs. relying on that one guy;
- How to keep your engineers and developers engaged and invested?
- Comfort vs. Challenge: how people are different sometimes;
- Developer and business manager, how to build this relationship?
- How to choose your hiring priorities?
You can listen to episode 49 of DevOps Accents on Spotify, or right now:
The world of tech is known for its rapid evolution and the unique challenges it poses in team management, especially when it comes to engaging and retaining top engineering talent. Recently, industry experts explored key topics around cultivating strong development teams, maintaining engagement, and aligning business and tech perspectives. Here’s a breakdown of the essential insights.
The Myth of the "10x Developer"
The term "10x developer" refers to the concept of a developer who is 10 times more productive than their peers. Originating from a 1968 research paper, this notion has sparked significant debate. The core idea is that a "10x developer" can outperform others in certain ways, such as efficiency or problem-solving speed. However, this concept can often create unrealistic expectations for both developers and managers.
Elin Brusberg, a development leader, argued that focusing on building a single superstar developer can actually undermine a team’s stability and morale. Instead, she highlighted the importance of having a team that collectively achieves impact, as teams reliant on a single "star" developer face critical setbacks if that person leaves. Businesses are better served by fostering balanced teams that can operate effectively even without one specific individual.
A 10-time delivery, is that 10 times the amount of code lines? I hope not. Is it 10 times the amount of functionality? Maybe. Or is it 10 times—and this would be even better—10 times the actual functionality that you actually want in a good, structured, well-maintained code? I mean, there's so many things that you have to think about here, and it's not just being able to just produce stuff, right? It has to be the right stuff at the right time. And maybe just having a good level of decision-making yourself, being able to tell, 'This is what we should focus on now,' you know, do your own prioritizing. Maybe that's what a good developer is. Maybe that's more important than producing something—is producing the right thing at the right time. — Elin Brusberg
Building a Team Over Relying on One Particularly Skilled Developer
Many companies fall into the trap of depending heavily on one particularly skilled developer who knows everything about a specific project. This can create challenges if that person is ever unavailable or decides to move on. Brusberg emphasized that instead of seeking individuals who can handle everything, it’s far more effective to cultivate a collaborative team dynamic where knowledge is shared and tasks are distributed. In her experience, teams that share responsibilities and knowledge are more resilient and deliver more consistent results.
In my mind, looking for one developer that's very good, that's more... it's old-fashioned in a way. It's something we used to do before. We had these crazy people sitting alone somewhere, just producing stuff, but now we're expected to work together. And I think the whole IT industry as a whole has woken up to the fact that we need to have functioning teams; we need to work on, you know, just doing everything right around the people. Yeah, so I think you're right there. I think it's more a matter of looking at team composition. And also, when you say to be able to recruit these people, I think it could be very dangerous to recruit these people as well, for other reasons. One is that they might not be happy about it. I've been trying to recruit a couple of times for new groups, new teams. And then you have this idea, maybe, that you want somebody who can be a team lead, who can be a tech lead, who can deliver and can do everything so that they will be like a one-man team or one-woman team, so to speak. But if you manage to find this person, they will not stay because they don't want to be alone in a team. They want to be surrounded by brilliant people like themselves and learn from them and grow from them. I mean, the curiosity, the know-how, and the social skills that we are looking for need people on their own level. So that's another thing you have to think about. Maybe you should start with somebody who's really bad in a way, just to get it going. You can't start with the top people because the top people might not want to be there. — Elin Brusberg
Keeping Engineers Engaged and Invested
When it comes to long-term engagement, ensuring developers are challenged and valued is essential. Providing variety and choice in tasks can prevent burnout and disengagement. Elin recommended balancing challenging projects with routine tasks to maintain both engagement and productivity. She noted that developers often thrive on tackling new technologies or solving complex problems, so giving team members a chance to work on innovative projects is key to sustaining motivation.
Additionally, offering opportunities for side projects or "innovation days" can allow developers to explore creative ideas outside of their usual scope. This approach helps developers feel fulfilled and keeps them from seeking excitement elsewhere.
People are different. Some people really like the challenge, and they are easy to push. Some people might not want the challenge, and maybe they don't need to be pushed either because, as I said, maybe there's room for people just doing one thing as long as there are other people who do the other things. So it doesn't really have to be a problem, but I can recognize the problem that sometimes, if you don't have any support from the product or the people designing, you know, making the tasks for you, then you could end up with too many boring tasks in a row, so you don't really have any way of making your developers happy. And maybe that's something that you have to think about as a company—that you need to have some fun things just to keep your developers. Because it is hard to find good developers, and an important part of keeping them is to have good tasks. So, you know, I think it's a bit crazy. I don't think I've heard anybody say that before in a way, but I think it could be a good idea to think about that—we need to have some things in our pipeline that are fun. Usually, it's new development, isn't it? I mean, if you ask 10 developers, then at least nine of them will say it's new development and it's new technology. It's also very important for most people. And I'm saying again, you don't have to go crazy. You have to rein this in, in a way, but if you don't do anything that they enjoy doing, then eventually you're going to have a problem. — Elin Brusberg
Comfort vs. Challenge: Understanding Individual Differences
One size does not fit all in team dynamics. Different people have varying preferences for comfort and challenge, and managers should recognize these preferences. Some engineers prefer stability, like working on bug fixes or other "safe" tasks, while others enjoy pushing boundaries with new development. By tailoring tasks to individual preferences, managers can avoid disengagement and turnover. Brusberg explained that understanding what makes each team member tick and offering a mixture of challenging and routine tasks creates a more balanced and satisfied team.
Building the Developer-Business Manager Relationship
A key insight discussed was the relationship between developers and business managers. While it’s crucial for developers to understand the business impact of their work, they also need to feel empowered to make decisions about their tasks. Allowing developers some say in the broader goals helps them feel more connected to the company's success, which, in turn, increases their investment in their work.
Brusberg recommended fostering open communication between developers and business managers to encourage this alignment. Developers who understand how their work contributes to business goals tend to be more motivated and productive.
If you think about it, then maybe as long as the key people have the skill—you know, the people who decide the prioritization—yes, they obviously need to have this. But does everybody need to have it? I don't think they do. And I think that this is a good example of maybe the kind of business acumen that you're looking for—that bit of ruthlessness, that bit of being really into money in general. I mean, I might be really, really terrible now, but I find that if you're that kind of person, then maybe you're not as open-minded, maybe you're not as creative, maybe you're not as... I mean, you're going to lose some other things. You can't have one thing without losing another, you know? And I think that's the... maybe that's also something we need to think about with this 10x developer. If you get all this, what are you losing? What are you not getting? So this whole idea of getting perfect people who can do a perfect job—we just need to forget about it. I mean, it's just not going to happen. And I think... I think that's maybe my takeaway there. — Elin Brusberg
Setting Hiring Priorities: Finding the Right Fit
In tech hiring, it’s common to seek candidates with specific technical expertise. However, Brusberg and our co-hosts discussed how a company’s needs should drive hiring priorities. For example, if a project is short-term and highly specific, focusing on a candidate with the perfect skill set for the job may be ideal. However, for long-term roles, it’s crucial to find candidates who fit the company culture, share team values, and are willing to learn and grow.
Brusberg also emphasized that, for sustained success, the key traits to look for are dedication, adaptability, and a collaborative spirit. Finding candidates who are not only skilled but also willing to help and support their team will create a stronger foundation for long-term growth.
I heard about a company in Japan where the only requirement they had was that they liked cats because they had lots of cats in the office. And yeah, I'm just saying, you don't really know what's important until you try it, right? I don't know if I'm going to make that a requirement just yet, but I do think it's not a bad requirement. I love cats myself. But yeah, I think dedication is a very important word, and I think being helpful is a very important word. I think if you're dedicated and helpful, then most probably we can make it work. — Elin Brusberg
Final Thoughts: Balancing Business Goals with Team Satisfaction
The episode closed with a reflection on how companies should balance business objectives with creating a supportive and engaging workplace. By treating developers as assets that bring diverse strengths and fostering an environment where they feel valued, companies can create high-performing teams. Rather than chasing the elusive "perfect" employee, businesses should focus on developing teams that complement each other’s skills and foster shared success.
This insight-driven approach provides a roadmap for tech leaders to build strong, effective teams and cultivate an engaging environment that drives both employee satisfaction and business results.
Show Notes:
- Our guest, Elin Brusberg, on LinkedIn.
- Vitec Megler is a leading provider of standard software for the real estate business in Norway, making sure they have everything they need to thrive and work efficiently. They are part of the Vitec group, who deliver business critical software for a large variety of niches in Europe.
Podcast editing: Mila Jones, milajonesproduction@gmail.com