Casey Koon has had somewhat of a non-traditional path into business systems that I think is a bit of a workplace superpower. He was the music director at the UC Berkeley radio station, then an administrative assistant, engineer, product marketer, and product manager before finally landing in the seat he occupies today. 

Which is to say, he’s seen companies from many angles and is acutely attuned to the needs of a business in a way some ops leaders aren’t.

What’s also fun about this interview is I’m going to release it in two parts. The first part (this article you’re reading) was recorded over a year ago. The second part was recorded very recently. That gives Casey and me the opportunity to reflect on what he was planning back then, and fast-forward to see how it went.

Below, I ask him all about how he structures his teams, one big evolution New Relic is going through, and how business systems is growing into a legitimate career path. Read on, then tune in for part two. 

This interview was recorded eighteen months ago and has been lightly edited for brevity.

Yoni Argaman: Casey, please tell me again about your career path. 

Casey Koon: I studied molecular and cellular biology, anthropology, and English, and then yes, was music director at UC Berkeley’s radio station. But when I graduated, I said, ‘You know what? I’m not going to do anything related to my degrees.” I got my first startup job through a loose connection—I was really just an entry-level office manager. Six months in, I got bored and started teaching myself how to code. My work started to suffer and the CEO said, “You know, you’re a horrible admin so we have to let you go. But if the engineers want you, they can have you.” I was like, “Am I being promoted?” and they said, “We don’t want you to feel that way, but basically.” So that’s how I fell into engineering. 

I stayed there three years and got nominated for several Emmys for work I did on TV shows, then left for Electronic Arts. After that, I worked at an education technology startup, and then got recruited to work at New Relic. So to be candid, I haven't worked in any back-office systems beyond New Relic and I learned everything related to that on the job.

Does that influence how you think about hiring for talent versus experience? 

Oh absolutely. I hire for talent. Most people fall into a business systems role and may have the potential but not the exact experience. Yet at the same time, I suppose we did just hire an intern who’s going to be starting in a couple weeks who graduated from San Francisco State University with a bachelor’s in business administration in information systems, and who knew about business applications. And it really surprised me that there are now degrees that cover it.

As every company becomes a technology company, I can see why people are growing interested in this field. 

Can you share how the New Relic business systems team is structured? 

We have two sides that report to one vice president who manages business applications and IT. She heads up our business applications group. I own one side, which I call the general and administrative (G&A) group and the other that’s called the go-to-market (GTM) group. My section is everything related to our finances, people operations, integrations at scale, and a grab bag of related pieces. The other group owns Salesforce, Marketo, and our sales and marketing stack. 

The reason for that divide is to consolidate stakeholders within the company, and define who engages with which teams. I work closely with our finance team, and because our fiscal year just finished, I’m ensuring there are no issues with closing the books. 

‍

How is your stack evolving? 

We’re implementing a CPQ solution for the first time. We’re also replacing our applicant tracking system. And perhaps the biggest: Back in August, New Relic released a brand new billing model that we need to support. We switched from simply a traditional SaaS subscription to also offering a consumption model, and there’s lots of changes needed to make that operable. 

‍

What did you do before those SaaS platforms? 

Good question. I’ve been at New Relic for six years and all those financial systems I inherited were custom. New Relic had this big, monolithic financial system built on Ruby on Rails that held our accounts and users and billing systems and product data—everything, really. That made sense at the time it was constructed. But then they IPO’d a few years before I joined and that kicked off a big pivot to more scalable systems.

This is to say, I’ve always viewed my role as transitioning our back-office systems from a custom stack for an SMB company, to an enterprise-grade SaaS-focused department. I started out managing Rails engineers, and then for the last three years, we’ve been breaking that monolith into scalable third-party systems. When releasing new products, we needed to be more agile than a big code base could support. 

There was this one moment when it became clear and we had to step back and ask, “Are we a billing system company, or an observability company? What should we be investing our engineering resources into?”

And after that, it had to become microservices. 

‍

‍

And what did that mean moving to? 

We adopted Zuora as our core SaaS billing platform. That meant sunsetting everything custom and migrating stuff there. That’s been a year-and-a-half-long project and my work has been figuring out how it will help us continue to scale and iterate on our billing models, which it certainly has. As just one example, we would not have been able to pivot to a usage-based billing model like we did had we been on that one monolithic system—and within five months, no less. 

I’m a fan of simplicity. If you can do it out of the box, do it out of the box. That’s why you’re paying for a SaaS tool. I don’t want my team managing a database of tax rates, or managing invoice posting and PDF generation. 

‍

‍

So is there still a place for customization? 

Oh absolutely. In my mind, you want to hand off everything you can to out-of-the-box functionality so you can push boundaries in other areas. For example, in one of our big pricing models, we sell an annual pool of funds where a customer commits to a dollar value for a full year and we draw down against it, depending on the products they use. It’s about draw-down, not license quantity, so that’s a model tools like Zuora don’t support out of the box. That’s where our engineering effort goes: building customization and logic on top of the platforms. Which, in my brain, is a more efficient mode of engineering because you skip to working on the parts that really add value. You may be limited in some ways compared to greenfield engineering, but you aren’t reinventing from scratch every time.

In an ideal world, I feel that no code is better than full code, but there’s a middle ground of no-code platforms where coding is an option. That’s why I believe Salesforce has been so successful. They’ve built a platform that everybody customizes the heck out of using Apex. 

‍

‍

What’s next for you? 

In the near future, I don't want my teams owning any greenfield applications. Period. If we can do it out of the box, we want to do it out of the box.

Join us for part two, where we follow up with Casey on how his team structure and decision to go all SaaS have worked out.