fbpx
Nick Rockwell Image
Nick Rockwell, Senior Vice President Of Engineering & Infrastructure at Fastly

Aligning Tech and Business Goals: An interview series with Fastly’s Nick Rockwell — Part 1

November 25, 2021 in Work out loud

Matching your businesses’ long-term vision with the day-to-day realities of running a technology company is one of the hardest challenges faced by growing startups. Commit’s Sarah Marion hosted a conversation between Commit Engineers and Nick Rockwell, VP of Engineering and Infrastructure at Fastly, to talk about how to find alignment between technical and business goals, how to invest in a performance culture at very early-stage startups, and the role of a technical leader in building trust with business stakeholders. Read the second post here and the third post here.

On how to measure performance 

Sarah Marion: When you left your role as CTO of the New York Times you wrote a piece about how you wanted your performance as leader of a technology organization to be evaluated according to the business metrics that the entire company is assessed by, which I thought was quite unique. Why was that the way you wanted your tenure at the Times to be evaluated?

Nick Rockwell: I think I would put that in the category of ‘hard-learned lessons over the course of a long career.’ 

By the time I got to the Times I decided that was what made the most sense, because the alternatives weren’t great. There are various output and productivity approaches to measuring the performance of an engineering team that can be fairly seductive, and some of them can be useful for internal consumption. They can help you identify problems and debug, or to ask interesting questions within the context of a team, but outside that context they’re almost always useless and usually harmful.

So ultimately the reasoning is pretty simple: other strategies don’t work as well. Even trying to focus on something as simple as output is just an attempt to insulate yourself from the rest of the business. It’s sort of like, ‘if I’m producing the output that I’m expecting to produce, and the rest of the business is failing, it’s not my problem.’ Which is not a healthy attitude. So I went in the other direction and decided that we want to share the goals that our product, marketing and business partners hold. 

And that’s actually the more important point: If you have your unique set of engineering metrics and the business people have a bunch of different metrics, you are going to be misaligned. Sharing the same goals helps you fight that. 

It also forces you to constantly think about what you’re doing in engineering, whether it’s big decisions about tackling technical debt or a process question. Whatever you’re doing, you have to tie it back to how it’s going to benefit the business. That’s just a healthy habit and discipline to live by. 

The funny thing is—I found that the business people didn’t really like it. It took a lot of convincing to get them on board. Everybody thought I was trying to wiggle out of some kind of accountability. So it took a while, but we talked it through and we got to a place where it made sense, so we dove into it.

Sarah Marion: As a leader in an organization, you’re spending time on higher-level, more strategic discussions that your engineering ICs might not be participating in. I’m curious how you tie technical metrics they’re directly impacting into those North Star business KPIs that can feel more disconnected from their daily work.

Nick Rockwell: The truth is that performance and uptime are actually pretty easy to connect. You can often quantify the impact of performance or uptime—performance can be a bit harder, particularly at media companies where it isn’t a great proxy, but for e-commerce it obviously is. At the time, selling subscriptions was the thing that we cared the most about, so that distinction didn’t matter. 

Other things are a lot harder. Tech debt is definitely the hardest—it’s extremely difficult. You can’t honestly tie the impact of tackling tech debt directly to some business outcome most of the time.

The other thing that’s really difficult is feature work, especially if it depends on how disciplined your product team is. The fantasy is that everything we do, every feature we build, we’re going to A/B test against our key metrics. In reality it’s not possible to do that.

The best thing you can do in that situation is to think harder about it and ask yourself why this is good for the business. Even if you can’t absolutely quantify it, thinking hard about it is the next best thing. That’s my approach.

Sarah Marion: I’d love to get into tech debt and how it relates to KPIs and performance. How do you set expectations with the business team around tech debt, as they probably have other priorities?

Nick Rockwell: Sometimes you can make a clear case based on impact to a KPI, but a lot of the time I don’t think you can. Twisting yourself into contortions to figure out a way to do it is not a good use of anybody’s time. It’s slippery to say, ‘If we do this work, we’re going to be more productive.’ Although it’s often true, it’s difficult to prove and it sends you right back to productivity metrics. So I steer clear of it if possible.

To me the foundations are trust and opportunism. The first thing you have to do is earn the trust of your business partners, because at the end of the day the most effective way to mitigate tech debt is to say, ‘Trust me on this, this is really important.’ Even if you can quantify it, it’s often too hard to make the case to people who don’t have the same understanding as you. They don’t have the instincts and they’re not going to see what you see. 

The other thing is opportunism. There was a long period at the Times when the product team was in disarray. We didn’t have a roadmap and nobody knew what to do. One day I said: ‘We’re going to re-platform.’ That’s where we started, and we did 80% of our big cloud migration, which included a whole lot of rewriting. We took advantage of a window where there wasn’t a lot of other productive work going on. 

That’s less likely at a small startup where you’re starved for resources and there’s so much to do. So it’s not going to happen as often. But in a bigger company or at a pivot point when the company’s really re-evaluating, that could be a great time to just do it. 

Sometimes I didn’t even tell the business everything we were doing. I didn’t want to rub it in their face that we didn’t have anything else to do. We would just do it. I think that’s okay too. That should fall within the purview of the judgment of technical leadership.

# # #

Get Commit news in your inbox!

* indicates required