4 ways Intercom is improving developer productivity

If it’s long been known that happy developers are more productive, what if, as an industry, we focused more on developer joy as a tactic to deliver better products faster? That’s the hypothesis that Iain Breen, a senior engineering manager in the customer service platform Intercom’s infrastructure services group, and his team of four have been working to prove over the last year — both to the company’s 300 engineers and to its more than 25,000 customers.

“We want Intercom to be the world-renowned great place to be in engineering. We want it to feel when you’re here that you can do some of the best work for your career, that the tools are working in your favor and not stopping you from achieving your goals,” Breen told The New Stack. “And this ultimately makes Intercom attractive for our customers because they can see how quickly we can iterate and ship changes.”

In 2024, focusing on developer satisfaction sounds like more of a radical idea than it should. Of course, Intercom has been built over the last 12 years on an ethos of speed to ship and ship to learn. Let’s explore how Breen’s team reduces developer toil on top of a monolith while maintaining incredibly high standards and an inherent need for speed.

The developer productivity shift at Intercom

Over the last four years, Breen has been working across this area of developer productivity inside of engineering.

“It’s existed in different ways, and shapes and forms,” Breen said, “but it’s always been around using our platform in infrastructure to help our engineers ship code faster and better and safer, and ultimately benefit our customers.”

Intercom is famous for being a super-elite engineering organization, as measured by standards such as the DORA metrics, with deployment thresholds of tenths of seconds. It’s in the customer service tool’s DNA, Breen said, to be “ruthlessly efficient, like getting toil and roadblocks out of an engineer’s path, because we want them to make good products for our customers.”

Intercom’s customer base, he explained, ranges from the classic mom-and-pop shop that just wants to talk to its customers all the way up to enterprises that have complex, integrated communications with real-time data-driven decision-making, which means customers range from the very low tech all the way up to other engineers.

Once dubbed the engineering velocity program, Intercom has tried various iterations of toil-reduction strategies. For a while, it had a velocity risk register where teams would record anything that was slowing them down. Common responses ranged from technical debt and service integration to documentation to new developer onboarding — anything that prevented the engineering organization from moving fast. Then, the idea was that teams would, sometimes, prioritize fixing those impediments.

“What we found in using a risk register in that manner is that it was hard for us to actually intercept a team’s roadmap,” Breen said, and “it was hard for us to justify why we spend time building this when we could also build this customer-facing feature or improve our customer experience.”

Then, about a year ago, he decided to flip this model. Teams shouldn’t be expected to schedule in time to fix problems that aren’t affecting just one team. Instead, Intercom needed a singular team that could holistically consider all cross-company improvements to developer satisfaction and experience.

“We’re going to specifically focus on engineering satisfaction,” Breen said, “and, by having happy and healthy and high performing engineers, we will create great products and our customers will really enjoy it.”

For Breen’s team, efficiency is a side effect of satisfaction. Of course, this goal of being the world leader in developer experience becomes a strong recruitment and retention driver too. And in a year that’s been particularly rough for the tech industry, as they remove friction and toil for engineers, they are more able to meet customer demands without needing to increase headcount or developer workload.

Now, let’s break down what this looks like.

Intercom’s monolithic crocodile and battle-readiness

Despite the company’s reputation for being a great place to work, it’s not just attracting talent by using the next shiny-shiny. Instead, Intercom stands on a Ruby on Rails monolith built on Amazon Web Services — a monorepo deployed across many services.

“People always think of monoliths as dinosaurs, but it’s more of a crocodile where it’s evolved and hardened over time. Now it’s just battle ready,” Breen said, which makes it “very easy for my small team to make effective change,” with deep institutional knowledge and context of the systems.

Of course, some technical debt persists, but he believes there is power in their monolith over, say, microservices architecture. The known technological entity actually lets them improve developer experience faster.

