The modern tech industry is generally built around a culture of collaboration. The stereotype of the introverted coding genius engineer has basis in reality. But it’s also not representative of any tech team I’ve been on that ships product. Every tech company I’ve worked for has mainly built and released product through cross-functional development teams consisting of engineers, designers, product managers, and usually also data scientists or product analysts. Little of the work released by these teams to end users was delivered by someone working in isolation; at minimum, each engineer’s code was reviewed by someone else before it was released. 

In reality, to be an effective contributor at the typical tech company, I think you need to be good at working as part of a team and at communicating well with other people. And of the four core disciplines, I think it’s the data scientists or analysts who most need to be good at communicating with others and selling their ideas. Even more so than for product managers, whose job is often defined as being all about communication and selling – I think these skills are actually even more important for analysts!

It’s easy for data scientists to emphasize the technical skills which are the true core of our role and what differentiate our jobs from everyone else in tech. But unless you’re the type of data scientist who writes production-facing code (in which case nowadays you are probably called a Machine Learning Engineer or Applied Scientist, instead of a Data Scientist), you cannot run away from needing to communicate your work and ideas to your colleagues: I’d argue that if you can’t do this, you can’t actually do your job.

Think About How Your Work Creates Value

If you consider how analyst teams were traditionally organized in pre-internet companies, this was a role that most naturally sat in the Finance organization. To the extent that you needed someone technical to be responsible for managing the database systems analysts use for their work, they probably sat in the IT department. In other words, the Data team at traditional companies is a cost center.

A “cost center” is fancy corporate speak for something which has to exist and is thus a mandatory expense, but doesn’t otherwise create value for the business. There is no logic to investing in a cost center, because you can’t multiply the value of your business that way. Compliance, Catering, IT – all these teams are examples of other cost centers. They are valuable teams whose work is critical for the success of the company, but also teams that you generally won’t want to spend more on than you have to. This contrasts with a “profit center” which refers to something that can grow the value of your business the more you invest in it. The Marketing and Sales teams are usually a profit center; the team that builds the product you sell is usually by definition a profit center.

Analysts historically existed as a cost center because every company needs to count stuff, but you typically don’t need to invest in better counting to grow your company’s profit. Until software began eating the world, traditional companies also regarded their software engineers as cost centers.

If you sell credit cards like Capital One, where I started my career, you probably wouldn’t have seen software engineers as a profit center – your product was credit cards, not software. Now that apps are such a critical part of how we experience virtually every service we interact with, more and more companies regard their engineers as a profit center. At Capital One, I think they made this transition around the time I left, about a decade ago, when the CEO and founder very publicly told us all at his annual all-company meeting that the company was going to launch a new round of investments in its APIs, and hire software teams accordingly.

As an employee sitting in a cost center, it’s not your job to think about business value. Your job is to do whatever it is you do well. The people working in profit centers are the ones who have to worry about creating value for the company through their work. Analysts sitting in cost centers aren’t paid to think about how to grow the business; they are paid to do whatever analysis the company needs them to do. What does the company need? Whatever the profit centers say the company needs.

One of Silicon Valley’s innovations in staffing is how they created a culture of profit center operations among functions that would have been cost centers at traditional companies. At traditional companies, software engineers sitting as a cost center would be told what to build by product managers, who constituted a profit center. Designs would be sketched by designers, another cost center, based on edicts from the product managers.

When I worked at Capital One, one of my last projects involved adding functionality to the website that would allow credit card customers to close their accounts online. This decision was not initiated by the product managers, engineers, or designers responsible for the Capital One website. Instead, my team of analysts in the US Credit Card business unit decided this would likely be a good idea. My job was to present an analysis that would get our executive to approve allowing our customers to close their accounts online. Once the decision was approved by our executive, a team of product managers, engineers, and designers was told to go ahead and build it.

At virtually every Silicon Valley company you’ve heard of, this top-down culture where someone from the business tells everybody else what to build is uncommon. I’ve never heard of a modern software company running a process like the one I went through at Capital One. Modern software companies typically make decisions about building their product through “cross-functional teams” consisting of engineers, designers, product managers, and analysts. Decision-making over what to build and how to build it is typically shared by the team. The product manager and an engineering leader will usually have the final say, but the team is otherwise expected to make their own decisions within their area of the product: it would have been the cross-functional team, not a bunch of executives, who would have owned the decision to build a way to close your credit card account online.

