Perspectives on agility and adaptability in engineering teams

Portraits illustrated by Matt Peet

Recent times, what with a pandemic and all, have required both agility and adaptability from the tech industry in measures possibly unmatched since the dot-com boom (and bust). Yet these features have figured prevalently in the world of software engineering for nearly as long as there has been software engineering. 

Like many buzzwords, agility and adaptability have lost much of another a-word: actionability. Every organization wants to be nimble and flexible, but not every team has the knowledge or the experience to advance them. 

If you’re looking to enhance your response to an evolving organization, these five tech leaders offer insights on how to build a flexible and dynamic team: Scott Lewis, VP of Engineering at APiO; Jonathan Rayback, VP of engineering at Evernym; Heidi Helfand, Director of R&D Excellence at Procore Technologies and author of Dynamic Reteaming: The Art and Wisdom of Changing Teams; Mike Rasmussen, Data Center Site Manager at Facebook; and Nikola Milanovic, solutions architect for Apple.

They each discuss how their strategies for creating adaptability and agility stem from treating engineers like people first, empowering them to shape outcomes, grow organizations and accomplish their visions, whatever the circumstances.

Heidi Helfand had long heard the gold standard for effective team building was continuity. It showed up in readings on agile and scrum. Leadership coaches talked about it. Yet when she assembled a coaching group at a startup company to make teams more effective, she scrapped that philosophy. 

“It would have run counter to helping our company thrive,” she says. “As a company grows and adds people—especially really fast—things need to adjust and change. Leaning into that change is important. Fighting that change is counterproductive.” 

Heidi discerns five distinct reteaming patterns—the structural methods for consciously making teams more adaptable: 

• The One by One pattern: The simplest way to create a new team is to add or remove just one person—even just that smallest of reteaming shifts creates a different team system. 

• The Grow and Split pattern: Teams that were once efficient can outgrow themselves, and leaders can break those teams into faster, sleeker, more specialized units. 

• The Merging pattern: Two or more teams combining into a single unit is often intended to create greater flexibility and knowledge-sharing. 

• The Isolation pattern: Forming a team off to the side and giving them process freedom is good for addressing emergencies and spurring new innovation. 

• The Switching pattern: Developers moving to other teams within the same company extends their lifespans at the company and helps them grow, learn and find fulfillment in their careers. 

Heidi’s research rooted in these five patterns shows that the bulk of reteaming efforts spawn from an intrinsic motivation or need. Some reteaming events, though, are deliberate top-down affairs—and if they have very sound reasons for happening, they can work. 

“They’re not about going in there, reorging these people and moving on without ever talking about how it went,” she says. “Reteaming education for leaders is important, because that’s how we develop a capacity to grow and change—and learn from it.” 

Utilizing feedback loops is key to what she calls humane reteaming. Feedback loops help identify the reasons for change, and what problems teams need to solve. They also demonstrate results. Heidi looks for feedback loops in three places: the people, the workflow and the work itself. 

“If you’re inclusive with the design of your reteaming and you get ideas from people on the ground, you have a greater chance of success,” she says.

Whether teams are being reformed according to Heidi’s reteaming framework or simply adapting the existing team, the software industry advances so rapidly and consistently that teams cannot remain any more static than their ever-evolving products. 

Nikola Milanovic, experienced in different sides of business operations, developed these three strategies for building adaptable teams. 

• Hiring for soft skills makes teams more adaptable: “I always put more emphasis on personality traits and on the so-called soft skills,” Nikola says. “It’s easier to learn technical skills, to progress and learn competency, than communication skills and other soft skills.” 

He 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. 

• Adaptable teams adjust to new technology—when it makes sense: Product growth often requires technological growth. 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,” Nikola says. “They end up going too wide and not going deep enough. So, a leader needs to have developers’ career interests in mind, too.”

Still, Nikola says, “We are in an industry where you cannot allow yourself not to learn and progress constantly.”

Welcome all voices for more ideas and better results.

Everyone on Nikola’s 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,” he says. 

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 Nikola experiences as a positive in building that long-term relationship that can last longer than any iteration of the product itself.

As a veteran engineering leader, Mike Rasmussen understands DevOps as a broader cultural phenomenon. And like other aspects of organizational culture, it can be shifted. He sees how a significant part of DevOps culture is measuring everything to understand if teams are moving in the right direction with efficiency and productivity—but that often leads to teams being stuck in rigid drives to create productivity rather than products. 

“So often companies implement OKRs and don’t have empowered product teams in DevOps,” Mike says. “Thankfully, most teams aren’t just measuring lines of code anymore, but they are continuing to measure output. That completely misaligns the incentives. It reduces alignment and shared responsibility.”

Mike’s solution to creating stronger agility is to value outcomes over output.

Let’s say that a team’s mission is to get a payload across a river. A company expects output-driven results if they provide the team with specifications for the bridge. Design, aesthetics, tolerances. The leaders likely want reports when certain milestones are reached so they can measure a sense of progress. On the other hand, a company allows outcome-driven results if it simply presents the team with the mission: We need to get this payload across that river. How they accomplish that is up to the team.

“Engineers might build a rocket that launches across the river that’s way more effective than a bridge, or they might build a floating bridge that uses less resources,” Mike  explains. “They might tunnel under the river, or they might build a zip line. It ultimately doesn’t matter to the business. They just want to get across the river. And if you save money and resources in doing it, even better.”

]Transitioning from output to outcomes is a mind-shift for many leaders, because stakeholders are so often used to pulling output-based levers. That’s how they feel they add value as leaders.

