We are surrounded by skilled people. We are also surrounded by unskilled people. How do we manage such diversity? How can we be sure that our Data setup is the one you need? Discover my thoughts throughout this post, being the first one of a series of posts explaining the foundations of this blog. Want to read it? Avant!
Already as an experienced worker, in my first job as a BI and Analysis "manager" (at that moment I had no clue what a manager was because I never had good managers), I was first required to make an evaluation of their set up on the Data and Analysis department, although they felt very proud of their Business Intelligence efforts. The first question I asked, ironically, was: "Ah, do we have such department"? I was presented a Data Scientist, a Campaign Manager, a guy that was creating some dashboards in Excel, and a self-denominated UX expert. That was the marvellous team. After talking individually with them for a couple of days I came back to my Manager and said to him: "Sorry, you have no team. You have a set of skills but no cohesion between them. You built your Data strategy based on silos!". "What's your recommendation?", he said. The answer was the easiest one I've given in my life: "Burn the silos!".
Is my Data and Analysis setup the right one? Sorry, I would say: NO. I can bet my next month's salary that there are important flaws in the way you've organized your Data, BI, and/or Analysis team.
Before starting, let's make very clear what is probably the most important topic when building your Data team: there is no unique and/or magical solution. Every Data team should be built according to the Business needs, the company culture, the skills available at that moment, the available budget, and a long etc. I'm going to give you the classical consultant answer to the question of how to organize the Data team: "Depends". If you came here wanting to seek a magical solution, this is definitively not your place. Further more, this is not your best job. Building up the best team possible is a tough task, and, for sure, not an easy one. It will require a lot of trial and error and a lot of adjustments.
The basic outcome: what do you expect from your Data team?
I was told many times that the Data and Analysis team should give added value to the company. If you think that a Data or Analysis team should bring knowledge then I must say you're partially wrong. Knowledge is the path, not the mean. The ultimate end of tracking, analyzing, extracting knowledge, etc., is to create action! A feature in the website should not be tracked or analzyed if these actions bring no action to the business. The team should be able to trigger a change in the business when delivering knowledge based on an analysis. If there is no action out of these efforts, then the whole Data strategy is totally worthless.
Simplifying the lifecycle of a Data team, we could say that there are four main steps in an analysis strategy:
In first place we have the business needs. The team should be able to gather them, understand them, and forecast what they could look like, in order to deliver Actions proactively. This implies clear and crystal communication skills with the business owners. Once the need is clear, we proceed to evaluate the availability of the necessary data for the potential analysis (in a separate post I'll come back to this point). Then we analyze, out of which we obtain knowledge. Afterwards we come out with actions: we need to make sure that every single analysis done, every single report delivered, any single data extracted is actionable, in the sense of provoking some change, some further thinking on the management level, or, in the last-but-not-least case, a change of operations and/or strategical decisions. If an outcome is not actionable then, simply, should not take a single minute of the team's time. This is where many companies and set ups fail, and actually creates the sensation that there should be no further investments on the Data and Analysis team. As well, I'll come with further insights in following posts.
Now that, in a high-level point of view, we understand how the lifecycle of Data works it's time to understand that this process, as it's exposed right now, it's based on silos. Each step is traditionally done in independent ways: the web analyst specifies and validates tracking, the data scientist probably determines that a regression analysis is the most suitable to mine the data, the campaign manager states that some campaigns should be stopped, the reporting manager tries to gather-and-show all this information (after it's being generated), etc. All this process, again, has been built over a silo basis. With the process implemented this way is virtually impossible to extract real action out of it.
Here and now is where the Manager needs to step in, in order to wrap up these processes into a single one. Then, and only then, we could start talking about having a successful set up of our Data and Analysis team. When doing this for the first time, is very common to fall into one of the two following mistakes:
Excessive focus on Tracking+Analysis:
Already as an experienced worker, in my first job as a BI and Analysis "manager" (at that moment I had no clue what a manager was because I never had good managers), I was first required to make an evaluation of their set up on the Data and Analysis department, although they felt very proud of their Business Intelligence efforts. The first question I asked, ironically, was: "Ah, do we have such department"? I was presented a Data Scientist, a Campaign Manager, a guy that was creating some dashboards in Excel, and a self-denominated UX expert. That was the marvellous team. After talking individually with them for a couple of days I came back to my Manager and said to him: "Sorry, you have no team. You have a set of skills but no cohesion between them. You built your Data strategy based on silos!". "What's your recommendation?", he said. The answer was the easiest one I've given in my life: "Burn the silos!".
Is my Data and Analysis setup the right one? Sorry, I would say: NO. I can bet my next month's salary that there are important flaws in the way you've organized your Data, BI, and/or Analysis team.
Before starting, let's make very clear what is probably the most important topic when building your Data team: there is no unique and/or magical solution. Every Data team should be built according to the Business needs, the company culture, the skills available at that moment, the available budget, and a long etc. I'm going to give you the classical consultant answer to the question of how to organize the Data team: "Depends". If you came here wanting to seek a magical solution, this is definitively not your place. Further more, this is not your best job. Building up the best team possible is a tough task, and, for sure, not an easy one. It will require a lot of trial and error and a lot of adjustments.
The basic outcome: what do you expect from your Data team?
I was told many times that the Data and Analysis team should give added value to the company. If you think that a Data or Analysis team should bring knowledge then I must say you're partially wrong. Knowledge is the path, not the mean. The ultimate end of tracking, analyzing, extracting knowledge, etc., is to create action! A feature in the website should not be tracked or analzyed if these actions bring no action to the business. The team should be able to trigger a change in the business when delivering knowledge based on an analysis. If there is no action out of these efforts, then the whole Data strategy is totally worthless.
Simplifying the lifecycle of a Data team, we could say that there are four main steps in an analysis strategy:
In first place we have the business needs. The team should be able to gather them, understand them, and forecast what they could look like, in order to deliver Actions proactively. This implies clear and crystal communication skills with the business owners. Once the need is clear, we proceed to evaluate the availability of the necessary data for the potential analysis (in a separate post I'll come back to this point). Then we analyze, out of which we obtain knowledge. Afterwards we come out with actions: we need to make sure that every single analysis done, every single report delivered, any single data extracted is actionable, in the sense of provoking some change, some further thinking on the management level, or, in the last-but-not-least case, a change of operations and/or strategical decisions. If an outcome is not actionable then, simply, should not take a single minute of the team's time. This is where many companies and set ups fail, and actually creates the sensation that there should be no further investments on the Data and Analysis team. As well, I'll come with further insights in following posts.
Now that, in a high-level point of view, we understand how the lifecycle of Data works it's time to understand that this process, as it's exposed right now, it's based on silos. Each step is traditionally done in independent ways: the web analyst specifies and validates tracking, the data scientist probably determines that a regression analysis is the most suitable to mine the data, the campaign manager states that some campaigns should be stopped, the reporting manager tries to gather-and-show all this information (after it's being generated), etc. All this process, again, has been built over a silo basis. With the process implemented this way is virtually impossible to extract real action out of it.
Here and now is where the Manager needs to step in, in order to wrap up these processes into a single one. Then, and only then, we could start talking about having a successful set up of our Data and Analysis team. When doing this for the first time, is very common to fall into one of the two following mistakes:
Excessive focus on Tracking+Analysis:
This is the most common mistake. Everything needs to be tracked and stored, said the CEO. There's not enough budget for that, said the CFO. There are not enough resources, said IT. There are not enough skills, said the analyst. There's not need for all that, should be saying the BI Manager. If you decide to track, store, and analyze absolutely everything, then I must say you have the data-version of the Diogenes Syndrome. You gather a lot of knowledge. You gather a lot data (which generates a cost that should not be underestimated). However, if there is no clear connection with the Business, we'll never be able to derive action out of this massive amount of knowledge. In other words, all this data and knowledge is totally unorganized and unstructured. The Manager should be able to gather concrete business needs, or, even better, identify clear business opportunities, and then (and only then) make sure the data is available and that a proper analysis is conducted. Actions will appear automatically after this process is properly followed.
Disconnection form the Business:
This is a very dangerous mistake. This set up is what I call the corpses set up. Deriving actions out of a massive tracking and analyze phase is like walking around by killing everybody you find in your path. If there is no connection with the Business (the motivation, the core of Data existence), the proposed actions will result in a worthless effort. Usually this set up ends with a generalized burnout of the Data and Analysis team. If the team (or its Manager) doesn't understand why are we tracking and analyzing, then the actions that we'll derive out of it will not answer any question. Let me depict this with a concrete example. As an analyst in a flash-sales online vendor I was asked by the COO: "For how long we should be running Promotional Sales campaigns? Please, tell me a number and I'll make sure that we'll implement such length". Indeed, was a very simple request, and it took me less than one day to come with an answer (actually, it was 4 days). As promised, the COO implemented by force such number, although nobody understood where that number came from. Even more, at the Data and Analysis team we ignored at all why we were running such campaigns. That is, we did not understand the essence of the request. In other words, the COO was assuming that we should have such campaigns "in order to generate unique buyers". A simple analysis afterwards revealed that such campaigns weren't generating more unique buyers, or that such buyers were spending more after a given time. At the end, by understanding what was the Business need (are Promotional campaigns worthwhile?) we were able to collect the necessary data and to conduct specific analysis to come with a clear action: kill Promotional campaigns. This was only possible by means of wrapping up all four silos in a unique and crystal process: from the Business need to the action.
A new way to understand the wrap-up.
The previous example showed that, indeed, we should consider all four stages as part of a single process. However, there is a way to further pressure the process: instead of considering it a linear process, consider it a cycle:
This is nothing more than having a proper follow-up of the implementation of the proposed actions. Ideally, such implementations will lead on more business needs, that, at the same time, will need more data and analysis in order to be optimal. Part of the Manager's skills we should count for proper feedback loops, implementation follow-ups, etc. This implies that very strong communication skills and technical and architecture knowledge are a must-have.
This cycle will automatically derive in chasing new business opportunities. In other words, when the team, and its manager, perform the proper follow-ups, and closes the cycle, then they will start to do analysis by themselves. Why? Because they will understand the business and check whether the implementation were a success or not.
Now this needs to come to an end. You can have the best business analysts, web analysts, campaign managers, data scientists, etc. etc. etc. But you will only succeed if their manager is able to wrap-up these silos, from the business needs to the implementations and assessment of the proposed solutions. It well worths a try. Guaranteed!
