As I look back on my time at TripAdvisor and HelloShopper, and think about conversations I’ve had with various startups, one of the recurring themes has involved building and managing engineering organizations, particularly during rapid growth phases. From five to fifteen, to twenty five, to seventy five, to a hundred fifty, and so on. Each of these ramps poses its own challenges, including recruiting, onboarding, process improvements, manager development, and increased stratification. How do you manage this effectively?

Recruiting

I’ve spilled a lot of virtual ink talking about recruiting, and I’m not going to try to reproduce it all here, but rapid growth is a whole mess of opportunities grafted onto a punishing interview schedule. Before you go off and talk to the same recruiters, scan the same resumes, ask the same questions, and follow the same ad hoc process you used to get to where you are, take a minute and evaluate what kind of team you’re really trying to build. What skills does your organization lack, what are your blindspots? If you’re heavy on backend engineers, your Javascript and CSS framework is almost certainly archaic[1]. If you’re heavy on front-end specialists, your backend, database, and operational infrastructure are probably lacking. As I’ve written previously, there’s great value in building heterogeneous teams – having engineers with different strengths means that everyone can take ownership of a different part of the code, and mentor the rest of the team in their area of expertise. Important areas of the code don’t get neglected due to missing skill sets and a universal expert beginner mindset. And, of course, it’s easier to find and hire quickly when you can source from different communities.

This is also a huge opportunity to address your team’s lack of ethnic and gender diversity. As I’ve mentioned before, this isn’t only a matter of doing the right thing (which it is, and you should), but also about building the most effective team possible. You care about that, right?

The promise of diversity is borne out in study after study that shows increased success and profits when companies and teams are diverse.
– VentureBeat, Is your startup diverse enough? (h/t @thelist)

There’s little correlation between a group’s collective intelligence and the IQs of its individual members. But if a group includes more women, its collective intelligence rises.
– Harvard Business Review, Defend Your Research: What Makes a Team Smarter? More Women

This will also help you reach your hiring goals – your existing sourcing methods will get you white dudes, but making a point of seeking out women and under-represented minorities will increase your total pool of applicants. And hiring a diverse team will create a feedback loop that will help you hire more women and URMs in the future. Don’t know how to get started? Luckily, plenty of resources are available.

During a rapid growth phase, there’s going to be a bit of an industrial aspect to your recruiting process. There’s never going to be a better time to set up your assembly line, train your interviewers, and standardize your process. There will always be some degree of randomness to interviews, but to the extent possible, your goal has to be to create an objective process that minimizes individual interviewer differences, reduces bias, removes artifacts that are unrelated to future job success, gets you to an accurate answer, and closes candidates. Work with your interview team to come up with a set of standard questions, set up dev environments on a couple of laptops (bonus points for doing it in vagrant so you can standardize and do quick resets), put together unit tests to prove correctness, and get rid of the whiteboard. Invest in a tool to track candidates, manage written evaluations, and keep decision-making and candidate communication on track. And finally, train and track your interviewers. Teach them what questions can’t be asked, and give them training to recognize and overcome biases. You’re going to be generating a huge amount of data as you interview k*(number of slots) candidates (where k is often depressingly high). Which of your interviewers are tougher, which easier? Which demonstrate a statistically significant bias? A year later, who was best/worst at picking candidates who did well on the job?

Lastly, recruiting is time-consuming, and there needs to be a common understanding among all stakeholders that engineering capacity is going to be reduced during this period. This absolutely needs to be communicated up-front. Interviews need to be scheduled along with engineering tasks, with the understanding that some interviews go long, emergencies pop up, and last-minute shuffling has to be accommodated. It’s important for your team to understand that interviewing is a critical part of their job, that they won’t be penalized for interviewing instead of coding, and that being a reliable, objective, friendly, effective interviewer is a requirement for success as they move up the ladder.

Onboarding

Starting a new job is hard, and more so when everyone around you is also trying to get up to speed, fit in, stand out, and avoid breaking something important. When your organization is doubling or tripling in size, you need to make an outsized effort to onboard new engineers with a couple of priorities in mind. First, to educate them on company values and culture. Next, to bring them up to speed on the code base, tools, and processes. And lastly, to make them feel special (because even if you start thinking about them as numbers getting you closer to a hiring goal – an understandable but unhelpful attitude – each of them rightfully expects to be treated as an individual whom you were lucky to close).

