How engineering leaders at Apple, Facebook, and more create adaptable teams

Not since the dot-com boom (and bust) has the tech industry required such agility and adaptability – two words that have been cornerstones of the software engineering world since its inception.

Yet, like many buzzwords, agility and adaptability have lost much of their impact. It is important to consider another word: actionability. Every organization wants to be nimble and flexible, but not every team has the knowledge or the experience to achieve this.

These five tech leaders offer insights on how to build a flexible and dynamic team: Scott Lewis, Vice President of Engineering at APiO; Jonathan Rayback, Vice President 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 at Apple.

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

Re-organize your team with purpose

Heidi Helfand had often been told that 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 entirely.

‘It would have run counter to helping our company thrive,’ she says. ‘As a company grows and adds people – especially when this is done quickly – things need to adjust and change. Leaning into that change is important. Fighting that change is counterproductive.’

Heidi discerns five distinct reteaming patterns, which are 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 the smallest reteaming shift can create a different dynamic. 
• The Grow and Split pattern: teams that were once efficient can outgrow themselves. Leaders can break these teams into faster, sleeker, more specialized units. 
• The Merging pattern: combining two or more teams into a single unit can often create greater flexibility and knowledge-sharing. 
• The Isolation pattern: forming a remote team and allowing them process freedom is good for addressing emergencies and sparking new innovation. 
• The Switching pattern: moving developers to other teams extends their lifespans at the company and helps them grow, learn and find fulfillment in their careers.

Rooted in these five patterns, Heidi’s research shows that the bulk of reteaming efforts spawn from an intrinsic motivation or need. ‘It’s not about going in there, reorganizing 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 the 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.

Grow an adaptable team

The software industry advances so rapidly 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 the so-called soft skills,’ Nikola says. ‘It’s easier to learn technical competency than communication and other soft skills.’

He looks at how potential hires approach problems and communication. Technical competency is still important – and it 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.

Many engineers want to learn new things every day, so it is also a leader’s responsibility to decide which new tech is a priority. ‘It’s not always a good thing for developers to shift from one thing to another,’ Nikola says. ‘They end up going too wide and not going deep enough. So, a leader also needs to have developer’s career interests in mind.’

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 status or tenure. And not just in an ‘anonymous suggestion box’ kind of way – these ideas are often put in front of the client to demonstrate 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 diversity of thought active and thriving within a team, but it also earns points with clients and customers. Bringing new ideas to the fore demonstrates to a client that the team is working with them, rather than just for them. This helps to build a long-term relationship that can last longer than any iteration of the product itself.

Value outcome over output for versatility

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 recognizes that a  significant part of DevOps culture is measuring everything to understand if teams are moving in the right direction with efficiency and productivity. This can, however, lead to teams being stuck in rigid drives to create productivity rather than products.

‘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.’

Mike’s solution for 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 fewer 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 outcome is a mind-shift for many leaders because stakeholders are often accustomed to actioning outputs. That’s how they feel they add value as leaders.

Doing the opposite, however, is much more effective… Even (or especially) when the going gets tough, leaders need to lean back on DevOps principles and trust 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 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.’

Weather the storm by building resilience and flexibility

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

This philosophy is highly applicable for global events like the Covid-19 pandemic, of course, but small-scale events (from company finances to family disasters) also call for some degree of resiliency from an engineering team.

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

Bolster the basics

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 a post-covid world.

‘We have gone back to basics,’ Scott says, in the sense that we’re not in this high-flying world anymore. We have tried to stay lean because we don’t know where this [pandemic] is going. We decided to work with what we’ve got, to see where things go, and forge new partnerships with financial institutions and distribution channels. 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.

Reconsider the organizational structure

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

‘Even though we’re technically a flat organization, I’ve had to place some people in leadership roles, because I just can’t be aware of everything that’s happening all the time,’ he says. ‘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.

Normalize digital collaboration

Communication is key to any successful engineering team and the pandemic has irreversibly altered how people interact with one another. Jonathan had long believed there was no substitute for being in the same room, but now his views have shifted.

‘Technology has improved and we now have video conferencing, Slack, and a new generation of developers who are more comfortable using this media. So my attitude to remote working has completely changed’ Jonathan says. ‘Yesterday, there was no ‘work from home’. Today, we are living it and we have had to commit to making it happen.’ 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 employees, it has required more flexibility. They now tend to start and finish later. I think they are naturally finding it more convenient to be aligned with other members of the team,’ Jonathan says.

Strengthen remote culture for everyone

A remote culture is more than methods of communication; it’s an entire worldview. Scott realizes that his team may never return to a brick-and-mortar office and he’s embracing the benefits of a remote culture.

‘We now have the flexibility to hire anywhere,’ Scott says. ‘We haven’t worked out those strategies yet but everyone needs to figure out how to draw great people. How are we going to change our perks to appeal to people working 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 well for everyone, which 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 better.

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

Final thoughts

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 perspectives 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 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 resilient, agile, and adaptable.