I’ve never done this before (at least sharing it publicly) but 2022 was a wild ride for me and I wanted to pause to consider everything that happened.

Weird to think it, but this was my first full year at incident.io, having joined the company August 2021. So much has happened these last 12 months – 4x’ing the team, our Series A, building loads of product – that it feels much longer.

I’ll break this down into reflections on team, product and writing. Only a few aspects of my last year, but themes I like to keep track of.

Team

The most obvious change has been how much incident has grown, going from ten to forty-five people in total, and four to fifteen in Product Development.

That type of growth is really exciting, but extremely hard to do well. Honestly, I’m astounded by the quality of the team we’ve put together, and think we’ve managed the challenges that come with this growth fairly well.

Firstly, I’m proud of the interview process we’ve built. We held 800 interviews in 2022 – of which I contributed 80 – and the effort we put into making the process as fair and transparent as is possible has really paid off, with props going to incident’s awesome Talent team for a lot of that.

Looking at the engineering team, it’s felt amazing watching people join and jump right into things. It’s particularly rewarding to see Martha speak about her experience in “Why I joined an engineering team of 6” and it be so representative of the culture we’re trying to build. Or Aaron in “5 things that surprised me in my first month” be so excited about how fast we’re moving, and talk about our trust by default ethos.

It would’ve been easy to hire loads of people and totally screw up those key cultural foundations. We worked hard to make sure that didn’t happen, and I’m happy with where we’ve landed.

Reflecting on me within the team, the most challenging part of an early stage has been knowing how to fit in. Joining incident as the first employee, I had to deliberately forget a lot of my previous role as a Principal because it just wasn’t relevant.

• Coordinating multi-team initiatives? Pointless, you’re four people.
• Supporting team leads? We have none.
• Consulting on technical problems? Sure, but you’ll be building it!

And for the first few months, forgetting everything worked pretty well. Getting heads down building things and being totally obsessed with the product was great fun, and helped set pace and quality of what we got out the door.

But as the team grew, I’ve had to gradually remember old behaviours as they became more appropriate for the business. And that meant struggling – and I have struggled – to understand how I can best contribute in this environment, from what to focus on technically to building relationships and ways-of-working, so I can provide support for teams without it feeling like I’m backseat driving.

I’ll be starting 2023 by supporting the creation of a new team, the first we’ll be creating out of the general engineering pool. In a past life, I’ve found success joining a team and helping them establish themselves, building relationships that last so I can support them once I move away.

A year from now, I expect I’ll judge myself on how well these teams have grown, and whether I’m in a position to properly support them. So I’m looking forward to the first of those challenges, and will be trying to learn as much as I can from the experience.

Product

Obviously the team comes first, but what the team has achieved is also awesome.

Starting the year, we’d just released Workflows, probably the most complex and powerful feature we had. But while Workflows keeps that title, it was a foundational piece of a much larger product that we hadn’t yet built, and we had a lot of obvious things missing.

We shipped too much to discuss it all here, but as some highlights:

Building on workflows

Workflows may have shipped in 2021, but we’d designed the core workflow concepts to be foundational for a lot of product features. In fact, the engine we’d built for workflows had been something we’d hotly debated, it being something that felt complex and perhaps premature at the time.

Reflecting on this with Lisa recently, we’re really glad we made this bet. Whether through luck or design, the concepts have proved remarkably solid, and allowed us to leverage them (Lisa would call these ‘lego bricks’) for a number of new product features at almost zero-cost.

One of the most visible examples is extending the workflow language to support expressions. Using expressions - if X then Y – has allowed some of our customers to consolidate ~10 workflows into one, such as a workflow to “Send updates to team channel” with a common message using an expression to compute which Slack channel to notify depending on the “Team” custom field.

But like most concepts from workflows, it wasn’t long before the same code that powers workflow expressions found other uses.

Just a few places are:

• Jira Cloud issue sync, used to calculate the value that should be provided to various Jira issue fields from the details of the incident, such as custom fields or severity.
• PagerDuty auto-creation, creating an expression that calculates the incident type or severity from the PagerDuty service or priority.
• Exporting follow-ups to issue trackers, to calculate default field values (like Linear/Jira project, or GitHub repo) depending on incident properties.

When we created these concepts I had conviction they were sound. But I expected we’d eventually try doing something basic and realise we couldn’t, because the underlying model was flawed or incomplete.

To my surprise, we’ve not hit that yet. Which is really reassuring, as going into next year we’ll no doubt build even more on these foundations, and it’ll be key to our success that these concepts continue to work as a cohesive whole.

Notifications

One moment of unexpected pride was shipping notifications, providing an interface to view notifications inside of the dashboard along with regular email-roundups.

I say unexpected because until we built it, I hadn’t realised how much notifications made it feel like we’d built a real product. Almost every software I use offers this, so when we built an extremely slick and polished version ourselves, I had a weird feeling that we’d ‘grown up’ or something.

Notifications is also one of the most obvious examples of how much our design has levelled up this year. Thanks to James’ tireless efforts and exceptional taste, we’ve upgraded from functional design to another level entirely, helping the product feel premium and our team much prouder of the great work they put into the implementation.

The feature also joins together the product so much better, adding more value to every interaction: now when you comment on a timeline people hear about it, and closing an incident starts feeling like you’ve checked something off your todo list, rather than something you did just because.

Writing

Something that took a backseat this year was writing, which was to be expected: working in a start-up is pretty all-consuming (in a good way), and if I have free time to work on something it’s likely going to be incident.

There were a few pieces that are worth calling out:

• My most impactful code was a fun post reflecting on abstractions I built at GC, and did the rounds online. It’s rare that people look back at work over a multi-year period in our industry, so mixing a bit of story-telling with a neat technical solution can be enjoyable.
• Building workflows: technical deep-dive was exhausting to write, but I’m glad I did it. Experience has taught me long-form is an awful way to build traction, but I wanted to capture my thoughts while they were fresh, and I’ve had several people reach out to say they’ve studied this for days (🤯) while building similar systems at their companies, so I’ll take this a win.
• Want to found a start-up? Work at one first! was just so obviously going to cause trouble, and it did: it spent a while on the HN frontpage receiving all sorts of hot-take comments. I try to avoid being too controversial online and don’t enjoy the attention when something takes off, so I think I’ll do less of these. Was happy to share my perspective on the question though, especially with lots of people considering start-ups in the current environment.

I write mainly because it helps order my thoughts, and because I enjoy being able to help others – and myself – when they hit similar problems. It’s also great practice at communicating in general, which is a superpower for almost everything in life.

For that reason, I’d like to ensure I’m doing more of this in 2023. I’d also hope incident will give me a lot to talk about, instead of the 50/50 mix I have of past and present experience right now.

2023 🤞

Coming back from seeing family over the Christmas break, I’ve been asked several times “how has last year gone?”, especially with the idea of a start-up being foreign to many of them.

For me, the way my head works, I’m always looking forward at the next thing. Which is why I find it difficult to answer that question and one of the reasons I’ve written this down, to force myself to look back and be appreciative of where I am.

And I am really appreciative. I always think I got lucky, in that for as long as I remember I wanted to be a software engineer. And unlike many, software engineering is exactly what I expected and more, and my work is a huge source of joy in my life.

Working at incident is the best version of this that I’ve known so far. I love the team, really believe in the product, and enjoy that this is going to be a battle tooth-and-nail to succeed in a competitive space. It suits me great, and while I know next years going to be really hard work, I’m already proud of what we’ve achieved and excited for what comes next.

If you liked this post and want to see more, follow me at @lawrjones.