Software companies often hit hypergrowth, which means developer teams often suffer to manage scaling at the pace of growth and necessary workload. We sat down with Rich Archbold to pick his brain on how they scaled developer teams at Amazon, Facebook and Intercom.
Rich spent quite a few years at Amazon and Amazon Web Services, he worked at Facebook and he has been working at Intercom for over five years. He's currently the Senior Director of Engineering there. Interview by Karolina Toth in episode 3 of the Level-up Engineering podcast.
In the interview, we’ll cover:
I'll start with the classic answer: it depends on the situation.
It depends on whether you're growing a small team; you may be scaling to split a relatively big team into more. When you split a team, or if you go bigger, such as scale the company by adding a new office, the old challenges won’t go away. You just get more scaling challenges on top.
The bottom line is, when you scale a team, you've got to make sure the fundamentals are strong. These are the mission, the vision, the strategy, the values, the culture of the team, and the metrics of success.
When you're looking to scale a team or split it in two, you need to figure out what these are going to be for the new team.
I ask myself these questions:
When you have a mission, vision, strategy, values, and goals, and you weave them all together, it's a story.
A story can align, excite and attract people, and keep them together when times get tough. It'll help them figure out their logo or what the fun things will be about the team. It’s a bunch of the challenges you need to get right but at the team level.
You need to know what your engineering brand is. Are you known for attracting people who are deep technologists or product people?
Maybe you attract young folks early in their career, and they're drawn to the growth opportunity because they know your growth trajectory is like a rocket ship.
Knowing your brand and being able to market it is super important.
Scaling the team usually means adding people into the team. So, you need to hire people, and you need a good hiring system. Both experience and data shows that depending on where you are, hiring can be very competitive, so your engineering and your company need to know who you are.
You need a good interviewing process because it's difficult and competitive to get great people in the door to talk to you. It's an intense and costly process to interview people. You need well-trained people to do the interviews, to make sure not to over-index on technical competencies, and not to under index on attitude and culture competencies.
Make sure your process is not unconsciously biased giving you a poor mix of candidates. Even worse is having a good mix of folks coming in, but your unconscious or conscious bias shows up in your interview process and turns away some of your best potential hires.
To sum it up, make sure you have a mission, a vision, a strategy, values, and metrics, so you can turn them into a story.
Make sure the team has a level of clarity, at least for the first six months, so they can iterate from there.
Know who you are, make sure your brand is authentic, and know how to market it. The last thing is to get your interviews right to convert good candidates into good hires and to do so with a level of diversity.
Scaling your dev team is an action that you take directly following your higher-level company, product, or R&D strategy.
If you don't understand why you're scaling, and how it fits into your overall strategy, the team will have an identity crisis. Being clear on the big picture is hard, but at least figure out the next six months that you're competent about.
Here is what we do:
We review our company strategy every six months. We get all our directors and above together annually to talk through it. We do an open Q&A with our CEO, COO and our chief strategy officer. We give the people who manage the scaling an opportunity to have conversations with the top leaders, so everyone is clear on the strategy, and they can make the best decisions.
Most teams these days are multifunctional. You've got product management, design, research, engineering, analytics, and maybe some ops or some dev-ops folks. You want to make sure when you're scaling a team, you're scaling holistically. Discuss it with the head of design and the head of everything.
Make sure you understand what dependencies are required. You need strong checkpoints with cross-functional counterparts, with the folks in design and in product management in particular. So, make scaling decisions together and not in isolation. We check in on that on a quarterly basis.
Figure out what your brand means to you and your company.
We have a value within engineering we call “represent Intercom with pride.” We make time and space for engineers to write blog posts or to give talks. If anybody pitches a talk at any conference in the world and is accepted, we will pay for their travel. That's part of our DNA and part of our brand.
We do very little contribution to open source, because that's not who we are. We're more a writing and speaking company. When I worked at Facebook, a big part of the brand was contributing to open source. That’s a key part of their brand, and they do a lot with that.
If you want to be world-class, you need to be known for something.
You want to have an opinion, and be confident enough to say, “This is who we are. We know who we are, we think it's cool, and if it resonates with you, come join us.” The right brand attracts the right people and repels the wrong ones. They aren’t bad people; they’re great, but they are not the right people for your company at the time.
We went through a nine-month period where we had some tight deadlines on delivery, so we didn’t put effort into blog posts. I personally hadn't published anything on our main blog at that time. We saw our brand dip and we saw the amount of people applying to work at Intercom dip a bit too.
A hard lesson to learn was that the market doesn’t stay still. We're back to hosting a bunch of events, and we're putting on our own mini-conferences and workshops.
The challenge is having an authentic brand that is unique and putting fuel behind it. We've always known who we are, and we have been comfortable being different in a bunch of ways. It's fine if your company isn't defined by the strength of your engineering work; then, you don't need to hire the very best people. But if you build your brand on the strength of your engineering team, it’s essential.
Getting the right people in your door is key, and you should look to have a documented repeatable, trainable, and scalable interviewing process.
Put weight behind your behavioral interviews. Be clear on what your culture and values are, and interview for those. That's the bar that a bunch of people stop at, and I think that is why you have many software engineering teams that are predominantly white males in their mid-20s and 30s.
You need to commit to having a diverse and inclusive recruiting process. Analyze your job site and job specifications for potentially biased language. Make sure you use an inclusive, inviting, safe, but rigorous interview process. Sometimes that means having a more diverse interview panel. Put your best foot forward.
To do it right, you may need to go to a consultant and say, “We're committed to creating a diverse, inclusive, safe, egalitarian culture because we think it’s right, and it’s what we want to be known for.” Every human has their own innate unconscious bias. You can't ask the most “diverse” person on your team to be your diversity consultant, because it's a skill you need education and experience to master.
I think inclusivity starts with the principles of objectivity, fairness, transparency and usability, so this is what you need in your interview process. Giving the same test to everybody is an objective measure. Making sure the challenge you set is an equal opportunity challenge and relevant to their task is fair.
You can make it transparent if you write a blog post about your interview process and explain the type of things they're required to do, so they know about it up front. Make it accessible and make sure it’s not written in legal language to negate the value of everything you've done before.
A quick plug to one of my favorite management books: The Advantage by Patrick Lencioni. It's the summary of all his other books. He lays out a simple, intuitive, step-by-step framework to help teams understand, clarify and codify their mission, vision, strategy, values, metrics and goals.
I've gone through this book as an exercise with new teams that I've taken over or teams that were trying to form. Doing these exercises usually takes half a day with the team, and it really helps you clarify the story behind the team, and it lights a systematic way about the things you need to do next. It gives you a good starting point to make strong decisions you can commit to for the next six months.
Go through the “what do we value” exercise. Get your team together for a few hours, preferably out of the office to give them perspective, then flush out all the strong opinions you have in the team. What are the lessons we've learned? And what do they tell us about how we make decisions?
This can be a fun exercise, and you can go about it in many different ways. What you're trying to get out of it is the top four or five attitudes, beliefs and behaviors that any new person coming into the team should have. It's always interesting to think about the opposite of these things as well.
It’s such a fun thing to have a team go off site together for half a day just to discuss this. It usually flushes out a bunch of things that people weren't even sure were real values, and it flushes out points of disagreement. You get to know each other better, and you get a chance to air all this stuff. You tend to get a tighter team as a result, and you make better decisions.
I'm a strong believer in hiring for attitude and training for skills, especially in this day and age where talent is scarce and the competition is fierce. It’s easier to find new grads or interns than hiring new senior engineers, and they cost less too. You need to invest into their training, and it will benefit the entire team as well.
One of Intercom’s engineering values is that we run less software. It means that we prefer to use a small set of tools, and we're prescriptive about the languages we let people use and the software we let them bring in.
This is why we want people who are not particular about the technology they use. We want problem solvers, and the main tool they bring is their ability to learn and write software. This is one thing we interview for. We love deep technology experience, but we favor a problem-solver mindset.
We documented in public blog posts how we do our culture contribution interviews. We are explicit about calling it culture contribution as opposed to culture fit, because we always want to be open to more diverse ways of thinking. We use a bunch of mostly behavioral-based interview questions when we ask about past performance.
We document all these questions, and our scoring system as well. We explain what a good answer and a bad answer looks like in our blog post. It’s our version for objective, fair, transparent and usable.
The questions are past-performance-based. We're trying to learn about what you've done, not how you think you might react in an imaginary scenario. We tell you what we're looking for, and why they are key for our company and engineering values, and we let you know how we assess your answers. It's not perfect, it's still somewhat subjective, but you can’t just write a set of unit tests, and see them all pass at the end of it.
Somebody can absolutely get hired if they do poorly on the data modeling interview but do well on the culture contribution interview. We won't make a hire if somebody does well on the tech design interview but poorly on the culture contribution interview. When we think a person has potential, and it's possible they had a bad day on an important interview, we don’t decline them; instead, we talk to them.
A more senior interviewer calls them and says: “We had some concerns, and we don't want to make you an offer that requires you to change to work for us, if that's not the type of person you are. If you think we got it wrong, we'd love to have another interview and to see if it goes differently. What do you think?”
It’s amazing how many people react to being open and transparent. They say things like, “Wow, you're actually treating me like an adult. Thanks for that.” Then you can have an honest discussion about whether that person wants to do another interview.
We all try to put our best foot forward when we go to an interview. As much as we think we're just trying to present our authentic selves, we do kind of tailor our answers to what we think the interviewer wants to hear. I think it's human nature.
That's why you have experienced interviewers, your senior engineers and your HR team be part of your interview process. If somebody will be working on a cross-functional team, you'd have your engineers interview them, but you’d also have product managers and designers be part of the process.
You might say this interview process is too long, there are too many people involved, or we ask too much with tests on top of it all. But we want to be thorough, since it's an expensive job for all involved. An unsuccessful hire hurts everyone in the long run, because you’ll likely end up parting ways at around six to 12 months. It’s not fun.
I would say the biggest one is not putting enough emphasis on hiring for behavior and attitude. It’s the most expensive one too. Understand the team you're hiring for and the balance you need to have in there.
The mistake we made in the past is hiring too many juniors. Unless you've got two seniors to match every eight juniors, you don't have a viable team. I call it guns and bullets. There's no point having a lot of bullets if you don't have any guns to fire them, or the other way around.
Hiring 10 junior engineers can reduce the capacity in your organization, because your best people who were executing at a high rate, now have to mentor juniors. It takes a lot of their time for about six to nine months, and the overall capacity takes a hit. Make sure you understand the balance of strengths in your organization, and you're not just thinking about adding people but strengthening the team.
I think of engineering as part of your differentiating value proposition as a company. You need a great engineering organization for your company to succeed, so you need great engineers. The competition is tough everywhere, so you need to invest into your brand.
You need to know who you are and let others know as well. Otherwise, your people will have six or seven juicier offers with a more compelling story coming from recruiters. As we get more competitive, the bar gets higher for your brand and story.
You need to have a uniqueness around your company and a reason why great people should come and work for you rather than working for Facebook, Google or Amazon. You better be sure they have a compelling brand to offer.
So, the key takeaways you can learn from Rich and Intercom are to be aware of who you are. Make sure you, your team and your company are all clear on the brand, then wear it as a badge, to raise awareness about your company and eventually get the right people onboard. Never lose sight of the overall strategy when managing your team’s inner workings.
Having a thorough hiring process is a must, as is interviewing for the most important qualities, which is attitude, according to Intercom. Be open, honest, inclusive and drop all the bias you can so you get to pick from the best people available.
Once you have all the main points down, you should be well on your way to being able to manage a strong scaling effort, and you’ll have much better chances for success.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.