Every team at Intercom is fully empowered to make the technical and business decisions necessary to do their job. They’re expected to own the problem from end-to-end, from relationships with vendors, through to running the underlying infrastructure, and all of the software in between.

In this event, speakers from Intercom’s Message Delivery software team (tasked with delivering Intercom’s messages across email, push notifications and websockets) will share their lessons learned in taking this approach of end-to-end ownership. We’ll talk through how good engineers step up to the task of fully owning the problem, as well as exploring some examples of the more expansive work we’ve done to chase high impact solutions. We’ll also talk through the classic build vs buy decision in software solutions, and what happens when engineers are left alone to make these decisions :-)

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.

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.

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.