My first three months at incident.io

How does working at incident stack up? Some observations from my first three months here working as a Product Engineer. I’ll say from the outset that I knew incident.io was setting the bar high when they took me for breakfast on my first day!

What really stands out when I think about my time at incident.io so far is the culture. It shows up in ways that have been a refreshing change of pace from what I’ve seen before.

Think before you do

There’s a really strong practice of thinking before jumping into doing stuff. For any project we tackle, and for context a project here is usually a week or more of work, we write three documents:

A cover sheet - a quick definition of what we’re trying to do, who it’s for, why we’re doing it.
A product specification - outlines what we’re building, what interaction looks like, what using this thing will actually feel like. Broken down into ‘chunks’ that can be delivered separately.
A detailed technical scope - how we’ll break up the coding, what bits ship when, which APIs need writing - with sample code, what components we’ll create, etc.

When these are well written you could honestly hand the project to any of our engineers and they’d execute on it without needing much input.

Once we’ve got those documents we run a kick-off inviting the whole team and anyone outside the team who might be useful input. In the kick-off meeting we’ll: talk through the documents and ensure everyones on the same page; agree on which chunks are in / out of scope or can be dropped if we run out of time; and go through the release plan seeing if we can ship some chunks to customers early for example.

I’ve seen similar processes elsewhere, usually only for big projects, and rarely written down in more than Jira/Trello tickets, always run by tech-leads. Here though, even for small projects, we run the same process and all engineers rotate through leading the process.

The usual resistance to writing plans like this is they’re accused of slowing teams down. Having seen them in action for three months, it speeds us up by enabling us to build closer to the right thing the first time. It saves us from inconsistent implementation, and a lack of visibility as to what teams are working on. They are also great to refer back to to when planning new features, to see the reasoning for things existing and the tradeoffs we made getting there. I’m a big fan.

Trust by default

The amount of trust here can be really jarring, especially if you’re used to larger organisations where there are layers of approval for everything. Here’s a concrete example: I worked on a small project to let you automate giving seats to user groups, it took around a week. I was given a couple of sentences as to what we thought we wanted but after that I owned everything. Defining how it would work, getting the UI designed and the feature built, turning it on, communicating it internally, through to communicating it directly to customers that had asked for the feature. I was trusted to do it all - though I should add I was given plenty of help and support where I wanted it!

Now for someone with my experience this isn’t that uncommon, I’ve owned and shipped large things before. But here’s the thing, this trust isn’t because of my experience. Every engineer is given the same level of trust to deliver things every day.

Working on actually fun, hard problems

We’re also trusted to manage our own time to build things well. This has led to many engineers spending time improving the developer experience, often along side shipping their normal project work. This means we don’t need to fight poor tools, slow pipelines, flakey builds, frustrating deployment processes or undocumented code.

These quality-of-life improvements enable us to go much, much faster. They enable us to spend more time working on the hard problems that move the company forward, like improving how teams interact with the product, and less on trying to get a random test that is unrelated to your work to pass. The only thing you need to think about most of the time is making the product better.

This makes it genuinely fun to come to work.

What this all adds up to

Three months in, I can really see how the culture lends itself to shipping a great product, quickly and actually enjoying yourself while doing it!

The intentional thinking out loud makes everyone clear on what we're building and why. The real ownership we get through all that trust naturally makes us care about making everything as good as we can. And the shipping fast is infectious.