Engineering Management: An Interview with Rich Archbold

Rich Archbold is the VP of Engineering at Intercom, a customer communications platform. Prior to Intercom, he worked on site reliability and global stock and customer operations as a Senior Manager at Facebook. He also led a large initiative growing a team from the ground up for Amazon in Ireland. Throughout his career, he has seen his responsibility for cultivating employee culture, growth, and excellence as equally important as delivering technological solutions.

For Behind the Code, Archbold shared his thoughts on best practices for engineering management, discussing how to transition from managing engineers to managing other managers, how he organizes his teams to ship code 200 times a day, and how to retain talent.

What’s your best advice for new engineering managers?

Moving from managing yourself to managing others can be daunting. It’s one of those iconic transitions that people go through from being an individual contributor. I think the best bit of advice is don’t march into a new relationship with an employee with the approach of, “This is how I do management,” or, “I read this book and this is how it told me to do management.” Read the books, understand what your preferences are, but then go and build an appropriate and unique relationship with each of the people you manage.

How should new managers go about developing their management style?

[When you’re starting out as a new manager], you’re emulating a style that seems to work for you and you get quite a bit of traction with it. But people need very different styles of management. When I first became a manager, I had one style. I had [an idea of] what worked for me as an engineer and abstracted it out to be a manager, emulating the managers I saw around me who I thought were real role models. I’m quite loud, direct, and candid—I will tell you exactly what I think of you early on in our relationship. Some people love that and some people hate it. [The latter] are much more shy or take time to build a relationship with somebody and don’t appreciate a direct or brash manager. And early in my career, I was like, “This is who I am, this is the style I have. People who thrive under me are people who like that style, and people who don’t thrive under me, that’s their problem or a hiring problem. It’s not a management problem.” And the more senior you become as a manager, the more time you spend in that role, the more you invest in it, you realize that it’s 100% your problem as a manager. It’s not OK to have one style as a manager. It’s not OK to do things by instinct. It doesn’t scale. It’s absolutely not inclusive and doesn’t create an inclusive environment.

And you have to learn and consider, “What am I actually doing? What don’t I do?” For instance, I’m really brash and talk loudly to people, so actually, what I’m doing is giving feedback and sharing context. So the secret is not Rich being brash and loud and talking a lot, the secret is Rich takes time to get context and feedback.

So you go from developing a style, rubric, or set of heuristics that works for you, and you seem to be able to get a good effect from it. You actually don’t have a clue about what you’re doing. Well, I should say, I didn’t have a clue about what I was doing [but] you start to get feedback from people, and that’s where you learn more about the fundamentals and how to assess the styles of the people around you. You just learn to adapt—well, hopefully you do. That is the only scalable way to do it. Otherwise you really are building a clone army to work for you, which is not diverse and certainly not inclusive.

How does your advice translate from managing engineers to managing other managers?

I find that the more junior the people you manage are, the more you can get away with telling them what to do. The more senior a manager, unless they explicitly ask you, they almost never want to be advised. There is this saying I use—”Everybody wants to change, but nobody wants to be changed.” Everybody wants coaching, but nobody wants to be told what to do. So, one of those transition things that you need to do as you go from managing engineers to managing managers is to be prepared to give up even more control.

You need to use the Socratic method to help people. Like, “Hey, it feels like you’ve got a bit of a problem there. Tell me about the top two alternatives you’re evaluating at the moment,” and helping them actually go down the rabbit hole to fully understand the situation. You’ve got to help people learn from their mistakes, rather than prevent people from making mistakes. If I see somebody about to make a mistake, it’s much harder for me to say, “Don’t do that, do this instead.” Rather, I have to say, “What do you think the tradeoffs are between doing A and B? Do you think that’s right? What will you do if it turns out you are wrong?” I have to help them decide if they want to make that choice themselves. Often there is no right or wrong answer.

Intercom is one of the few companies to ship code up to 200 times a day. How have you organized your team to be able to ship at this frequency?

We embrace the philosophy that the safest change is the smallest-possible change. If you’re releasing a change and it has a thousand lines of code, it’s really hard to debug it and go, “Where did that come from?” But if you’re shipping a 20-line change and something breaks, it’s pretty easy to eyeball all 20 lines of code and go, “Oh, it must be that.”

[At Intercom, we have a] continuous, fully automated deployment process that ships 200 times a day and [its] deploy time is 10 minutes or less. Once you create the capability with a small code base to ship that fast, engineers love it. You get this really fast positive feedback loop. Designers and PMs love it, as do our customer support team, because you can ship a fix really quickly and get it out to a customer within the same hour. And once you build this culture, it becomes addictive. And then it’s a battle to keep it, because as you go from one team to two teams, and three teams, you need to organize your code repos to make it modular. You need to invest in your testing infrastructure, because there’s no point in being able to ship untested code to production in six minutes or less because you’re basically just asking for outages. So you need to be able to test the code within that same kind of feedback loop.

We now have a dedicated engineering team whose only job is to make sure we can keep testing and shipping code at that same speed. It’s a testament to the huge amount of innovation and focus that this dedicated engineering team has on making sure that we have a fast and effective continuous deployment infrastructure.

How do your teams retain good talent?

[Our engineering offices] are based in Dublin, London, and San Francisco—all global hubs where the best companies in the world have headquarters. We’re very aware that people could walk out our door and [easily get a job at] Slack, Stripe, Facebook, Google, or the latest startup, so making sure that we have a really strong value proposition for why you should work at Intercom is very important to us. We’re on a mission to create an environment that anybody would be excited to join at any stage of their career. What that looks like for us is creating this really friendly, inclusive, human-centered environment where there are great growth opportunities.

One thing I’m really proud of regarding Intercom’s culture is the rate of progression [for engineers]. Here, we talk about trailing six-month promotions but, really, it’s closer to two- or three-month promotions. We don’t look for eight examples of evidence of competence at a particular level before promoting somebody.

Mobility is encouraged. We have standardization across teams, which enables people to move pretty easily between them. We offer extreme internal mobility because I’d rather you change team at Intercom than move to a different company. I will almost never say no to a [request to do a] training course, and we’ll bring trainers in-house for a group of people, rather than just sending you on an external course. We have a really generous budget for training, so we generally encourage people to either travel to one of our other offices or do a course—keeping your team feeling fulfilled and valued is key.

This interview has been edited for space and clarity.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustrations by Paulo Nunes dos Santos