Intercom Engineering Insights - Software Ownership

Introducing the Intercom Engineering Insights series.

To complement our popular "On Product" events, which give a broad view of all aspects of building world class product, we're starting a series of heavily technical focused evening events, each focusing on a specific theme which we are passionate about.

On Thursday, February 4th, from 6:45pm we’ll be hosting the next in our series of technology focused, Inside Intercom Engineering events. The theme for this event is Software Ownership.

We’ll be charging a €10 donation for all attendees. All proceeds will go to the Dublin Simon Community, a charity dedicated to fighting homelessness in Dublin. We’ll be covering food and beer for the night, so your donation will go entirely to the good cause. We do hope you can join us for what will be a great night.

Why talk about ownership?

Building a software product takes more than cranking out lines of code. An engineer who is truly owning a problem will extend their reach in any way possible to solve that problem. They won’t declare themselves a “front-end” or “back-end" engineer, cutting themselves off from entire chunks of the code base. They won’t ignore the cost of their database queries because it’s the Ops team that get paged for database problems. And they won’t treat problems that stand in the way of building a good software product as someone else’s job.

At Intercom, we want our engineers to own the problem fully. Ownership is one of our engineering core values. We describe it as follows:

Ownership is about caring, not box ticking. We are outcome driven. People who own things will naturally fight to overcome obstacles to reach the outcome. People who are great at owning things, earn trust and confidence to own bigger and bigger things. As owners of Intercom, we should act accordingly: If something is broken, say something. If something can be better, fight to make it better. Never be passive, never feel you’re powerless to make progress. Use positivity as a tool to help you and other overcome obstacles. Owners never say "that's not my problem”.

It’s also something I’ve spoken about internally and written about previously on our blog so I’m excited to bring to you a set of talks on the topic.

Speakers & Talks

Owning the problem

Changing from an engineer to a manager of 5 engineers, Brian Long now knows that going beyond simply producing lines of code can impress your manager, and benefit the organisation you work for. Having seen engineers on his team step up to own challenges beyond purely writing code, he’s also convinced that doing so can really help individual engineers to grow.

He’ll show you the impact that ownership can have across the company and on individual engineers, as well as taking us through some less obvious but powerful opportunities for showing ownership.

Owning scaling: Moving a billion row table to AWS Aurora

How do you move a live, heavily accessed billion row table between databases? Why would you want to do it in the first place? And why not leave it to the Ops team? At the heart of Intercom is a simple relationship between Users and the Messages they’ve received. But as you can imagine, we have a lot of them.

A few months ago, Mario Kostelac took end-to-end ownership of our data store scaling by taking on the challenge of moving this table to Amazon’s new relational database engine, Aurora. He’s going to tell you why he did it, and how he managed it with mere minutes of downtime.

Living with what we’ve built

At a previous event, we spoke about a project to support real-time messaging in Intercom and how our build vs. buy decision unfolded (spoiler: we chose to build). It’s now 12 months since we built our first iteration of our real-time system.

William Tabi is going to take you through those 12 months and the reality of living with and being paged by a system you’ve built. He’ll talk about how that experience can prompt you to revisit your design, to simplify it, and remove every unnecessary dependency.

What happens when engineers choose to buy?

How (and why) do you pick a vendor to simply send millions of emails a day on your behalf? We were faced with this question in the past months, and once again made the build vs buy decision. This time, we took out our cheque book.

Aidan Lynch will take you through truly owning every part of the solution, and the unexpected challenges that arise when you’re doing so much more than writing code.