Thread by @imightbemary

DS teams' work is often referred to as "consulting," an appropriate term for swooping in and lending your expertise to a group you might not be a permanent member of. I generally find the consultant framing useful, altho at first blush some concepts may not seem transferrable

Take billable hours, for example. Activities that are done in direct service of a client--doing research for their case, planning and executing the work, corresponding with them (in all forms)--the time spent on those things are what you directly invoice your client for.

Any other professional activities you do (like improving your firm's systems or processes, spending time on professional development, or marketing to find new customers) are not things you can charge the client for.

From the client's perspective, it's desirable for any consultant working with them to have a high utilization rate (billable hours / total available hours) on their case. It means the consultant is prioritizing the client above all else, giving them their full undivided attention

A high utilization rate may also be desirable for the consultant. When most of your hours are billable, that means more money in a shorter amount of time

If you're the practice manager of that firm, this means you're in the tricky position of finding an optimal utilization rate among your staff.

Maxing out utilization rate across all consultants might be profitable in the short term, but I'm sure I don't need to tell you that short term optimizations can hinder future prospects.

This is probably already starting to sound like a familiar situation for DS managers, but it does beg the question. What's the equivalent of billable hours for a data scientist?

Simply said, it's visible work. Consultancy is a good analogue for DS work because both are highly stakeholder centric. While DS are salaried rather than compensated for specific tasks, a good relationship with stakeholders is often what earns DS teams to their proverbial keep

Visible work can be many things--pulling numbers, running an analysis, designing metrics or modeling business problems, creating dashboards, fielding the much dreaded "qq" slack DM.

And speaking of slack, participating in stakeholders' slack channels is also a form of visible work. Spending time with them and immersing yourself in their concerns is a form of research that they can immediately recognize, even if only subconsciously.

Other forms of participating in your stakeholders' world can have a similar effect. Attending their team meetings, adding excitement in email threads announcing wins, and even joining their social events can be ways to increase visibility and build trust with your stakeholders

What DS work is not visible then? Attending DS team meetings, building foundational data pipelines or analysis libraries, reviewing teammates' work, setting up development environments, interviewing for other teams, learning new tools or skills... a lot of operational investments

If you're a DS manager, the non-visible stuff is crucial because if you aren't making sure it happens, it's unlikely that anyone else will.

Yes, visible work is a form of currency within a company--it gives you a lot of leverage, so long as it's balanced with the ability to make investments back into your own team's operational capabilities

Probably every DS has worked with stakeholders who had high expectations of speed and quality and no appreciation for the supporting infra. Visible work is great until stakeholder demands start drowning the folks on the frontline

How you think about maintaining this balance will be specific to your team and company, but it's worth talking about factors that influence your tilt towards visibility or team investment, as well as what stakeholders perceive your utilization rate to be

Impact vs. level of effort is an alright starting place but IMO too high level. When thinking about what work to take on, here are four other dimensions to consider, roughly in order of increasing visibility to stakeholders (probably on an ordinal rather than continuous scale)

First: what is the state of your supporting infra for this stakeholder request? The 90-bajillion-percent of DS time is spent cleaning data is a direct consequence of this. If the data is shit quality or no one has ever worked with this data before, your infra will slow you down

A DS's visible hours will be much lower if they have to do a significant amount of data cleaning or infra set up. This will impact the stakeholders perceived utilization rate, so TELL THEM if this is the situation.

Second: what is the skillset of the DS team? This is partly about subject matter expertise, which has a huge impact on how quickly a DS can solve a problem, but it's also about the seniority of a particular DS.

Juniors need more help structuring work and identifying relevant datasets and techniques. Stakeholders rarely know the difference (and probably don't even know the level of a DS), so it might not occur to them that a given DS really IS spending all their time on an project

Third: the interests and morale of your team can have a big impact on how much effort they give to a stakeholder request. Stakeholders might not care if a DS feels like a project is growing their skills, or if the DS feels burnt out from always fielding urgent inbounds

But they CAN tell if a DS's heart is not in something. Interest and morale are more visible to them than the former two points, and even if they're getting what they need from a DS, they may still think a DS is not spending enough time on their work if the DS seems unengaged

Thus, DS managers should keep an eye on interest and morale. You can't always give your team the work they most want, but when the team can give energy to a project it's perceived as spending the right amount of time on it, even if the DS is spending a lot of time on other things

And fourth is the compatibility of a DS and their stakeholder. Not every pairing of personalities will work well together, and as a DS manager, you can only do so much to smooth that over.

There are many ways that a chronically unhappy team member makes your life as a manager difficult. And a stakeholder who's dissatisfied with the level of service they receive from that unhappy DS can also find many ways to make life hellish

If your team is unhappy or your stakeholders are unhappy, you're in for a rough time, and it only gets rougher when they're at each other's throats. If working with a stakeholder makes a DS bristle, the stakeholder will think a DS is using their time poorly almost no matter what

Avoiding personality mismatches is a good way to control perceived utilization rates up front, and in general, will save the manager a lot of interpersonal-drama-induced headaches.

Each of these four things is a rich topic in and of itself, and even though they're not all equally visible, each has an impact on how stakeholders perceive a DS's work. DS managers don't necessarily have to talk about these factors, but they absolutely should keep them in mind

Visibility is an important organizational currency to accrue, but it's a currency that's also easy to spend quickly. Investing in your team and infra will enable you to expand breadth and depth of your team's work, and make it possible to do even more visible work in the future

Seeing is believing for stakeholders, but one can not live on belief alone.