What does it mean to be a cost center?

When I shared my piece on Measuring an engineering organization, one point I made was that focusing too heavily on optimization metrics (e.g. things like CI/CD time) can turn engineering into a cost center. That’s not because optimization metrics aren’t important, they’re extremely important! Rather, it’s inherent to what it means to refer to an organization as a cost center.

First, an obligatory definition from Investopedia:

A cost center is a department or function within an organization that does not directly add to profit but still costs the organization money to operate.

That’s a pretty dry definition! In practice, “cost center” is often tossed around to refer to an organization that is underfunded and whose requests are held to a higher standard. One painful real-life example came from friends at a well-known tech company where only engineers were allowed to eat the free lunch. Other organizations were not invited. When your expenses are being monitored so closely that your organization is excluded from free lunch, that is being a cost center.

However, I think this common usage isn’t very helpful. If “cost center” just means that a function feels underfunded, then every function probably feels like a cost center in a funding era like 2022 when companies are slicing valuations, struggling to raise additional capital, reducing hiring plans, and frequently laying off large parts of their existing teams.

I’ll offer a definition that I find more helpful:

A cost center is a function that is operated by optimizing its existing components.

This definition gets at the root of why I think explaining engineering’s contribution through optimization metrics is a flawed endeavor. When engineering departments ask their CEOs and Boards to evaluate them through the context of optimization metrics (“cycle time decreased by 20% QoQ!”), they are training those bodies to evaluate them as a cost center.

For example, let’s say that you’re reporting on cycle time, and that cycle time has gone up. There’s a potential problem to dig into there, and you will likely create some real value by addressing it. However, what if cycle time went down: that should mean that you’re doing well as an engineering org, right? It might, but it might not. You can be a very effective engineering team and deliver very little impact because you’re shipping the wrong work. You can even be a bumbling, inefficient engineering team but still deliver significant impact by shipping the right work.

Disproportionately impactful engineering teams are distinguished by effectively shipping the right work. System optimization is part of that remit, but only part of it. The larger aspect is shipping the right work, and that’s an aspect where your CEO is actually well-positioned to help you. If your CEO is in the trenches working with you on reducing your build times, then you’re in a lot of trouble (either they aren’t doing their job or they are doing their job and they think you are not doing yours). You should be optimizing the engineering organization’s operations, and should rarely need to surface those details upwards unless you want to occasionally brag (yay, we’re good at this), are asked to provide deeper context, or need to justify an investment.

Conversely, pushing the company to pick the right work to do is very much in a CEO’s wheelhouse, and a place where you should be escalating to get visibility, alignment and support. The first rule of managing up is to focus your manager’s attention on areas where they will be useful and you need help.

Anyway, optimization metrics are very important to running your organization well, are terrible for reporting upward, and don’t forget to focus at least as much on what the team is doing. Most engineering managers default to a focus on efficiency, but in an executive role, you’re held to outcomes first and foremost, so don’t necessarily focus where it feels most comfortable.