Data Careers: Dealing With Being in a Cost Center

Those of us who work in the tech industry face a fairly unique problem that I like to call the ‘cost center problem’.

The problem is this: every business is divided into parts that are considered cost centers, and parts that are considered profit centers. To hear Patrick McKenzie explain it (in Don’t Call Yourself a Programmer):

Peter Drucker — you haven’t heard of him, but he is a prophet among people who sign checks — came up with the terms Profit Center and Cost Center.  Profit Centers are the part of an organization that bring in the bacon: partners at law firms, sales at enterprise software companies, “masters of the universe” on Wall Street, etc etc.  Cost Centers are, well, everybody else.  You really want to be attached to Profit Centers because it will bring you higher wages, more respect, and greater opportunities for everything of value to you.  It isn’t hard: a bright high schooler, given a paragraph-long description of a business, can usually identify where the Profit Center is.  If you want to work there, work for that.  If you can’t, either a) work elsewhere or b) engineer your transfer after joining the company.

The tech industry is unique in that tech workers can work in both parts of the company. If you're working on Search at Google, for instance, you're working in a profit center; if you maintain servers at Citibank, you're pretty much working in a cost center.

The tricky thing, of course, is that if you work in data, the odds are good that you are considered a cost center. You aren't, after all, critical to anything that the business does. This then implies that when the business isn’t doing so well, data professionals who provide ‘decision support’ are considered less valuable than other roles, and are more likely to get the axe.

So what do you do in this situation?

Dealing with the Cost Center Problem

A few weeks ago, data scientist Randy Au wrote a piece about his experiences with exactly this problem. He titled the post ‘Showing value as a support data scientist’, and that last phrase is key — Randy asserts that there are basically two types of data science roles, and one of those types will have a harder time proving value during performance review. These two types are:

1. ‘Product’ data science roles — that is, data scientists who ‘create tools and/or models for use by end users’ and
2. ‘Support’ data science roles — these are data science teams who provide a support function to other internal teams.

You’ll notice that the two categories map pretty readily to ‘profit center’ and ‘cost center’ — Randy points out that people in the first category are less likely to lose their jobs when times are bad, as compared to the people in the second category. Sharp readers will say “well, if there are two kinds of data science roles, then obviously you should aim to apply for the first type and ignore the second category, right?” The tricky thing, of course, is that many jobs in data are in the second category: for instance, data analysts in business intelligence roles are de-facto ‘support’ types. So you often don’t have much of a choice.

There’s also a subtler problem if you find yourself in a support role:

The core of the issue is how support DS teams usually work on things that are far away from a source of revenue, so they have to fight against the perception of being merely a cost center. These teams are usually supporting product development, or providing research and analysis to make various teams more effective, oftentimes there’s a fair amount of small, disjointed, ad-hoc data work from various corners of the company.

These teams have trouble saying “We built X!” because their actual work was helping engineering, product, and design understand and think about X, then those people put their own unique creative processes into X before end users see it. It’s very squishy and hard to be definitive about “we contributed this specific part”.

So what do you do to deal with this dynamic? The answer, Randy says, is that you should keep a brag document.

Maintain a Brag Document

A ‘brag document’ is a document that keeps track of your accomplishments. This way, it becomes easier to justify a promotion when it’s time for perf review. This isn’t a new idea by any means — career guides have been recommending it since the 80s or 90s. The best article I know on this practice comes from software engineer Julia Evans. You can find her guide to writing brag docs here.

Don’t let the name repel you. Evan says: “Where I work we call this a ‘brag document’ but I’ve heard other names for the same concept like ‘hype document’ or ‘list of stuff I did’” Evan also pre-empts those who don’t like to brag about their accomplishments: “You don’t have to try to make your work sound better than it is. Just make it sound exactly as good as it is!”

A brag document, Evans continues, should contain a number of things:

• She recommends writing the doc in a format that you can share with your manager and/or peer reviewers (if that’s a thing at your company). This feels a little uncomfortable, but it makes things SO MUCH EASIER for them to do their job that they will appreciate you for it.
• You should take the opportunity to explain the big picture at the top of the document (e.g. “this quarter I helped the company identify dropoff points in our activation funnel, and cleared up a ton of report debt”). Evans notes that this practice is very similar to veteran manager Will Larson’s recommendations around Career Narratives.
• Brag documents also allow you to notice patterns in your work over a period of time. Evans prefers to write hers once every 6 months, instead of the recommended once every two weeks — the longer period allows her to see the bigger trends in her work.
• Finally, Evan encourages you to include all the fuzzy work you’ve done over a quarter; things like “improving code reviews” and “making on-boarding nicer for newbies on your team.”

Evans’s guide is good, and I encourage you to read it in full. But Au takes this basic idea and adapts it for the specifics of a data role:

• In addition to maintaining a brag doc, Au has dates prefixed into the name of every file he creates (in ISO8601 format, because of course he would). This includes every analysis, every query, every spreadsheet, and every document he works on as part of his job. Adding dates like this augments his ability to quickly check over all the assets he has produced over a certain time period; he also creates short documents with links to collections of such files, in order to quickly piece together what he’s done, come perf season.
• Au keeps tabs on every project he’s influenced. This is a lot harder than it sounds — he notices that often, product teams will take months before they launch anything that produces a measurable impact. In the meantime, the challenge is to stay in the loop, and to keep track of one’s contributions to those product teams.
• Finally, Au attempts to stay visible, because “you don’t want to be in a situation where you’re taking credit for some contribution to a thing and everyone doesn’t even remember you were in the room.” This means things like occasionally stepping up to present your work to a wider audience, or selling your support — you know, the usual big company stuff.

There are a few other tips that Au covers that I won’t include here (because you should go read the original post!) — like learning to say no to projects with limited impact and attempting to calculate the $$$ value of your support work anyway, no matter how difficult that might be.

But at the end, Au closes with a sobering note:

Will these methods save you if large staffing cuts are coming? Probably not.

They certainly didn’t save me the two times I’ve been hit with the layoff axe over the years, both at places where I had time to build strong relationships and was generally well known for the work I did.

Being let go just meant the organization was willing to fly blind without detailed analytics insights for a period of time. (emphasis mine) That risk of making bad decisions (that can always be fixed with a patch) wasn’t worth my salary when a manager somewhere needed to hit a cut quota.

When it comes to making hard budget cuts and figuring out who’s left behind, the decision becomes cold pragmatism and retaining the ability to launch any feature at all is usually prioritized over launching good features.

When this happens, the last thing you can do is, if you’ve been keeping track of contributions you’ve been making over time, you can take those stories with you to demonstrate your potential value to a new employer.

If there’s one lesson I’ve learnt about careers, it is that you can’t really escape the realities of your employer’s business model. And the reality of data-oriented careers is that they are — in the vast majority of cases — a career in a cost center. Au’s and Evans’s techniques may help a little, but there’s only so much you can do.

The implication here is that you have to be aware of the cost center problem if you want to embark on a career in data. This means all sorts of things: it means things like evaluating your employer at the interview, picking healthy companies that are unlikely to do layoffs (hard!), all the way to cultivating relationships with product teams and maintaining a visible presence within your company. As Francois Chollet said in a Twitter thread recently:

This is simply a reality of the industry, and while it's not necessarily a bad thing, it’s still one that we have to learn to grapple with.