Scaling Engineering Teams from 5 to 500 and Beyond

 

Every high-growth engineering organization eventually needs to address the challenges around restructuring teams, maintaining a productive culture, building resilient systems, and adjusting engineering processes.

We recently held a live Q&A-style discussion with three tech leaders on the critical lessons they’ve learned and their best practices for keeping teams aligned and productive at scale.

You can watch the entire webinar here, or read on for six highlights from the discussion with Randy Shoup, the VP of Engineering at WeWork; Cornelia Davis, the Sr. Director of Technology at Pivotal; and Saminda Wijegunawardena, the VP of Engineering at Box.

In a conversation moderated by Marcus Blankenship, author of Habits that Harm Your Technical Team, these leaders delved into how the growth challenges of splitting teams is a recurring process; how coding and mentorship can find coexistence on a team; the behaviors that help remote work succeed; the ways that leadership bias can impact how you communicate goals and needs to the team; how an advanced IC track can incentivize the longest-tenured engineers; and how to maintain your hiring standards while improving the process.

The first real growth challenge occurs at around 20 people—and it happens over and over again

Scaling startups are often concerned with the first inflection point of their team size. Many organizations feel that shift at about 20 engineers—but what many don’t realize is that whatever the precise number is, a scaling company will bump up against it over and over again.

“It’s not that you start with five, you’re now challenged at twenty, you grow beyond that, and you’re done,” Davis says. “What happens is, when you get to twenty, you start to break apart into teams. Eventually, each of those teams adds more people, and you hit the twenty-person mark again.”

Davis is a self-described architect. When she breaks apart teams, she always seeks out the architectural seams. Where do you put the contracts in place? Where do you put the APIs? The teams often split in accordance with how the architecture splits.

Shoup loves the duality that Davis describes. “The idea of teams as small units, well-defined areas of responsibility interacting with each other through well-defined interfaces—all those things that we know about good software architecture, they apply just as much, even more so, in a human organization,” he says.

The key, though, is that you have to keep feeling for those seams at scale. “You’re looking for that mark. Is it twenty? Eighteen? Twenty-two? Fifteen? You are continually looking for that number, all the time,” Davis says.

Coding and mentorship can always go hand-in-hand

All the engineers who join a scaling team have a period of steep learning as they get familiar with the product, the culture, the codebase. Many leaders fret over how to balance training and mentoring those new hires, with allowing tenured team members to continue contributing to projects.

Those don’t have to be two distinct efforts that need balancing. “I don’t think they are orthogonal,” Wijegunawardena says. “There are ways to marry those things together.”

When a team tackles a critical project, it’s convenient and tempting to put only the top engineers on it. But those same projects are also opportunities to train the more junior engineers in reality, rather than in the abstract.

“We have one of our very top engineers take a backseat on a certain effort, and give a junior engineer the front seat to lead the project,” Wijegunawardena explains. “The senior engineer is there to support, guide, and make sure the project goes well. The junior engineers learn best not by consultation from a mentor, but by doing the work with a senior person coaching. That builds a culture where engineers always want to see the other people on the team succeed.”

Davis emphasizes that she builds peer programming into her teams for these very reasons, and that all critical components of a project have both people who need mentoring and people who can mentor.

“Mentorship is very explicitly part of the expectations that we have as people become more senior engineers,” Shoup adds.

Remote works well when everyone acts like they’re remote too

“A critical element of having a remote team is that you have to have a culture where everybody behaves as if they’re remote, even if they happen to work at headquarters,” Shoup says.

What does that mean in practice? The panel elaborated that for remote to work well:

• People communicate via the same video and chat mechanisms, whether they are co-located or remote. “It’s more writing and less talking,” Shoup says. “More writing on Google Docs or the equivalent versus going to the whiteboard. We do all our meetings over Zoom or some other video chat.”
• The fun stuff happens the same way as the work stuff. “The people who are co-located tend to do what humans do—they chat, they go out to lunch. And the person who’s remote from that isn’t able to contribute as effectively,” Shoup adds. A team can enable the camaraderie to develop by dedicating channels to that sort of communication—even for the people located in the office.
• Engineers utilize technology for pair programming and other mentorship models. “A few years ago, we had this idea that in order for pairing to really work, you needed to be sitting side by side,” Davis says. “Technology has definitely evolved to make it more inclusive. Those tools that help you do remote pairing have gotten really good.”
• Senior leaders make these practices habits. Whether it’s shifting how you acknowledge speakers in a meeting or changing the platform you use to communicate, Wijegunawardena points out that these shifts have to become habits to gather any efficacy. “It’s most effective when the more senior leaders do it,” he says, “because then other folks model that behavior instinctively. So you go above and beyond not to assume that everybody knows how to involve the remote people.”
• Everyone still gets regular face time, starting with their onboarding. Wijegunawardena stresses the importance of an onboarding experience that includes face-to-face interaction. “They really start to build relationships,” he says. “Because while we can do all these things at scale for remote employees over time, there’s no substitute for that initial interaction in person. Abstraction kills execution, but it also kills empathy.”

Speaking through leadership bias helps create org-wide alignment