But the opposite is much more true. Even (or especially) when the going gets tough, leaders need to lean back on DevOps principles and trust and empower their teams to deliver the outcomes they want.

“Most dysfunctions are the result of the leadership, not the teams,” Mike says. “It’s on leadership to model vulnerability and trust. Help yourself out by assuming positive intent. Your teams are not trying to fail. They’re trying to succeed. Hold them to a high standard, and show you expect results by putting the ownership on them.”

The software development industry is already one of the more versatile disciplines on the planet, with organizations taking on all kinds of internal structures and distribution/co-location models. When tough times happen, teams already accustomed to responding to change are more capable of adapting to new circumstances.

This philosophy is highly applicable for global tough times like the COVID-19 pandemic, of course, but any smaller-scale tough time (from company finances to family disasters) calls for some degree of resiliency from an engineering team, too.

Jonathan Rayback and Scott Lewis both offer insights into how creating a little flexibility in a team can go a long way when the going gets rough.

One new idea Scott has is actually an old idea: get back to the core of what his team is and how it functions—even if that looks different in these new post-2020 circumstances.

“We have gone back to basics,” Scott says, “in the sense that we’re not in this high-flying world prior to the COVID slowdown. We have tried to stay lean because we don’t know where this [pandemic] is going. So we decided to work with what we’ve got, to see where things go, and forge new partnerships with financial institutions and distribution channels. We’ve even delayed our Series A so that we don’t get over our skis.”

This opportunity has enabled Scott to examine the practices within Engineering and make sure they’re really working to support the team. Stand-ups are now remote, for example, which is his chance to make sure they’re still adding purpose to the engineers’ week. Grounding the team in its foundational practices has helped them operate at peak efficiency, even as they have taken on a lean and frugal approach.

When everyone is working in an office, it’s easier for leaders to check in with individual engineers, see who’s working on what project and have on-the-fly meetings when the situation calls for it. Going online strains many of the opportunities leaders have taken for granted. Jonathan quickly realized that his organizational structure needed refinements to better serve his team.

“Even though we're technically a flat organization, I've had to develop some people into more leadership roles, because I just can't be aware of everything that's happening all the time,” he says. “So, I've asked a lot of our senior developers to take on a sort of quasi engineering management role without anyone reporting to them. It allows them to get involved in a little project management and decision-making while being the senior person in the room.” 

By being creative with the structure of his team, Jonathan has made room for senior engineers who want to explore leadership responsibilities. But the forced change of a fully distributed team also opens up an entirely new pool of talent when recruiting. 

“In the past, I've only wanted people in one of our cities. Now we have a lot of flexibility to hire anywhere,” Jonathan says.

Communication is key to any successful engineering team, and while in-person is still the best way to forge strong relationships, the pandemic has altered that dynamic for most co-located organizations for the foreseeable future. Jonathan had long felt there was no substitute for being in the same room, but over the past few years real-time digital communication has become more realistic. When COVID created an immediate need, and yet his team’s collaboration continued unabated, his views on the matter shifted. 

“Technology has gotten better and we have things like video conferencing, Slack and a new generation of developers who have come up more comfortable in those types of media. So my attitude has really modulated and come around 180 degrees,” Jonathan says. “Yesterday, we couldn't spell work from home. Today, we are living it and we had to commit to making it happen and just learned as we went."

Because Evernym is global, time zones and team schedules are something that Jonathan and his team have been navigating on the fly.

“For our offshore people, it's required more flexibility. They tend to start their days later now and work a little bit later. I think they are naturally finding it more convenient to be aligned with other members of the team,” Jonathan says.

A remote culture is more than methods of communication; it’s an entire worldview. The pandemic has forced Scott to realize that his team may never return to a brick-and-mortar office. The Engineering team has always been partially distributed. But now that everyone is working from home, he’s realizing the benefits of embracing a remote culture.

“We’re going to start looking for talent that doesn’t necessarily have to be sitting nearby,” Scott says. “And we haven’t figured out those strategies yet. Everyone is going to have to figure out how to draw great people. How are we going to change our perks to be available to people who work remotely? It’s one of the big areas I’m trying to figure out myself.”

When Scott discusses “perks,” he refers to this idea: How can an Engineering organization build a remote culture that works great for everyone—that isn’t a lesser experience for anyone outside a co-located office? The pandemic has allowed him to see for the first time what it’s like to lead an entirely distributed team, and how to do it even better.

“This has given us the ability to see the shortcomings that the remote people were already dealing with,” Scott says. “It’s given us new ideas for how to make it better for the remote people and not just live with the inefficiencies.”

Adaptability and agility aren’t magical coincidences. Leaders must facilitate their emergence and development, which they can do by embracing these strategies and philosophies presented by other tech leaders:

• Reteaming intentionally, because every team and organization will change whether we want it to or not. An awareness of what teams need, and therefore how to help them change, will lead to more powerful outcomes.

• Meaningful actions that leaders can take include hiring for the soft skills that are harder to learn than tech-based knowledge; adjusting to new technology when it makes sense rather than doing so indiscriminately; and opening doors and minds to input from all voices and perspective in an organization to yield more and better ideas. 

• Setting goals for outcomes rather than emphasizing output leads teams to think and perform more creatively. These teams possess a greater freedom of thought and process and thus create more unexpected, versatile solutions. 

• Establishing resiliency and flexibility now will help teams weather the tough times ahead—whether those tough times are global or personal in scope. 

These ideas, distilled to their essence, offer a universal maxim for tech leaders: Take care of your people, and your teams will become as resilient, agile and adaptable.