So, on values: what are they? How do you live them? Have they been thought through, written down, and communicated throughout the organization? If asked, would everyone agree on what they are? Do they match your company’s reality? This isn’t a post on defining and living up to your stated values, but it’s worth understanding two fundamental facts. First, that unless you explicitly communicate your company’s values to new employees, they’ll muddle along using their last company’s values until they can divine yours on their own. In some cases this is ok – honesty, integrity, etc., should be common across all healthy companies. In some cases it isn’t – if, for instance, your company values speed of delivery and they come from a quality-first environment, they’ll be frustrated and viewed as underperforming in the critical initial period when first impressions are formed. Second, if your explicitly stated values differ from how the system actually works (e.g. if you state that “done is better than perfect,” then punish people for shipping minor bugs), they’ll figure this out pretty quickly, which will breed cynicism and lack of trust.

In some ways, culture is both easier, and harder, to impart than values. Easier, since it’s baked into the floor plan, seating arrangement, perks, equipment, team makeup, meeting schedule, processes, email, and interpersonal interactions. Harder because it encodes a thousand things you no longer see, including some you actively resist seeing. If it’s ok to arrive late to meetings. How quickly code reviews get done, and by whom. Whether the organization uses Scrum, Scrum Light[2], or nothing much at all. Whether methodologies are centrally mandated, rigorously applied, or left up to the teams to decide for themselves. Whether people go out to lunch together. Whether company functions center around alcohol. If swearing is common. How charges of sexual harassment are handled. If important company events are welcome/hostile to particular groups (women, LGBTQ, URMs, parents). Does your company proactively send engineers to industry conferences, or does it force them to use vacation days if they go on their own? And speaking of vacation, if you have unlimited PTO, what does that actually mean in practice? Culture is all the details about working at your company that everyone understands without discussion, and which can be hard (or embarrassing) to enumerate.

Some culture is positive, some neutral, and some actively toxic. As leaders, you have to constantly reinforce the positive aspects and root out and exterminate the negative. Though you can introduce new hires to values and processes in a structured way, acculturation is mostly accomplished by putting them into existing teams and letting them adjust to the environment over time. This can be challenging during a period of rapid growth, when acquiring a team wholesale, or when opening a new office, because the new hires can overwhelm the existing team, imposing their alien culture onto you instead of the other way around. Most difficult is when the manager is also new, trying to navigate a new organization, hierarchy, and team, falling back on old patterns to get through the tough initial period. So, to the extent to which you can manage it, it’s best to add people to teams a little at a time, and to grow managers internally, or to give them pre-existing teams that already know how things are done. As for acquisitions, splitting them between existing teams – at least initially – is most likely to give them the best chance to successfully navigate their new environment.

It’s common to introduce new hires to a codebase and toolset by giving them some minimal instruction, mediocre documentation, and a minor project to “bring them up to speed.” This is a huge, demoralizing waste of time. It’s much, much more efficient and humane to spend some calories creating correct, clear documentation, developing new hire training, and having experienced engineers pair program with new engineers for their first projects. You effectively leverage an up-front O(1) cost into an O(n) ROI, with the added benefit of creating a culture of asking questions and collaboration. At TripAdvisor (which certainly wasn’t a paragon in many respects), we used to have all new engineers and interns read through Effective Java as part of cross-team reading groups. This helped integrate new hires socially, made sure everyone had a common technical point of reference, and normalized the idea of using reading groups for continuous development.

Lastly, there are little things you can do to help new hires feel special. Make sure their equipment is at their desk when they arrive, with instructions for getting onto the network. Make a point of introducing them around. Take them to lunch their first day. Give them a “buddy” or “mentor”. Have a 1:1 with them their first day, and discuss concrete requirements and objectives. Follow up on a weekly basis. Tell them you’re excited to have them. None of this is rocket science, but unless you plan for it, a new hire can easily get dumped in a cubicle, handed a task, and forgotten.

Managers and Stratification

When I first joined TripAdvisor, I was one of twenty individual contributors reporting to a Director of Engineering, who in turn reported to the VPE. As her organization grew, the Director divided it into multiple teams, each with its own manager. New teams were created or spun off, new managers hired and promoted, the VPE became Senior VPE, the Director a VPE, managers turned into Directors, and soon there were senior managers, senior directors, team leads, and so on. People love to sing the praises of a flat org chart, but these are usually sung loudest after the old structure is long obsolete, stretched to the breaking point, and in the process of being radically altered or thrown away.