As organizations scale, management develops different layers, and the teams grow horizontally, keeping individuals aligned with the company’s goals becomes increasingly challenging simply as a function of size.

“You’re never done communicating the strategy or the mission or the vision,” Wijegunawardena says. “You have to constantly re-communicate it over and over and over again.”

Beyond simply communicating those messages, leaders can improve their efficiency in communicating those strategies by becoming more cognizant of their bias.

“The view of reality at the C-level is shaped by the future,” he explains. “They have access to more information, they know where the company is going, they direct and influence where the company is going. The ICs’ reality is shaped almost always by the past. They’re constantly living in what they experience rather than the promise of a better tomorrow. And middle management is literally in the middle, where they have some view of the past but they don’t have access to all information about the future.”

The role of leadership, whether as executives or middle management, both requires and permits a different perspective on the organization’s course than engineers have. “Be conscious of that when you’re communicating,” Wijegunawardena says. “Senior executives have a lot more data, and they’ve internalized it all for a lot longer period. Getting ICs to internalize the strategy and the pivots through constant re-messaging with attention to that bias helps keep that alignment.”

Again, Wijegunawardena points to the necessity of killing abstraction. Creating empathy and awareness of the challenges that different pockets of the organization experience starts creating organic alignment and helps the organization start to feel like a team going in a unified direction.

An IC track that parallels the management track honors, rewards, and incentivizes the longest-tenured engineers

Imagine, for a moment, that you joined a startup as an engineer when you could count the whole team on one hand. You opted not to pursue management, so now you’re one engineer among dozens, and you’re several levels removed from your original cohort. It’s not outrageous to think you might struggle to maintain the connection you had to the work in those early days.

That relative anonymity is not only a problem for the engineer, but a missed opportunity for the organization to establish its most senior contributors as cultural exemplars equally as valuable as any manager.

“Part of scaling a healthy, sustainable engineering organization is to split out an IC track that has the same levels all the way up as the management track,” Shoup says. “The same compensation, certainly the same respect and the same kind of cultural contribution. The same expectations around leadership, distinguished from people management.”

“I would love to see smaller companies start to think about a program to honor those people who have contributed for such a long time in the past, and continue to do so in the future,” Davis adds. She highlights how larger companies, the IBMs and Intels of the world, have established programs for distinguished engineers and fellows.

“Something that I generally see lacking in smaller companies is this chance for advanced career growth that is non-management,” she says. “Engineers who don’t want to go into management still provide a lot of value. There are ways that you can acknowledge that.”

Hiring practices are strengthened by looking for diversity and character—and by maintaining your standards

At scale, organizations are often not hiring engineers Noah’s Ark style—they’re not looking for two at a time. They are growing faster than that, and they bring new engineers on board more rapidly. Hiring at speed increases the chances of making big mistakes, and our panelists each had their own advice for keeping hiring practices solid.

Hire for character first, competency second. You can develop competency; it’s very hard to change character.”

Saminda Wijegunawardena VP of Engineering at Box

• “Start sourcing in places that are not your major places to source—and source from a diverse pool,” Davis says. “We tend to source from the organizations that we’re the most familiar with, or have the best reputations. But there are many, many other places to source from. Coding boot camps. Historically black colleges. Colleges that are more strongly aligned with encouraging women to go into technology.”
• “One of the other great places to find people is referrals,” Shoup says. “There is nothing we can learn in an interview process that’s as powerful a signal as actually knowing the person.” This strategy also applied to hiring people of various tenures—both entry-level engineers and senior developers can come with references from people they’ve worked with, studied with, and interned for.
• “The thing to watch out for with all the pressure on hiring is not to lower your bar,” Wijegunawardena says. “It is an incredibly competitive market, and with the emphasis on hiring and building products and delivering to the market, you can unconsciously lower your bar in the speed of hiring. We all know the cost of doing that on the team, the culture, the net output, finances. All that stuff is impacted by making a bad hire. I always say, hire for character first, competency second. You can develop competency; it’s very hard to change character. So keep that bar high.”

Summary

Here are six of the main takeaways we gathered from Wijegunawardena, Davis, and Shoup in this webinar:

• Organizations reach their first significant growth challenges in the neighborhood of 20 people, and then they continue encountering that threshold each time a team reaches that size.
• Coding and mentorship are not mutually exclusive activities, and in fact, they can both mesh into the routine practices of an engineering team.
• Remote workers on an engineering team can contribute most meaningfully when everyone on the team adopts remote practices.
• Leaders have their own bias that reveals itself in communication—and becoming aware of this bias helps them communicate goals and needs to the team more clearly.
• Designing an IC track that parallels the management track keeps the longest-tenured engineers incentivized, recognized, and respected.
• An organization can learn to hire for character and diversity, all while maintaining its high standards for new team members.

Thanks again to our panelists, Cornelia Davis, the Senior Director of Technology at Pivotal, Saminda Wijegunawardena, the Vice President of Engineering at Box; and Randy Shoup, the VP of Engineering at WeWork, as well as Marcus Blankenship for moderating the enlightening discussion.