Unfortunately, this often ends up producing a team of data cops. A team more interested in enforcing how others should use their tools rather than producing value with data.
I think there's a much more effective approach.
Instead, consider your new data team to be a startup inside the company: making and selling a product. Your product is the data; and intuition and judgement are your entrenched competition.
You're probably the sort of person to whom it's obvious that people should be using more data in their decisions. You probably shiver every time you hear someone say they are basing their decisions on their strongly held beliefs that have no evidence to support them. But you may not realize how un-obvious this is to everyone else.
In order to succeed as a data team, you're going to have to learn to be operate like a successful startup.
That means that just like any founder, you're not just a developer. You're sales. You're support. You're the number one advocate.
And you're going to have to hustle.
Don't make people's lives harder. Don't be confused in thinking that the rest of the company (your customers) are going to put in extra effort to deliver your data ready to be consumed. Don't try to start putting impositions on product development to make your life easier. Startups that make a product that puts demands on its users rarely survive. To put it simply, you work for them.
Make people's lives easier. Adopt work that existed before there was a data team, where that makes sense (eg: take on log maintenance). This is what all other teams do when they form. A new design team is responsible for the landing page design even if it was originally designed by a developer. Startups that solve a previously unsolved problem rarely take off. Take on the schleps.
Anticipate opportunities for data to be the answer and then have it ready. A friend of mine recently told a story how when he was in the t-shirt business he'd respond to potential contracts with custom shirts in the bid. When you see an opportunity for data to make your business better build it, don't argue for it. Big pitches don't sell. Big pitches that don't even have a screen shot really don't sell. Having the product ready and pre-configured sells.
The word no isn't in your vocabulary anymore. When you have succeeded in gaining some interest, don't turn around and tell them "well, that's not actually what I'm building". Successful companies pivot in response to demand; and so do you. I'm not saying you have to be a GIGO machine that answers every question you are given. But every request is a lead; and every lead is gold.
Communication will make you or destroy you. What's worse than having bad data? Having to discover for yourself that the data is bad. You will make mistakes. But you also need to earn trust. People will learn to trust you are providing good answer when you pro-actively and aggressively communicate where things have gone wrong.
Learn to take the blame. In general, learn how to provide customer service. For example when someone has a data need that your tooling can't handle instead of responding by saying "well, you can't really do that because that request is kind of unreasonable" try
That's a totally reasonable request and I can understand why you'd want that. Embarrassingly, the tools we've setup don't actually support that yet. But let me come up with something that will solve your problem for now.
Try to remember you're not telling people to eat their vegetables. It's very easy to be seen as the doctor saying "if only you were to eat all your vegetables you will eventually appreciate them". But you're not offering vegetables. You're offering pie. The pleasures of using data is almost immediate and it never gets old (just like pie). So while you are competing with an entrenched product (intuition) your competition doesn't have what you have. You have pie.
2 comments:
I've grown to dislike the idea of having a data team, no matter whether it is product based or consultancy based.
What you need as a startup is two things:
- The engineering capability to collect data so it can be analyzed later.
- The business/product capability to make proper data-derived decisions.
Long-term, having a single "data team" is detrimental for both of these capabilities. (Hyperbole alert:) a data team like this will end up fixing poorly engineered products that do not collect data properly, only to analyze this data to support decisions that are made on instinct anyway.
So, it's better to invest in finding people for your engineering that know how data analysis works and what kinds of data need to be collected, and executives and product managers that know how to properly make empirical decisions based on the collected evidence.
Eventually, you will need to invest in infrastructure to be able to collect and analyze the growing amount of data that is being generated. At that point, a data infrastructure engineering team becomes an option, but this can and should be put off for as long as possible.
Later, a third capability could become useful as well: the capability to build products that build on the vast amount of data you have collected (recommendation engines, etc.) A team like this can best be organized as any other product team (product manager, designers, developers), with a data expert mixed in for extra flavour.
@willem While I understand your point I think it's somewhat orthogonal. That is organizations grow in all sorts of different ways into all sorts of different structures. Some will organize their teams to cover different problems. Some will organize their teams by different skill sets. In some of those cases there will be something called a data team.
I suspect successful organizations are like Tolstoy's unhappy families. There's no real blueprint.
At the same time there are a group of people who enter organizations at various times whose background or inclination skews more towards statistics than those there before them. Often they are confused and struggle with how to interact with the rest of the organization. Whether they organize themselves into a data team or not this blog post is an attempt to help them.
Post a Comment