Almost excited to get paged

Six weeks into my internship, I was handed the biggest project I'd ever worked on: WhatsApp notifications for on-call paging. It was bigger by a large margin. When we scoped it out it broke into about a dozen chunks, each roughly the size of a whole project I'd done before. This is what I learned from it, and what it was like leading a project of that size as one of the most junior engineers at the company.

Adding WhatsApp as a notification method means we can use it as another way of reaching people when they are paged. It was on our roadmap because we know SMS delivery is unreliable in some regions and WhatsApp goes over the internet instead which is more reliable in those regions.

I was going to be leading it, something I'd never done with a project this size. I was excited and nervous in roughly equal measure.

Raise the pace

I knew the project was big, but it didn’t really sink in until I saw it broken into pieces during scoping.

We spent more than a week planning how to add the feature, much longer than any project I’d worked on before, both within our team and with engineers who’d built the parts of the codebase we’d be touching. Leo P cleared up a misunderstanding that would otherwise have sent us down a costly path. The pace here is normally fast, so days of nothing but discussion got in my head a bit, even though taking that time up front is deliberate. It paid off: how thoroughly we scoped it is a big part of why we shipped as fast as we did. Sometimes it seems like diving straight in and writing code is faster. I don’t think it usually is.

The scoping started very pen-and-paper: settling on the design we wanted and how it would actually work for the person using it, rather than the finer technical details. WhatsApp have their own way of doing things, so our escalation messages (the ones that actually reach you when you're being paged) have to use a template approved in advance by Meta, which ruled out some of what we’d sketched out. Mostly it came down to weighing that effort against whether the feature would actually get used, and being willing to drop things. For example, the WhatsApp for Business API doesn’t support WhatsApp calls. There’s always more you could add, and people had genuinely good ideas, but the job was deciding what the first version actually needed and saying no to the rest. Saying no isn’t permanent though: I added incident subscriptions via WhatsApp last week because customers asked for it.

Adding a bit of WhatsApp everywhere

My first PR for WhatsApp was a feature flag, so we could control who got access. We started off with the project team, then rolled it out to everyone in the company for internal testing, and finally to customers in stages. That gradual rollout mattered more than usual, because Meta caps how many people you can message until you’ve proved you send to lots of unique users consistently. We also added monitoring so we could see how much capacity we had, and what was erroring.

After that came the notification path itself. From the outside, being paged looks like one thing: your phone goes off. Inside, it’s a dozen layers - from the contact details we hold for you through to the timeline that records what happened - and WhatsApp needed adding to all of them. None of the changes were big, but I couldn’t make any of them until I understood what each layer was for and why it handed off to the next one the way it did. Making lots of small changes across a system turns out to be a very good way to learn it. The list kept growing, too. I hadn’t thought about the import flow at all until Esther pointed out that customers migrating from PagerDuty would need their WhatsApp numbers brought across.

One of my biggest learnings came from getting retries wrong. Most of the time, a failure is temporary and trying again a moment later is right, so that’s how I treated every failure. But some are never going to work, like someone who’s blocked our number, and I hadn’t written anything to recognise those. When we page someone, we work down an escalation path. A failure lets us move on to the next person; something stuck retrying holds it in place, so nobody gets paged. So I made the permanent ones fail straight away, with the reason surfaced on the dashboard so whoever’s looking can see what actually happened. You won’t catch every error case in scoping, and that’s what implementation is for.

The last things I shipped were about access: who’s on a plan that includes WhatsApp notifications, and hiding it entirely from anyone who’d opted out. My first PR decided who could use it, and so did my last. Wholesome.

Find a way

At one point we fell behind because getting our Meta account approved to send messages took longer than we expected, which something we couldn’t have planned around. I found that disheartening at first: we’d scoped carefully, then lost time to something entirely outside our control, and it felt like the plan had failed. Nobody else treated it as a failure. Everyone just kept coming at it from different angles until something worked, and we reshuffled in the meantime and picked up whatever we weren’t blocked on instead of waiting.

Group projects at university went sideways too, but the stakes there are a deadline and a grade, and nobody’s waiting on the other end. Seeing a team absorb a delay like that without any drama was new to me.

Things broke after we shipped, too. Our first real incident was someone putting a newline in an escalation title, which WhatsApp templates don’t allow. I’ll admit I was a little excited about the project having its first real incident. It’s okay to break things; what matters is moving fast when you break them.

Trust by default

One of the things that helped me get the most out of this project - and grow as an engineer - is how much ownership you're given here.

I was slow to say what I thought at the start, surrounded by people with years more experience than me but I got over that fairly quickly, because your opinion gets taken seriously here even when you're the new intern with barely any context. The separate-channel question was one of the first times I said it: I thought WhatsApp should be its own thing rather than living under phone numbers. Talking it through got us somewhere better than my version, a separate channel that still lets you reuse a number you've already added, so no user has to enter the same number twice.

I got to make real decisions. How the message templates were structured was my call, including dealing with Meta on them directly. People gave me their thoughts, but weighing them up and deciding was on me. It didn't have to be perfect, which is a big part of what made it feel like trust: I got the first pass, and once everything else was working we went back and improved the templates to make them nicer for whoever's reading one at 3am.

Ownership wasn’t limited to just within our team. When people across the company - TSEs (technical support engineers), solution engineers, product engineers not on the project - asked questions in Slack, I didn't wait for someone else to answer, I just replied and it was trusted. Being one of the people who got questions directed to felt good.

I also got to choose my own chunks and tickets. Nobody ever told me "you have to do this one," so sometimes I picked something I already knew well and sometimes something I had no idea about, because it was a good chance to learn. That autonomy is where a lot of the learning came from since deciding what to pick up meant working out where my gaps were first. I started off asking what would be good for me to take on, but I got better at making the call myself, especially towards the end when there's no natural order left and it's just a pile of improvements you have to rank.

Win together

One habit I changed was sharing frontend designs early, before they were anywhere near polished, so there was still time to act on the feedback. I used to sit on things until they were perfect, which just meant iterating alone instead of getting good input. I'd had feedback on this before: we do Feedback Friday here, where everyone gives and receives feedback each week, and the weekly cadence is what makes it work, because it's recent enough that people still remember the specifics and what you get back is concrete enough to act on. This time I actually fixed it.

Edd and Nicole, who I worked with most closely, were brilliant, and I learnt different things from each. Nicole's reviews caught the things that would have quietly not worked - a place I hadn't wired up, validation I'd skipped - and she'd ask a question rather than give the answer, so I had to actually understand it. Edd made me think about design: whether an endpoint needed to exist at all, whether two things I'd modeled separately were really one thing, whether a name would make sense to someone reading it in six months.

Stand-ups and end-of-day updates forced a particular kind of honesty: what we'd done, what was left, and being upfront when a day hadn't gone to plan. Some days I did more than planned because I'd been ambitious with my goals, some days less because you can't predict when you'll hit a big bug. I got better at being okay with the second kind: a day where you don't finish what you meant to isn't a bad day, it's just what the work looks like sometimes. With Edd and Nicole away at points, I had to write things up well enough that whoever picked them up didn't need me in the room, which forces you to understand what you've done rather than just that you've done it.

I also liked that I wasn't building this alone, or with other interns. I was alongside experienced engineers, on a proper team, which meant getting dragged along sometimes: picking something up fast because the person next to me already knew it well, or getting nudged past a decision I'd have sat on for days by myself. I learnt faster, and we moved faster, than I would have on my own.

The first time it actually worked

So much of this project stayed invisible for so long. With most code I'd written before, you see the effect as you write it, but here a huge amount of backend work had to happen before a single message came through, which is why the first one mattered as much as it did. We'd tested plenty in the development environment, but the moment it worked in production was properly special. The main build took just over a month, with smaller bits after that, and then it just worked. I was almost excited to get paged after that. Almost.

All hands

One of the most exciting - and most nerve-wracking - parts came near the end: presenting the project at all-hands, in front of the whole company. It was one thing to be trusted to lead something customers had asked for; it was another to be the one explaining it to everyone. A couple of dry runs with the team helped a lot. Their input gave me a much clearer sense of what to focus on, instead of trying to cram everything in.

It also changed how I thought about the project. Until then, I’d mostly thought about how it worked, technically. Presenting meant switching to why we’d built it and what customers could get out of it, a much less technical way of looking at something I’d been deep in the weeds on for so long. It was also nice to be encouraged to take credit for it!

Closing

Every phase wanted something different from me: patience while scoping, pace while building, and a kind of care I'd never needed before at rollout, thinking about legal implications, docs for the user, gradual rollout. I'd never built anything that had to hold up like that.

The biggest thing that changed is how I feel about taking on something big again. I'm more confident I can handle a project this size now, in a way I wouldn't have said about myself six weeks in. Owning the whole thing rather than just my slice of it is a lot of why: because I'd been there since the first scoping conversation, I understood the actual problem, not just whatever ticket was in front of me that day.

I'm looking forward to more projects like this one. And honestly, the first thing I do every morning before I start work is check the dashboard and watch the number of WhatsApp users and messages go up.