When your organization’s in a period of rapid growth, the old teams expand until they’re unwieldy and their managers are stretched too thin. This is a natural point at which to break teams into smaller, more manageable units, and assign each a team lead or manager, depending on size and resources. At which point, of course, you’ll have managers managing managers, which you’ll probably want to call “senior managers” or “directors.” And suddenly, without having planned it, you’ll have a hierarchy that’s five levels deep. Which is fine – really. People think they care about hierarchy depth, but they don’t – it’s more that it’s a convenient proxy for concerns about access, status, fairness, communication, and trust. None of these needs to go away, but it’s worth facing the concerns proactively, having a conversation about why the teams are being broken up, and what it means for the people on those teams and the organization as a whole. Overall, it should be a positive message – the company is growing because it’s successful, and growing, successful companies have lots of opportunities for career growth and upward mobility.

The next obvious problem is that you’re going to need to start finding or growing new leads and managers. Hiring managers is hard, and your first round should generally be from internal candidates who have the interest and skills to grow into the role. This gives both you and them a chance to try before you buy. Mentoring an individual contributor into a manager role has a number of discrete pieces, which I’ve discussed in a fair amount of detail here. Ongoing mentoring also has to be taken seriously. In addition to the weekly 1:1, some things which have worked well for me are manager reading groups, cross-functional manager lunches, bringing in consultants to do 360 reviews, discussing management challenges you’ve faced (or are facing), and providing a backstop during crises. A lot of the time, the best thing you can do is to be your managers’ debug duck.

Last, there’s the issue of engineer title. There are good reasons to have titles, and good reasons to avoid them, but as an organization grows it’s hard to attract talent, reward individual contributors, have fair salary bands, and specify seniority-dependent job requirements without having some kind of explicit ladder. Camille Fournier at Rent the Runway made her ladder public a while back – if nothing else, it’s a good place to start as you think through what would work for your org.

Process Improvements

It’s impossible for processes to stay the same as a company grows. Approaches that work for a five person team frequently don’t scale well to 25 (or 100), and small annoyances and inefficiencies that weren’t prioritized when the team was small have a bigger negative impact as the team balloons with inexperienced new hires.

Everyone on your startup team probably had access to everything, but at some point you have to start restricting access to critical resources (servers, databases, payment gateways, online services, etc.). Standards and processes around branching, code reviews, staging, and releases need to be made explicit and enforced, through tooling, documentation, and culture.

Speaking of which, documentation also needs a fair bit of love as the team grows. As noted above, dev environment setup is an area that can benefit tremendously from up-to-date, correct documentation – or better yet, a script that takes care of all the details. Useful but obscure tools tend not to get communicated to new hires consistently, which can lead to confusion, lost time, and reproduction of work. It’s worthwhile to invest in a centralized document repository, and to spend some time organizing and keeping it up to date.

Furthermore, as teams proliferate, they specialize, sometimes choosing new tools and languages, and it becomes harder for people to understand each other’s code and tooling. You can’t expect everyone to have a full mental model of the code base in their heads, and team-specific onboarding and documentation become more important.

Hire quality during a high growth phase will be more variable, and try though you might, there will be some regression to the mean. Build breakages and bug counts will increase supra-linearly, and you’ll have to make decisions about how to get this under control. Switch to TDD? Enhance your commit tooling to first compile, lint, and run unit tests? It’s easy to slow down by adding well-intentioned but ultimately useless process to guard against one-off problems, instead of dealing with underlying structural problems (or recognizing that something was a fluke, and deciding that the time spent guarding against it would be far more costly than the likelihood of it happening again).

The communal responsibility anti-pattern is a real thing, and it’s worth spending a fair amount of energy to root it out early. Likewise, communication patterns also need to change. That Slack party line needs to be broken up, and there need to be more formal rules around what’s appropriate for the “all@” email alias. It’s common for a “spam” email alias / Slack channel to get created at some point to offload non-work-related traffic, and just as common for it to spin out of control with political rants, flame wars, microaggressions, and harassment. Whether it’s light-hearted and fun[3], or a toxic cesspool of HR liability, take note – like it or not, this is an important vector for communicating culture and values to your new hires.

Conclusion

This may all seem like a lot, and it is. Hiring well is hard, hiring a lot of top people quickly is harder, and it’s common to focus on that to the exclusion of all else. A little bit of forethought goes a long way, though, and you can significantly improve outcomes for the incoming wave by planning for some of the most common challenges up front.

---

[1] 

[2] Defined by one wag as “calling milestones ‘sprints’ and buying a Jira license.”

[3] The only flame war I remember at TripAdvisor – requiring CEO intervention – was caused by a someone sending a photo of a double rainbow to the off-topic email alias, some “great pic!” replies, complaints that this was filling people’s inboxes up with distracting crap, and a big public fight over what constituted appropriate “off-topic email.” You just never know what’s going to set people off.