“If we wanted to make an effective change [on microservices], we might need to replicate that across a lot of different places. Whereas if we want to improve, let’s say, the boot [load] time of the monolith for our engineers, it’s only one place we need to change, and that’s the monolith itself,” he said, which makes it “very easy for us to make a change and validate that it works. And then roll it out and get feedback straight away from engineers.”

In the first 90 days of this new increase-developer-satisfaction campaign, the Intercom DevEx team diverted from another industry trend — moving away from remote, cloud-based desktop developer environments in favor of using laptops as the primary developer device.

“Purely due to engineer feedback around the problems that they had with getting connectivity into remote services, keep codebases in sync. That kind of thing,” Breen explained this turn against the tide. “If we use these M-series [ARM-based, system-on-a-chip] from Apple, they’re actually great and they provide the compiler speed that we need. So the local experience we find is much better nowadays than having a remote one.”

Most importantly, in their developer satisfaction surveys, they’ve seen the rating of the environments “go through the roof,” he remarked — from 48% to 76%. “We found that we can build a hypothesis. Test it very quickly. Get feedback. Iterate on this. And then ultimately prove it.”

This all wholly embraces Intercom’s ship to learn core value, which cultivates a culture of shipping as quickly as possible, alongside blamelessness and low-risk learning.

Can a monolith have guardrails?

Netflix famously coined the phrase “guardrails not gates,” referring to giving developers a series of choices to get them on the right path, but not being declarative, among those choices, about which tech their devs ultimately use. More recently, Spotify has talked about laying down “golden paths” that guide their developers in the easiest way to get to production. The Spotify developer productivity engineering team allows its devs to go off this proven path, but devs wander knowing they might not be supported in this less simple process.

Intercom’s developer experience team has established a “blessed setup” or “happy path,” which Breen described as, “If you want the least friction for getting set up and running, follow these instructions and these are the ones that we will support directly as our developer experience team.”

Intercom is much less opinionated about which integrated development environment or IDE is used.

“It’s always been in Intercom’s DNA to be very engineer-focused, to be ruthlessly efficient, like getting toil and roadblocks out of an engineer’s path, because we want them to make a good product for our customers.” — Iain Breen, Intercom

It’s less of a gated situation and more of what the DevEx team can directly support and continuously improve.

“We won’t stop engineers who may have other experience in a different area that they want to implement and improve their own workflows,” Breen assured. It’s quite the opposite, where devs who go off that golden path may be asked to support others.

“It’s more like you’re kind of on your own. We’ll best-effort support it where we can, but you might now become the subject matter experts in supporting this environment,” he continued. “And we might ask you to help us or help upskill and if we find something that’s interesting, we can [run] experiments and build that into our current flows for our engineers.”

This leveling up “tour,” as Intercom calls it, could see the developer experience team borrow one of these sudden subject matter experts for a couple weeks or one of Breen’s team could embed on that app team.

“We don’t need to have dedicated headcount moves,” he explained. “It’s more like: ‘Hey, we’re just going to solve this problem and we’re going to work together til we get it done’.”

While each team has its freedom, it’s important to note that new engineers who join Intercom are persuaded that this blessed route is the fastest way to get up and running.

Intercom’s democratized internal developer surveys

Just like with external customers, a quarterly internal developer satisfaction survey can go a long way to uncover roadblocks alongside shorter, more frequent pulse checks. The first 90 days of moving from a cloud-based development environment to a local one was in direct response to the most common developer complaint to surface.

After that, Breen’s team looked to find a way to more efficiently run surveys because “it’s hard to run your own internal surveys, I find because, not only are you not too sure how to frame the question, you have to manually do all the data analysis on it.” He continued to reflect that “you’re not sure what type of biases you’re bringing in by asking questions in a certain way,” emphasizing that survey creation is not his field of expertise.

These biases can include areas for improvement that he may emphasize or de-emphasize. This also meant that he ran the risk of blocking other people from influencing the developer experience.