In other words, in Silicon Valley, all the technical functions are profit centers. Unlike a traditional company where the business tells the technical functions what to build – treating engineers and designers no differently than IT technicians – in Silicon Valley, especially in startups, it’s expected that technical teams understand their area of the business enough to make decisions about it. Most individuals on the team don’t need to understand the business in depth, but they do need to understand enough to participate in discussions about what their team should do for the business.

In small startups, there is often no business team responsible for making decisions while insulating technical folks from the business – it’s often just a bunch of technical people trying to build a business together. And this culture seems to have successfully scaled in the tech industry far beyond small startups that don’t have formal business teams: I can’t think of a single Silicon Valley company I’ve heard about that doesn’t operate or say they operate along the lines I’ve described. I think this is one of the most powerful aspects of startup culture: a bottoms-up, quasi-democratic approach to making business and product decisions.

Because most individuals in tech share responsibility for decisions in their area, they have to be cognizant of how their work is going to create business value. Team leaders – typically the product manager or the engineering leader for the area – have to present the team’s decisions to higher-ups to get sign-off for the team’s roadmap. You can’t build whatever cool thing you want to without being able to articulate a business case for it.

Analysis Has No Intrinsic Value

Trying to build cool stuff is however a very common pitfall for junior analysts trying to spread their wings. In my career I’ve sat through countless presentations of very technically challenging analyses and models which only served to confuse the non-analysts in the room. Much of the time, the analyst responsible was left confused: they did difficult, challenging work to answer the question they were asked to tackle. What went wrong?

I’ve helped draft a charter for an analyst team many times in my career, and one thing I am always at pains to stress is: the team’s work creates no value in of itself. The point of having an analyst is not to produce analysis for its own sake. Analysis has no intrinsic value to an organization. The point of having analysts is to create a shared understanding of the business grounded in data for the sake of expediting decision-making.

When interviewing for their jobs, hiring teams look for analysts who can do rigorous, technically sound analysis. But in practice on the job, business stakeholders are often just asking them for a bunch of numbers with little care for the process of coming up with those metrics. Many analysts thus get caught up in trying to produce every single number they’re asked for, or produce increasingly sophisticated and technically-challenging work, thinking this is how they’ll burnish their credentials for a promotion.

To me, this is falling into the trap of acting like a cost center. More than once I’ve heard executives complain about a data team behaving like a bunch of “ticket takers” – people who see their job as purely responding to requests for data. In any organization, the IT and HR teams largely operate as ticket takers – that’s not all they do, but it’s a big part of what they do: they are cost centers. But data teams that act like cost centers are typically acting counter to  what startup culture expects of them.

When chartering a team of analysts, I aim to make it clear how the team’s work is supposed to create value for the business – it has to be clear that we are a profit center, and we will act like one. This means that while delivering sound analyses is a critical and necessary part of the job, it is not sufficient: our job is not done until our analysis has made an impact on the business.

I often make this point by reminding people that unlike engineers, designers or marketers, analysts don’t build anything that gets put in the hands of users. Unlike product managers, analysts don’t have any formal decision-making authority over the roadmap or the strategy. Our job thus creates no value for users – or the business – unless and until we do something that helps the other members of our cross-functional team do their jobs better. We can’t build a product – but we can be a force multiplier for the builders, if we do our jobs right.

This is very easy for analysts and data scientists to forget. It’s easy to fall into the trap of thinking that if we just complete enough of the data requests that have been sent to us, or if we can finish a technically-impressive enough analysis, that we’ve done something valuable. People who work in cost centers do typically generate value for the business by cranking through tickets faster, or by being more thorough in their work. But if you work alongside technical teams or business leaders, and are compensated as if you’re a member of the technical or business teams, you’re expected to behave as a profit center.

