Why you should join incident.io: behind the curtain

In case you haven’t heard: we’ve just raised a $62m series B. That means we can grow the business — but to do that, we need to grow the team… which also means I’ve been spending a lot of time hiring recently.

We always leave time to chat at the end of our interviews, and give people a chance to ask us questions about what working at incident.io is really like. This post is based on a lot of those questions: I’m here to cut through the hype and the dollar signs, to tell you why you should actually join incident.io, and equally importantly about why it might not be a great fit for you.

TL;DR

Things I love about working here

• The product - our customers genuinely love it - we don't just want it to be 'good enough' we want to make someone's day when they use it
• The problems you'll work on career defining complex problems of all shapes, both product-y and technical
• The team - you'll work with a wildly talented team who will push and support you to do your best work, with a sane work-life balance
• The approach to AI - we use AI to build great product when it's useful, but never just for the sake of it
• The company - we are well positioned to win in a congested market, with competition pushing us every step of the way

Why this might not work for you

• The ruthless tradeoffs - we're relentlessly focused on building the most important thing, that means leaving great ideas on the table - it's painful!
• The relentless learning curve - with such a broad product surface area, you'll regularly need to dive into unfamiliar territory and get up to speed fast
• The written alignment - we believe in writing things down (scopes, design docs, thorough commit messages) to align before building and help us go faster
• The office first culture - if this feels like a compromise, it's probably not for you

The good

These are (in my personal opinion) the best things about working at incident.io.

We build a product that our customers love

Whenever I’m asked in interviews about my favourite thing about working at incident, it’s always this. I come from a fintech background, and let me tell you, no-one loves their direct debit provider. But incident management + paging software? It just hits a little different.

Our product matters to people. We’re a product that our customers use when things have gone really wrong, and they’re pretty stressed. That means the stakes are high: when we get it right, customers really love us (but if we don’t, they are understandably pretty frustrated).

Building for other developers is super fun. Engineers aren’t our only users, but they are a large group of them, particularly for on-call. Building for ourselves means we get to dogfood our product all the time, and can add delight features that are just things that we really want it to have.

We work closely with our customers. When we’re figuring out what to build, we’ll often jump on calls with customers to get their perspective and help steer our thinking. Everyone can see customer channels, and you might well find yourself jumping in to help a customer debug something related to a feature you built.

We get a lot of compliments. At a risk of sounding a bit arrogant: most deals that we win are because we’re the best product (we are deliberately not the cheapest). We have a Slack channel #compliments which has a direct line to my dopamine centre, and a weekly ‘magic customer moment’ at all hands where (usually a CSM) shares a particularly delightful interaction with a customer.

Every day, customers and prospects genuinely (usually unprompted) say things like:

We get to solve really challenging problems

The kind of product we build is mostly challenging on one of two aspects:

1. Gnarly product: we need to support lots of different organisations with diverse needs, while maintaining a coherent and understandable product.
2. Technically tough: as a paging provider we have to be super-reliable, and able to handle this complexity at scale, without making mistakes.

This kinds of work presents significant learnings opportunities for our team.

To give you a flavour, here are a few of the projects we’ve run over the last year:

On the more product-y side:

• Hyper-customisable forms which help you avoid asking your responders too many questions, while still collecting all the information you need
• Dual-running our on-call alongside PagerDuty as part of a migration process (including moving people onto our product team-by-team)
• Figuring out an actually-nice-to-use UX for managing your resources via Terraform

And on the more technical end:

• Figuring out how to make sure we get paged even if our own product is completely down (but still get to dogfood our product)
• Ability to ingest alerts while our database is unavailable (which was particularly handy when a pgaudit bug took our database down for a couple of minutes)
• Scale status pages to support OpenAI’s status page (which has ridiculous amounts of traffic)

Yes we’re building with AI, but in the right way

Entrepreneurs across the world are currently following the hype, running around with an AI-shaped hammer, looking for anything that looks like a plausible nail. I know I would say this, but I genuinely think we’re looking at this differently.

It’s not AI for AI’s sake.

We’ve got a team dedicated to building out our newest AI features: using AI to help responders investigate incidents. I firmly believe this is a legitimately AI-shaped problem. An LLM can help us:

• Rake through thousands of code changes to find something that might be relevant
• Look at 200 dashboards and tell you which queue has been backing up at the same time as the database CPU started increasing
• Tell you what your colleague did last time they were paged for this issue a few months earlier

One day maybe an LLM can auto-scale my Kubernetes pods, but for now that gives me the heebie-jeebies so we’re focussing on helping responders with a human in the loop.

Building this is by no means easy, but it feels that it’s possible to build something really great in this space.

Our ambitions are high: we are trying to make something that’s significantly better than the standard ‘I put some AI on it because my sales team asked me to’.

We’ll also continue to build with AI across the rest of our product suite, in the places where it clearly adds value (like Scribe which auto-summarises calls) - it’s a new tool that we have at our disposal and we’d be mad not to use it. But we should never be adding AI ‘for the sake of it’.

Building with AI also contains a lot more traditional engineering challenges than you might expect: orchestrating highly concurrent workflows, reporting on and controlling costs, and much much more!

We’ve written a lot about our approach to building investigations in particular if you want to find out more.

We have a talented and excellent team, with sane work-life balance

This is undoubtedly the most talented product team I’ve ever worked with, not just engineers but also PMs, design and data. And personally, I find that hugely motivating: working with excellent people is just a lot more fun.

It helps that they’re also a very fun bunch (if you want to get a flavour of our ‘vibe’, I’d recommend looking at the comments on our LinkedIn posts).

We talk a lot about pace, and shipping fast. It’s a part of our company’s DNA that we’ve worked hard to preserve since day 1.

