Illustrated by Matt Peet

While most every engineering leader entertains dreams of landing that mythical 10x engineer, the truth is that most quality products aren’t built by these fabled engineering unicorns. Instead, leaders are better off optimizing quality teams to do the work. The top-drawer products they tackle are hardly ever static creations—so it makes sense that high-performing engineering teams need to be dynamic in turn.

Building an adaptable team capable of producing the right products is the trick and the responsibility of an engineering leader. Systems architect (and Pluralsight author) Nikola Milanovic is doing just that.

Milanovic has been working in IT for more than a decade—from starting as a software developer at Execom to serving as CTO and Chief R&D Officer at Devtech. Now he’s a systems architect for Symphony and TrueNode. While becoming a software craftsman, Milanovic also diversified his focus to include management and strategic aspects of the tech world. That diversity of experience has shaped his emphasis on creating practical solutions for actual customer problems—which, in his perspective, means building teams that can overcome mistakes and challenges and adapt to new ideas and circumstances.

Milanovic sat down with us to talk about how to build a team that can build the right products, whatever those might look like in a given organization. Here’s his approach.

Before engineering leaders focus on building great products, they need to focus on building great teams. Of course, any engineering team is comprised of individual engineers. But it’s by inspiring those engineers to move as one that leaders can accomplish the unified vision that leads to successful products.

“Usually teams share only the good moments,” Milanovic says. “So if something is successful, a sprint or launch or MVP, then the whole team gets credit. But it also needs to go the other way around. If one member makes a mistake, the entire team needs to help correct it.”

These are Milanovic’s philosophies for creating that team unity through a blameless culture and leading by example.

We all want to assign fault to other people at times. But Milanovic emphasizes that building a high-performing team means not playing the blame game.

“People aren’t making mistakes because they want to make mistakes,” he says. “Everybody would like to do their job perfectly, but mistakes do happen. Try to help them, and try not to point a finger at anybody.”

Milanovic expects that everyone has the intention to do good work. Usually, he can convert these difficult moments from “someone messed up” to “the team and the product are both stronger now”—but only by acknowledging and working with the mistakes.

Engineers aren’t the only ones making mistakes on a team—despite what some leaders might have you believe, they drop the ball just the same. Milanovic admits he makes mistakes daily. He’s learned that the best way to own his mistakes is to address them candidly, with both his team and his clients alike.

“I’m the first one who will openly say, ‘Hey, I made a mistake. I was wrong because of this, this, or this,’” he says. “As a leader it's really important that you are willing to work on yourself, and that you are willing to push yourself to always be better. That doesn't only apply to being good at the technical side of coding. It also applies to being a good team member. I believe that if you are willing to put the effort into your own growth and development, it will benefit not only you but the people around you as well.”

“We are in an industry where you cannot allow yourself not to learn and progress constantly. It’s a paid opportunity to try something new.”]

The ability to accept mistakes, and to take responsibility for them as a team, is foundational to Milanovic’s next insight for building high-performing teams: working in an industry that advances so rapidly and consistently, teams cannot remain any more static than their ever-evolving products. Adaptability is crucial—and not purely in a technological sense.

“Everybody tends to see things from their own point of view,” Milanovic says. “You have your own set of goals and agenda, and you do not necessarily always take into consideration the other pieces of the puzzle. So being on all sides really helped me to try to use other points of view.”

Those different points of view, experienced from different sides of business operations, brought Milanovic to these three perspectives for building adaptable teams.

Milanovic recalls a time not so long ago when managers and companies would put up with a not-so-easygoing personality so long as it was attached to a technically gifted engineer. But he sees the industry shifting away from that approach, and he himself no longer emphasizes technical skills in the hiring process.

“I always put more emphasis on personality traits and on the so-called soft skills,” he says. “It’s easier to learn technical skills, to progress and learn competency, rather than communication skills and other soft skills.”

Instead, Milanovic looks at how potential hires approach solving problems and communicating their thinking. Technical competency is still important—and itself can show how well engineers approach problem-solving and change throughout a career—but technology can be learned. Interpersonal and creative-thinking skills are harder to instill, and they are just as important as technical knowledge to a cohesive, well-performing team.

Product growth often requires technological growth. Leaders of adaptable and flexible teams can present these divergences as chances to learn something new—and because these teams are built with engineers strong in problem solving and creative thinking, they are often game for the challenge.

“We are in an industry where you cannot allow yourself not to learn and progress constantly,” Milanovic says. “It’s a paid opportunity to try something new.”

It’s up to managers and other leaders to strike the balance between technological adaptability and maintaining velocity from sprint to sprint. Engineers might want to learn new things every day—so their leadership needs to decide which new tech makes sense in the moment, and which doesn’t. “It’s not always a good thing for developers to shift from technology to technology,” Milanovic says. “They end up going too wide and not going deep enough. So, a leader needs to have developers’ career interests in mind, too.”

Milanovic’s third insight into building adaptable teams comes from within the team itself. Everyone on his teams has the ability to contribute ideas, regardless of their developer status or tenure. And not just in an “anonymous suggestion box” kind of way—these ideas often make it to the clients’ consideration as an indication of the team’s commitment.

“We try to enable each team member to raise their voice concretely and practically,” Milanovic says. “If anybody has a suggestion that they think should be raised, we organize a meeting with a client where they can present the idea to them.”

Not only does this approach keep a diversity of thought active and thriving within a team, it also earns points with clients and customers. Bringing new ideas to the fore demonstrates to clients that the team is working with them, rather than just for them—which Milanovic experiences as a positive in building that long-term relationship that can last longer than any iteration of the product itself.

By building a foundation of trust within a development team, Milanovic finds that the team becomes immensely capable of building the products they need to build, when they need to build them. And they accomplish this not by being great coders, but by working and adapting together as a team.

“I always like to say that our job, as software developers, isn’t to write code,” he says. “It isn’t to create the best architecture in the world or to write the cleanest code or to write one hundred percent coverage of unit tests. Our job is to solve problems. If the thing that you wrote doesn’t solve a real problem for a person, then it’s useless.”

In Milanovic’s experience, the trademarks of adaptable, high-performing teams are:

·      Teams are as unified in their mistakes as they are in their accomplishments. Mistakes are an inevitable part of creative work, and a blameless culture allows teams to shoulder responsibility for them collectively rather than assigning individual fault. Leaders can set this culture by example when they own up to their own mistakes with both the team and with outside clients.

·      Teams thrive when they are founded in the so-called “soft skills.” Pretty much by definition, developers are able to learn technological skills. But communication, critical thinking, and problem solving are harder to teach—which is why Milanovic seeks out those traits in the hiring process.

·      Teams adapt to new technology—when it makes sense. The benchmarks for the “right product” shift with time, and an adaptable team will shift with them by learning new technology when they need to—within sensible moderation. Engineers need to deepen their expertise as well as broadening it, and leaders can help them strike that balance.

·      Teams welcome input and ideas from all their members. Not every brilliant idea comes from the senior developers. Engineers newer to the team may have valuable perspectives, and sharing these within the team and with clients builds a collaborative atmosphere with diverse thinking.