Taking the Red Pill

When I’m interviewing candidates for RichRelevance, I always give them an opportunity to turn the tables and ask me questions at the end of the session. If I’m the last interviewer of the day, the hapless candidate is often so drained that the questions I get tend toward, “Could you remind me where the bathroom is please? I seem to have drunk rather a lot of your coconut water” or “Is that it? Are we really done, or are there more of you?!”

Occasionally, a savvy candidate will inquire about my previous job, before I joined RichRelevance.  When I say that I was a small fish in a big pond, they are often curious about what it was like to transition from such an organization to a small, nimble firm like RichRelevance, especially if the candidate is also currently employed in a corporate behemoth.

One word: “Awesome.”

That’s a word you hear a lot around the RichRelevance offices, even from me.

Then I remember my British roots, compose myself, and elaborate on my answer.

What was that transition really like?  Admittedly, it was initially scary.  My performance at the “Big Pond” was often measured in terms of my conformance to the process, by how well I followed the rules and procedures, rather than on “product” delivered. In many ways the process was the product.  The challenges I faced were often not those my engineering background had prepared me for. Instead, I found myself coming up with innovative ways to work around entrenched bureaucracies, fiefdoms, and archaic, often pointless processes.  In such a huge company, I often felt my contribution got lost in the noise, that it made little difference to the company’s success.

Compare this to life at RichRelevance.

Here, I get to do some real coding.  In fact, I sit right next to my boss, who also codes.  How cool is that?  Sure, I now have concrete deadlines—perhaps measured in days, or hours, rather than months—so inevitably, I’ve grown accustomed to, and even come to appreciate, the ever-present chaos that is part of startup culture.

Product requirements?  Sometimes they’re vague, contradictory, or simply don’t exist.  Priorities shift constantly.  I’m expected to learn new technologies in a matter of days, with only my wits, experience and StackOverflow to rely on. Extra hours may be devoted to helping pitch products to customers or giving technical presentations at Meet Ups and conferences.  But in the end, I thrive on it all, on taking ownership and responsibility for everything I do.

In return, I get to be surrounded by some of the sharpest, most humble, wicked-smart people I’ve ever met–people who will drop what they’re doing without hesitation to help me out when I need it, knowing that they will then have to work late to catch up on their own tasks. I have Nerf gun shoot-outs with my colleagues, import code written by the CEO years before when the company consisted of three people, and play ping pong at the end of a long day when I just can’t chase that Hadoop bug any longer. (The answer will come to me during a particularly well-executed forehand topspin. Aha! Take that, recalcitrant Mapper class!)

Between the passionate technical discussions with my teammates on how to squeeze an extra few percentage points of performance out of a message consumer application or what’s planned for Java 1.8, or Scala syntax, I know in my gut that what I’m doing makes a difference, in a very direct way, to the company’s success.  The results of my work are deployed to the production environment rapidly—sometimes frighteningly so—generating revenue for the company, helping the system run more smoothly, or just making other developers’ lives easier.

So, how is it to transition from a large corporate environment to a scrappy start-up?

Yeah, “awesome” is about right.  Just try sending me back. I’ve got a Nerf gun and I’m not afraid to use it.

Did you have any more questions for me?  If not, please help yourself to a coconut water on the way out. We’ll be in touch.