 |
 |
 |
Scaling Developer Teams: Know-How From Amazon, Facebook and Intercom - Interview with Rich Archbold
Software companies often grow quickly, 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.
In the interview, we’ll cover:
What are the biggest challenges when scaling a software development team?
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.
You will need strong fundamentals for scaling developer teams
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:
- “Can I paint a compelling picture of what the first six months of delivery are going to look like?”
- “What are the first six months’ worth of goals for the new team?”
- “Can I tell a story around what the new team is going to work on?”
Learn the ins and outs of Monzo's renowned engineering culture! [Podcast + Blog post]
Creating a story
When you have a mission, vision, strategy, values, and goals, and you weave them all together, it's a story.
Learn how to create your own company culture document from this case study! (Podcast + Blog post)
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 an employer brand
You need to know what your engineering employer 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.
Get hiring right
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.
👉 Learn about Asana's developer recruitment process from this interview! [Podcast + Blog post]
Avoid any bias
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.
Source: business.linkedin.com
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.
📗 Check out the State of Software Development 2019 Survey for more specific data!
What have you done to overcome these challenges?
Scale in sync with company strategy
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.
Scale holistically, be aware of dependencies
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.
👉 Training Engineering Managers: This Is The Way to Keep Growing [Podcast + Blog post]
Figure out what your values are worth
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.
- You need to have a discussion with your engineering leaders and ask questions like:
- “What is your brand?”
- “What does it mean to you to be true and authentic to your brand?”
- “What do you want to be known for?”
- “Are you willing to have ten less features a year in exchange for fifteen blog posts?
- “Are you willing to use some of your budget for conference attendance?
- “Are you willing to make hard trade-offs?”
Be comfortable with who you are
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.
Improve your hiring process
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.
Make sure you’re inclusive
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.
What is the first step if someone needs to scale their developer team?
Be methodical about it
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.
Work out your values
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.
Hire for attitude
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.
The way of Intercom
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.
How do you remain objective if you hire for attitude?
Make an objective, fair, transparent and usable process
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.
- “Give me an example of a time when you had to go beyond what a customer had initially asked in order to solve a problem.”
- “Tell me about a project you delivered within the last two years that you are most proud of.”
- “Why are you the proudest of this project?”
- “Give me an example of a project that pushed you past your comfort zone, and how did you react to it?”
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.
Hiring at Intercom
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.
Don't people want to land a job so much, they just act as you expect them to?
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.
Let your most experienced team members evaluate applicants
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.
A thorough interview process pays off
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.
What are some of the mistakes you would warn against when scaling?
Hiring for hard skills alone
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.
Weak brand
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.
Conclusion
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.
What You Should Do Now
👉 If you are serious about becoming a great engineering manager, you should subscribe to our newsletter or download the state of software development 2020 report.
🚀 If you need developer help for your project then click here for a FREE consultation.
About the author:
Karolina Toth has been working with engineering managers for over 5 years. She is an internal coach, working on the most pressing management-related issues tech companies face. She is the host of the Level-up Engineering Management podcast where she talks with accomplished tech leaders of fast-growing tech companies.