SOURCE: Pixabay

When to Be Cautious About Sharing Data

Thomas Nield
97 Things
Published in
3 min readMay 16, 2019

--

When I was fresh out of business school, I was taught that silos are bad and toxic to organizations. When people and departments become too secluded and inwardly focused, all kinds of corporate dysfunction can happen. Redundant work becomes commonplace, contradicting and competing objectives undermine the efficacy of the organization, and valuable data that could benefit everyone stays locked away with its owners.

While these concerns are valid and do happen, I have learned that bureaucracy and silos sometimes exist for legitimate reasons. Data can especially become a political and organizational headache if it is made available to too many parties. “Why?” you ask in a surprised tone. “Is it not great to have transparency and open data to drive analysis and innovations?” Well of course, but it is a balancing act and it depends on the situation.

I will get the obvious reasons that you should not share data out of the way first. If the data is sensitive, then it is best to give access only on a “need-to-know” basis. If the database is vulnerable to heavy traffic and expensive analytical SQL queries, then that is another obvious reason to not provide access. Typically, in that situation, you would provide a replicated database used for analysis, so it does not impact the production database.

Now I want to get into the less obvious reason: sometimes domain experts should have exclusive access to a database and be the gatekeepers for it. I know this sounds bureaucratic and terrible, and I too hate the phrase “leave it to the experts”. But bear with me.

Sometimes it can be difficult to navigate and interpret specialized data correctly, because doing so requires an immense amount of domain knowledge. If you know nothing about revenue forecasting, do you really have any business going through a revenue forecasting database? Maybe you should ask the revenue forecasting people directly for what you need! They know that data, the business it reflects, and which fields require a “WHERE” condition for your inquiry.

Say Joe works for a Fortune 500 company and transitioned from one department to another. His new department asks if he could pull some strings and help get access to forecasting data from his previous department. Joe rightly tells them the implications of what they are asking for: the data is complicated and requires full-time expertise to interpret it. It is not the type of database to browse casually, and it is easy to query incorrectly.

Not to mention, if Joe’s new department starts doing his old department’s work… well, that’s going to complicate their organization and this will perhaps step on some toes. When it comes to forecasting work, where should budget and talent be put now? Both departments? At best this may be a necessary organizational change, but at worst can be a bitter and unnecessary political struggle.

Delegating responsibilities (and the data that goes with it) in an organization is no easy task. Centralizing data and making it accessible to as many stakeholders as possible is a noble objective, but it’s not always practical. Some data should be shared more openly, while other data should be exclusively kept with its full-time experts who know it intimately enough to use it correctly.

--

--

Thomas Nield
97 Things

Author of Essential Math for Data Science (O’Reilly) and Getting Started with SQL (O’Reilly)