10 engineering lessons from 6 years at Intercom
Intercom has a unique engineering and product culture – discover the main lessons around product and technology learned by one of our engineering directors during his time here.
After more than six incredible years, across three roles, in three different product groups, I’m leaving Intercom for an entirely new opportunity.
As we have extensively written about in the past, Intercom has a unique engineering and product culture – so here is my attempt to reflect on the culture and summarize the main lessons from my time here. I hope these insights prove valuable for other engineers and engineering managers.
And if you’re interested in working on hard problems with great people, be sure to check out the Intercom careers page to see if there’s a role for you – you won’t regret it.
1. Betting only on the future is like shorting the present and it carries an opportunity cost
Intercom is an extremely innovative company and our senior leadership is excellent in having great insight into what trends will make waves in the market. But betting only on that, building only for the future, is like shorting the present and thus carries an opportunity cost. At Intercom, we perhaps had that issue with emails and phone – we were confident for years that these channels were dying only to realize year by year that they were not shrinking at all. I find it a useful mental model when you think about the future trends – would you short the present and be willing to pay the premium if you continue to be wrong?
2. Every developer needs to have AI in their toolbox
When we worked on Fin, our AI team was fundamental to making it work, we wouldn’t be able to do it as a product team. However, as time goes by, more and more excellent features have been built into that system directly by our product teams. The initial push might need specialization, but it’s important to expose AI to your org as soon as possible. Another engineer shared with me this anecdote – back in 2008, companies had whole teams that did “mobile design”. Only a few years later it was part of everyone’s job.
3. Monoliths can scale very well, give solid deployment safety and high leverage for developer experience and observability
I continue to be amazed how well the Intercom Rails monolith scaled over the years. Exceptional engineering decisions, keeping it simple, huge leverage that our only developer experience team has, and sticking to proven cloud technologies helped us navigate growth really well.
“Monolith is something that keeps our ability to ship very fast, very often”
Monolith is also something that keeps our ability to ship very fast, very often (by sweating things like fast rollbacks or quick CI). We found a few services we owned painful to work with in comparison – teams had to be slowed down by maintaining their own dependencies, deployment pipelines or infrastructure updates. I never worked in professional, high-scale microservices architecture but can’t wait to learn about the trade-offs there.
4. How often you ship is critical. It’s your heartbeat
You might not ship it to customers, but there is always a way to ship to production in a safe way. If you can’t find it, keep looking. It builds muscles for accelerating even more when necessary, and keeps you from losing impatience culturally. Show off the progress, ideally on a regular company-wide demo.
5. Create plenty of system models and mental models, and apply different layers of abstraction
Looking at the same problem from different angles really expands your horizons and builds alignment. At Intercom I learned that the best meeting starts when someone picks up the marker. System models, made up on the spot, adapted, evolved as you talk – all of this really help sharpen your understanding of the problem, its complexities and dependencies.
“Shared mental models are very useful for moving fast”
Write them down, show them in your next conversation, ask for someone else’s mental model. Doing this work together with your partners and stakeholders accelerates how fast you collaborate and removes misalignment. Shared mental models are very useful for moving fast.
6. Own and know your data, without excuses
I had plenty of excuses in the past for my understanding of product data without the help of data analyst to craft queries and analysis techniques. I have no mercy for myself since ChatGPT. The quality and confidence in which I can navigate my product space without a dedicated analyst has increased dramatically and I expect that everyone at least slightly technical can do it now.
7. Data management is evolving, painful, and it’s tough to find a silver bullet
We owned a relatively flexible, broadly used data platform. It was the area of product with the biggest amount of feedback. But making an impact in this space was very tough. The market is evolving fast, with new approaches like ETL, reverse-ETLs, point-integrations, CDPs. Your customer base will be spread over multiple different “best ways of managing your data”.
“To see meaningful change and improvement in data management, it’s all about strategy and consistency”
And because of that, there was never a single problem – it’s always been long lists of problems, similar in some shapes but different. To see meaningful change and improvement in data management, it’s all about strategy and consistency. Small investment shots here and there rarely work.
8. Data integrations are getting more complex the more you dive into them
I learned to never underestimate cross-system integrations. From the distance, they always sound relatively easy – if this then that, sync objects in system A with the same objects in system B. But the closer you get there, the more differences you discover. Small nuances, API rate limits, race conditions, retries and lack of idempotence, and many more angles. The devil is always in the details, and the jobs your customers are trying to achieve with these integrations are often similar but fundamentally unique. Integrations are super complex the deeper you get and don’t underestimate it.
9. Building easy-to-adopt integrations is removing friction, but reduces the TAM.
The most easy to use integrations are layers of abstractions on top of core capabilities (like APIs or iPaaS blocks). They remove a lot of friction, usually working out-of-the-box. What I realized over the years is that building broadly adoptable integrations is very tough as every company has unique needs, setup and their own internal IT mess to navigate.
Building these abstractions makes it easier to adopt, but significantly reduces the TAM, which can end up with a lower number of customers using them versus a more complex but powerful version.
10. AI will fundamentally change how we build integrations
However, I believe it will play out differently for deterministic, high-volume integrations and non-predictable, dynamic integrations. Co-pilot experiences will dramatically accelerate users in iPaaS tools like Zapier or Workato while creating repeatable, high-volume, predictable process automation.
“AI agents will remove a need for building any integrations in human-triggered activities”
This will accelerate them, while maintaining today’s reliability and ultimately deterministic behaviour of these integrations. AI agents that can reason about which tools to use and adapt to dynamic and unpredictable input will remove a need for building any integrations (outside of API capabilities) in human-triggered activities like reporting, data exploration or asking for help.
Lessons for life
The experience of working at Intercom will always shape how I approach engineering and management for the rest of my career. I want to say a big thank you to everyone I worked with and that helped me form these lessons over the years. Intercom is a truly special company.