Some analyst and data teams even in technology companies are explicitly chartered as cost centers. For example, HR Analytics and often Finance teams are thought of as cost centers, even if their leaders hasten to point out all the ways in which their teams’ jobs are about creating business value rather than purely cost minimization. But in every technology company I’ve worked at, most analysts and data scientists are staffed in teams that I would consider to have been chartered as profit centers. If your job is to work directly with and advise a key decision-maker in the business, such as an executive or product leader, you are supporting a profit center – which makes you a profit center too.

Analysts Create Value by Informing Business Decisions

As much as executives love to say they make data-driven decisions, and as much as everybody in a modern business complains they are flying blind without data, the truth is that of all the profit centers, the data team is usually the first one on the chopping block. Layoffs hit data teams hard because we are usually one of the most dispensable profit centers: technology companies need people who build the product and market the product, but they don’t need people who help them understand how to make the product better. In an economic crisis, the analyst and data scientist are some of the most dispensable roles in a technology firm.

This is why I’ve long been paranoid about making sure my job connects to business value, and making sure I’m working with leaders who appreciate how my team’s work directly impacts their business. While nobody can ever be truly safe from losing their job, making sure the profit centers understand and can personally advocate for the value of your work does go a long way to helping your chances.

And this is the reason I think it’s even more critical for analysts and data scientists to be excellent communicators and salespeople for their work than for functions like product or marketing: we cannot take it for granted that people will understand the value of what we do. The value of a software engineer or designer is self-explanatory. And while it’s easy for technical people to dismiss marketers and product managers as lightweights, these functions also don’t have to advocate for the business value they create: it’s taken for granted. It’s the humble data scientist that will be the first product-facing function, the first profit center on the chopping block when a company has to make the difficult decision to start cutting back.

On the flipside, when a data team demonstrates the business value of their work and embeds themselves as true partners to decision-makers, it becomes easier to advocate for investment. At most startups I’ve worked at, the data team has felt understaffed most of the time: this is because headcount planning for data teams often treats it as a cost center. The chief way I’ve seen data teams successfully get vital heads approved has been pointing to how their work has created tangible value.

For over a decade, I’ve participated in weekly metric review meetings with executive teams – a chief avenue I’ve used to advocate for my team’s value as a profit center, because these meetings actually are one of the few explicit levers data teams have to create business value. A common and understandable pitfall for junior analysts participating in these meetings is to get hung up on the minutiae of the data being supplied and reported to executives. That’s cost center thinking. 

Reliable, accurate data is a necessity for an effective and valuable metric meeting, but it is not enough. The analyst’s first job is to make sure the data they supply is accurate, and accurately portrayed, but that is not enough to deliver value. The value of metrics meetings is giving executives clarity on what’s going on in their business, so they feel equipped to make decisions – even if the decision is only something like which of their direct reports to follow up with, or what questions to ask in another meeting.

To put it more simply, while the way most technical functions create value in a technology firm is by shipping product, the way analysts create value is by running an effective metric meeting. And the way you know you’re running an effective metric meeting is when executives come away feeling clear-headed and satisfied that they’re abreast of what’s going on in their business. This is how I’ve most consistently seen data teams turn their perception around from cost to profit centers.

Of course, meetings with executives and metric reviews are not the only way data teams can create clarity for decision-makers: a lot of the value in an analyst’s work comes from the informal collaboration they have with the engineers, designers, marketers, and product managers they work with day to day. But the most important thing I believe is that the analyst has to create clarity for the people they’re working with. We are hired because nobody else has the time or inclination to understand what the data is saying. This means that until we’ve helped the non-analysts who matter understand the implications of the data, we haven’t done our job; we haven’t delivered anything of value.

So I close by coming back again to the all-importance of communication and selling for analysts: if it is our job to create clarity and understanding of data among people who don’t know anything about data, we have to be brilliant communicators. We also have to be brilliant analysts and data spelunkers, but that isn’t enough: if that’s all we are, we can’t avoid the trap of being labeled a cost center. Not every analyst has to be a brilliant communicator, but every analyst who takes investing in their career seriously cannot afford to neglect their communication skills. Analysis in of itself has no intrinsic value – but when a good piece of data work is explained and presented well, there are few things businesses crave more.