Breen chose the DX developer insights platform as “the super fuel for our developer experience program here. It handles so much of the work in terms of creating the survey [and] creating the analysis out of it as well, and also gives us angles that we never really thought of before.”

DX’s measurements are integrated into Intercom’s developer workflow and connected to Slack, where developers can answer a survey, and then the results and analysis quickly feed back into the platform. There, they view survey results alongside quantitative metrics from systems.

“One of the real selling points of this is that, before, I was the single point of failure and a bottleneck on a lot of the analysis, which meant that [everyone] was kind of depending on me to build my own insights and derive it and send it to the org,” Breen admitted. “Whereas now, with the DX platform, the data is democratized. Every engineer and every manager can see the inputs and see how the scores are set up.”

Other engineers are even welcome to build and inner source solutions to the problems they face, increasing cross-org motivation and involvement in developer experience.

Because of the rapid delivery of promises to devs, the Intercom DevEx team sees a minimum of a 90% response rate.

“I hope it’s a good reflection that we do a lot of work to respect the time that engineers put into taking the surveys,” Breen said, including providing a summary report and sharing their roadmap, on top of all engineers having access to view the DX scores and trends.

For Intercom, top-line engineer engagement and developer productivity metrics include:

• How much time do you think you lose per toolchain?
• How much time do you lose due to inefficient processes?
• How easy or difficult is it for you to work as an engineer at Intercom?
• How satisfied or unsatisfied are you with the internal documentation at Intercom?
• How satisfied or unsatisfied are you with the clarity of requirements for tasks?

These aggregated results are anonymous but respondents are allowed to elaborate via public, written feedback. So far, they’ve seen these numbers improve with each survey, Breen said, but “even with our worst scores, we’re proud of them because it means we can improve on them.”

Removing roadblocks to docs and requirements gathering

Through about a year of using DX, the Intercom developer experience team surfaced documentation and requirements gathering as the next two priority roadblocks that add to excessive cognitive load and context switching.

“Historically this ‘move fast mentality’ can come across as ‘moving so fast, we don’t write the docs’,” Breen said. Docs, when existent, have been scattered across Notion, Coda, Google Docs and Stack Overflow for Teams. In the short term, his team has created a self-service widget. In the future, as other engineering teams look at integrating generative AI into this customer service tool, his team is looking at dogfooding Intercom with its internal developer customers, including perhaps adding GenAI to the mix — all in a continued goal to reduce context switching and to increase developer flow state.

As for requirements gathering, Intercom has user experience design researchers speaking to customers. Then it’s up to the engineering org to figure out how to translate those needs into shippable code. This tends to yield the lowest score from developer surveys, because, again, Intercom is focused on shipping fast over shipping perfect.

“We don’t want to get too far down the path before we realize we built something that customers aren’t going to use,” Breen explained. Based on feedback from DX, the objective for his team is making sure its developer customers feel confident in what they are building to satisfy these requirements, while also being able to easily consider how each requirement will integrate within the rest of the product.

For the Intercom developer experience team, these numbers and trends aren’t only motivating within the context of the company. The team eagerly tracks the Industry P90 benchmark (90th percentile, or top 10% of organizations) within DX, which allows an organization to see how it compares against top organizations. As one of Intercom’s objectives is to be the best place for engineers to work, Breen’s team has set a key result to stay in the top 10% or better when compared with other orgs.

Another thing that makes this team stand apart is its lack of sole focus on developer productivity — although they do track aggregated trends around developers’ self-reported productivity.

Another key result is that, by the end of any engineer’s first week at Intercom, they should’ve been able to ship something to production, which he said validates that their developer environment is fully set up, they’ve tested the deployment toolkit and they’ve been able to grasp the organization’s complexity.

If they focused only on measuring developer productivity, Breen said, “We might be shipping more, but we might be shipping things that are broken or not fitting customer requirements.” He continued, “the payoff is in making sure our developers feel great about how they work.”

This article was originally published on The New Stack.