But the question you’re actually asking: are you all working 80 hour weeks?

Well … no.

Some people never work beyond their core hours (usually ~10-6). Some people regularly work a few extra hours here and there or flex when there’s something particularly impactful, and some work significantly more. There’s genuinely a large mix in the team, and I expect (and hope) it'll stay that way.

We’re not interested in performatively working long hours: we want do do a great job and maximise our impact, not celebrating the number of hours we’re spending in the office.

We care about our work and have big ambitions, we’re not shy about working hard to achieve it. When things get tough, whether it’s a frustrating incident late at night, or trying to get something over the line for a customer, the team shares the burden: you always have your colleagues supporting you, you’re never in it alone.

We focus on driving pace in other ways - taking the time to ‘go slow to go fast’. In practise that looks like:

• Planning and scoping before we break ground, so we can all pull in the same direction (write and circulate a tech scope, chunk up the work so it’s well defined, agree on the APIs)
• Investing heavily in internal tooling, with low tolerance for everyday friction (think <10 minute time-to-deploy, local traces for debugging, world class observability, writing great docs for Claude code etc.)
• Being hyper-focussed on our top priority, ring-fencing people to do reactive work instead of asking everyone to constantly context-switch

We want to build a long-lived team that (as much as possible) stays together for the forseeable future: not a revolving door of mercenaries that burn-out in 1-2 years.

We’re well positioned to win

We aren't in stealth mode going after a secret idea that no-one has thought of yet. We've got stiff competition, that fall into three buckets:

• Incumbents - e.g. Pagerduty & Opsgenie, also more enterprise focussed tools like ServiceNow
• Peers - e.g. Firehydrant & Rootly, started with a similar Response product and have also built on-call
• AI SRE startups - e.g. Resolve, Phoebe and many many many more

That competition list tells us two things.

First, we can't coast. If we rest on our laurels, someone is going to come and eat our lunch. We need to out-execute our competition, by building a more compelling product, and fast enough that we don't lose all our momentum.

Second, the prize we're going after is worth pursuing. There just wouldn't be so many players in the space if the products weren't genuinely valuable for our target customers.

So, why take a bet on us?

• We have a top tier customer roster, with top engineering teams like Netflix, OpenAI, Airbnb, Etsy and many more trusting us to help them in their most challenging moments
• We're commercially in a good spot: the fundraise gives us a lot of cash in the bank, and we've had a great start to the year in terms of revenue
• We have really strong foundations on which to build the next generation of our product, both in terms of technical abstractions and product features like Catalog

Why might this not work for you?

Finding the right place to work is a two-way fit exercise. There are choices we’ve made that won’t suit everyone, and it’s important to chat about those too!

We have to make hard trade-offs

As mentioned at the start, we have many more things that we want to build than time to build them. That inevitably means there's always a backlog of things we'd love to build burning a hole in our back pocket.

This absolutely isn't a good feeling, and while I do think it's genuinely better than the alternative where you're building for the sake of building, it's definitely not for everyone.

There's a large surface area

We currently have three teams, and a product that probably would have (at a large company) maybe 20 teams working on it. It's part of our superpower: having a small team means we can make super cohesive product experiences. But it's not free.

You won't join the company and work on iterations of a single feature for 6 months. You'll be working on 1-3 week projects, within a larger domain like on-call or response.

That means you are often jumping into a new area of the codebase (which at least should look pretty similar in terms of patterns and structure!)

It also means we all do a bit of everything - while some of us might be more frontend or backend leaning, we are all up for picking up something new whether it’s a sticky React form or figuring out Google’s load balancer caching.

If getting up-to-speed on something new is a feeling you dread, then this may not be a good fit.

We believe that having the right structures + processes speed us up

We were once a scrappy 5-person startup with daily plans, nothing written down, and a lot of chaotic prioritisation discussions.

We're not that company any more, and we don't want to be.

We have high expectations on team alignment, and we get that through written communication. In practise that means:

• Writing product and tech scopes up-front to align on what we're building and how
• Running polish parties to give us time to sweat the small stuff, and pick up anything we've missed along the way
• Writing good commit messages and getting peer reviews before merging code
• Having solid code patterns across our codebase that we don't stray from without a good reason - we're optimising for our team to be productive across our codebase

If you're looking for a no-holes barred, full-on scrappy startup experience where you can make all decisions entirely autonomously, this isn't going to be the right fit.

We enjoy being in the office (in London)

We've built the team as 'office-first', meaning that most of our team are in the office 4 or 5 days a week.

We enjoy collaborating together in the office, and our 'default' is to be colocated and so able to have high-bandwidth conversations at desks with ease.

There's also flexibility: no-one is keeping count, and there aren’t specific days you have to be in / out. Some folks average 3 days in the office (which is our advertised 'expectation'), and we’ve had people work remotely for the odd week in Cornwall / New York / New Zealand.

But if you see coming to an office as a compromise you're willing to make, rather than something you're actively excited for, this probably won't feel right.

Conclusion

I find writing blog post conclusions really difficult, so congrats and sorry if you've made it this far. I really like this job, and this team, and I'd love for more great people to join us.

If it sounds like a good fit, check out our careers page or drop me a line on LinkedIn.

P.S. here are some final reasons that incident.io might be a good fit:

• You have strong opinions about what constitutes a top tier snack option (I say Pom Bears, come at me)
• You’re partial to a cheeky rooftop lunch in the summer (and take the traditional London view that ‘I can see the sun’ means it’s summer)
• Your first name begins with L (we’re currently 25% of the engineering team and counting)
• You also want to participate in Martha’s legendary #cold-case-mysteries game