Today marks my one week anniversary of starting as a Product Engineer at incident.io.
How young I was then—unaware that a week later, I’d have navigated a mostly unfamiliar tech stack to ship two features, communicated with high-value customers directly about them, contributed to our Changelog, and written a blog post all about it.
Sound like a lot to get done in a week? Well, 4 days actually, as we take the last Friday of every month off.
Pace is at the core of everything incident.io stands for. The goal of the product itself is to enable teams to respond to incidents quickly and efficiently, with minimal faff—and this spirit informs our development ethos as well. Any engineer who has interviewed with us (or wants to) will know this.
But I’m sure we’ve all heard companies pay lip service to pace before. How do we actually deliver on this promise? As one of the team’s newest engineers, here’s my take. It comes down to thoughtful onboarding, ownership, and simple architecture.
🤖 Thoughtful onboarding
Let me start by taking you through my first week. Days one and two, as you might expect, are all about basic orientation — meeting people, setting up accounts, trying Dishoom’s sausage naan rolls for breakfast (🤌🏻), and getting familiar with all of the tools we use to catalog our work.
We are very disciplined in our use of Linear, an issue tracking tool, to keep track of what we want to build, why we want to build it, its estimated complexity, and who exactly should know about it when it’s delivered. This attention to detail enabled me to dive in to two very clearly explained and tightly scoped updates to the product by the end of day 2.
This isn’t an accident - in advance, the team had put effort into picking out digestible, yet high-impact pieces of work that I could tackle as part of my onboarding.
🤝 Ownership
Part of this orientation process is getting your local environment fully customised and ready for work.
This process is thoroughly documented by not only seasoned engineers on the team, but by newer hires who have recently followed these steps. From the start, the expectation is that this documentation belongs to us — if it needs editing, updating or clarifying, that’s on us.
Our job at this point is not only to follow the documentation, but evaluate their clarity for the benefit of whoever is starting next. It’s subtle, but this begins the instillation of ownership from the very beginning. Again, this is intentional: speed is a positive side-effect of trusting by default.
đźŹÂ Simple architecture
While all architectural choices have their trade-offs, one undeniable pro of monolith architectures is that they’re relatively easy to grok.
While I’m not yet an expert in the guts of our core codebase, my introduction to it was smooth thanks to its intuitive structure and clear, repeatable organisational patterns. The usual questions when making a change — What relies on this data? What needs to know about this extra property? Which pattern will this change break? — require very little investigation to answer.
Not to mention that in our case, one codebase == one backend service to run, and one frontend service to run. This makes local development the stuff of dreams — incredibly smooth, straightforward and easy to navigate. For me, this held true even though incident.io’s tech stack is made up of languages I’d had only cursory experience with prior to joining. This paradigm shift has been more-or-less neutralised by the careful and deliberate simplicity of the codebase.
So, yes, we really do move that fast. And although there is an element of magical startup energy here, the true reasons for our pace lie in careful and deliberate choices that we have made, and continue to make as a team.
Come see for yourself, and if you beat 2 features shipped by the end of your first week, I’ll buy you a pint*.
*Limited time offer, Ts&Cs apply.
