Accidentally Saving the Day

Several years ago, when I was a junior engineer just out of university, a PM wandered by my desk on his way to a meeting one morning. “Uh, hey, we’re having a meeting about Project Jabberwocky, uh, right now, can you come?” He was already past my desk and did a last-second pivot to extend the invitation. I was familiar with Project Jabberwocky — a major effort to rewrite our embarrassingly awful iPhone app for the new mobile-first future — and I was surprised by the request. Not only was it a last-minute afterthought of an invite, but I wasn’t really a part of Project Jabberwocky, beyond helping them out with a few small issues. But I was curious, especially since I knew Jabberwocky was getting extremely close to release. So I accepted anyway and followed him to the meeting.

The room was packed, hot and stuffy, and the meeting started late after people finally stopped trickling in. The PM explained what had happened: about a week ago, a new experiment called ChaChing had been extremely successful, massively increasing sales from mobile phones. This should have been nothing but good news.

But, the problem: ChaChing had been built exclusively into our old iPhone app and not into Jabberwocky. This made sense for an experiment like ChaChing, since you want to experiment with the released app (with all the users) and not the unreleased app (with zero users). Except fate’s timing had screwed us, since Project Jabberwocky was due to launch in 5 days, sans ChaChing, losing us all those potential sales, unless we did something. One idea for “something” was to just delay Jabberwocky until we could integrate the ChaChing code — but that would be a PR disaster. Jabberwocky was important enough that we already had a bunch of press events lined up about it, so any delay would be very visible and very public. We could delay if we had to, but that’s why this meeting had been called: we were to find any possible way to hack ChaChing’s code into Jabberwocky, and we had a blank cheque to do whatever we needed to make that happen before the deadline.

The PM nodded awkwardly and left us to it. I still wasn’t completely sure why I had been pulled in; while the system I worked on did sometimes shuffle data between ChaChing and Jabberwocky, my work tended to focus on other clients. But I had worked on the Jabberwocky-specific component a couple of times, and its general principles were similar to the parts I was more intimately familiar with. So I supposed I did have some relevant insight, perhaps — and, in any event, I was now on the hook for helping make this happen anyway.

I joined a conversation among the Jabberwocky folks about how to get the ChaChing data into a format that Jabberwocky could be quickly hacked up to understand. Unfortunately, the API between Jabberwocky and the backend I worked on wasn’t designed with this in mind, and so it was unclear how to actually do it. They suggested a few ideas which I explained were incompatible with the backend; I suggested a few which they explained were incompatible with the Jabberwocky frontend. After several rounds of this, we gained a lot of mutual understanding of each others’ systems and restrictions — enough that we were able to come up with a plan. We’d use an unconventional formatting that my backend could send to Jabberwocky — very hacky, but it would work without complex API changes. Then Jabberwocky would use an unconventional interpretation to get the data it needed out. It might actually work.

The Jabberwocky folks got to work on their side, but someone needed to build the formatting to put the ChaChing data into the right format to send to Jabberwocky. I supposed that fell to me; no one else was volunteering, and I knew how to do it.

Someone also needed to figure out how to pull the ChaChing data in the first place for my code to format. The ChaChing team had been strangely quiet throughout all of this. As I talked with them to figure out how they could provide my code with the right data, I started to realise they had little real understanding of what our plan was, and that I couldn’t trust them to get this done. So the data retrieval fell to me too, after I got a little bit of information about the ChaChing API from them.

By that night, I was able to provide Jabberwocky with some fake data for them to test their code with. Over the next few late nights, I got real data hooked into the system, helped debug both sides, and even tripped over a compiler bug. The Jabberwocky team similarly held up their end of the bargain.

By the end of the week, the PM and the rest of Jabberwocky management were really happy: we actually pulled it off! Jabberwocky launched on time, with ChaChing duct-taped onto the side. The new iPhone app was well-received by our customers, and the new sales stream continued uninterrupted.

Pleased at having helped smooth out this small bump right before Jabberwocky’s release, I went back to what I’d been doing the week before and didn’t think much more of it.

An Alternative View

During my next performance review, I received a promotion and the highest possible rating and bonus. (This is still the only time in my career I’ve ever gotten such a spectacular performance review.) I was quite surprised — I didn’t think I’d done anything particularly special. My manager explained that my work helping out Jabberwocky and ChaChing had been really impressive; I accepted the compliment and moved on without much more thought.

But in the ensuing years, I’ve come to realise a lot of things that were largely lost on me at the time — the above is how I would have told the story shortly after it all transpired, but here’s how I suspect that PM would have told the story:

Everything was fucked. Mobile was eating the world, and our company was horrifically behind. Two major company initiatives were supposed to fix this. The first, Jabberwocky, was to rewrite our awful iPhone app so that it had basic features like “not crashing all the time” — without Jabberwocky, our user base would inevitably evaporate in the oncoming worldwide shift to mobile. The second, ChaChing, was to figure out how to make sales on mobile — without ChaChing, 100% of our revenue was on desktop, which would similarly evaporate in the oncoming worldwide shift to mobile. These were not just major projects — they were top-level company priorities to mitigate existential risks to the company. And, by a cruel twist of fate, these projects had become at odds with one another! Releasing Jabberwocky on time would mean reverting ChaChing; delaying Jabberwocky would be a PR disaster. We were stuck between a rock and a hard place.

As a hail-mary, he called an emergency meeting, inviting anyone who might possibly be able to engineer a way out of this — literally pulling in everyone within arms reach on his way to the meeting (like me) in the desperate hope they might be able to help. And, somehow, it actually worked out — the team pulled it off! One of the junior engineers he had pulled in on a whim — me — just to sit in for half an hour and maybe lend some advice… had not only been key to figuring out the plan of execution, but then stuck around for the rest of the week, diving in headfirst and nearly singlehandedly delivering the server-side components.

Carpe Diem

I often hear questions from other engineers about what sorts of things they need to do in order to get that highest rating — how they can manoeuvre themselves into positions to excel like I did above. It definitely takes some luck to be in the right place at the right time (moreso if you aren’t a white man like me — an entirely different essay) — but more importantly it takes just doing fantastic work when the opportunities present themselves. It may not even be obvious to you the importance of the work at the time! “He was pivotal to saving two conflicting top-level company priorities” is the hindsight story of why I got the highest rating, but I didn’t comprehend that was what was going on at the time. I didn’t step into anything trying to resolve top-level company priorities, and I definitely didn’t search for top-level company priorities to resolve (that way lies madness). I saw an important problem which needed solving, and — whether I was “expected” to do so or not — I dove in and solved it. No one else was doing it, and I knew I could, so it might as well be me.

This is how I think about career advancement. It isn’t about creating bigger and bigger opportunities for yourself — it’s not about selfishly inventing self-serving projects. Rather, it’s about getting better at recognizing and taking advantage of bigger opportunities which are already there and just making things happen. When I first started out, that meant taking an obvious problem which no one else was working on and solving it. As I’ve grown, I’ve gotten better at foreseeing future problems, major product holes, and the like, and organising people to solve them — in other words, finding bigger problems which are obvious to me but maybe not other people. I’m better at noticing when I’m in the right place at the right time.

But in some sense, all of that work is just “lying around” for anyone to pick up — no one else is doing it, so it might as well be me.