How I automated ad-hoc analyst tasks
Hi Hi! I'm Oleg Filonov, leader of product analytics at Tinkoff Affiliate Cashbacks. I’ll tell you how I saved my team from ad-hoc tasks, what worked and what didn’t, and how I should have acted. I’m sharing my story of implementing changes in the analytics team.
Enemies of analysts – ad-hoc tasks
The main enemies of analysts are ad-hoc tasks: downloads, atypical but massive reports, sudden problems with data, product processes that are done by the hands of analysts.
Analysts do not always know how to manage and redirect ad-hoc task flows. This is purely managerial work. Ideally, I would like product managers to handle this. But in this story, I got the role of manager because my team suffered the most from the established state of affairs.
In our company, managers are trained. At one of the trainings, I became acquainted with the stages of change according to John P. Kotter and even wrote a post about it on LinkedIn. You can learn more about change management read on the website of the Training Institutefrom which I borrowed a useful and understandable graph with stages of change.
Every manager and employee is constantly busy with their current work, projects and tasks. And if there are problems in my part of the process, this does not mean that everyone should rush to automate for me. But I have the power to change the process. You will have to compete for attention, prove the value of the task for the common cause, and if everything goes well, eventually get the desired automation.
Successes and failures in the automation process
At the very beginning, I did not have enough weight and persuasiveness, so we launched the rescue program with some delay.
Step 1. Talk about the existing problem, create a sense of urgency and inevitability of change among colleagues.
What I did: approached the problem as an analyst. The ad-hoc situation was completely clear to me, but not to other team members. I collected the invoice, wrote everything out in detail, and made telling graphs. Alas, all this analytics took too much time, and the effect was very weak.
I also discussed the problem with one of the managers in the hope that he would start the processes. It was naive on my part. Managers always have a lot of important and urgent things to do, often they simply do not have enough resources to respond to every signal. While I was waiting for his reaction, time passed, the analysts continued to cut ad-hoc.
How to proceed: to spend minimum time for preparation and tell the maximum number of managers and stakeholders about the problem. I focus on leaders because they have resources and leverage that specialists do not.
With support from above, you don't just grumble about difficulties and wait for change, but become an initiator of improvements with the ability to change something. Don't be afraid and don't hesitate to amplify and repeat your signal until the problem is addressed:
– regular meeting;
— channel in the corporate messenger;
– half of the conversations are in the corridors and at the coffee machine.
Step 2. Assemble a team of reformers = find allies.
What I did: failed my first attempt to raise the issue and bring the problem to management due to small coverage target audience. After a short break, I started crying wolf again: I told all the development leads, managers, and the product owner about the problem.
After the first responses, I collected several meetings with all these respected people. During the calls, I was advised to have one-to-one meetings with the development lead and product managers who could potentially take on this project. And only at this stage did my detailed analytical note come in handy. There was enough data in it to convince the guys of the importance of the project. This is how I found interested and involved people who were ready to help me.
How to proceed: I did everything right here. Interested colleagues helped me formulate messages, connected me with responsible people, and generally reduced the burden on me to start and lead changes.
Step 3. Create an image of the future or describe it as a project.
What I did: I spent several weeks meeting with the future project team. During the meetings, we formulated problems, thought about possible solutions, and wrote notes. Then all this formed the basis of the project documentation. Documentation helps explain why and what the change team is doing without meetings.
How to proceed: I did everything right here too. But here is a tip: it is important to try to connect your vision with the goals of the team or company. This will help you obtain additional resources in the next steps. Have time to “sell” your ideas before annual or quarterly plans are agreed upon. Otherwise, it will be very difficult to replay them.
Step 4. Tell everyone about the new project and the risks of not completing it.
What I did: I started by introducing new terms. For what? I literally gave names to projects and processes that previously had no names or were unfashionable and had a negative context. This helped focus the team on certain entities and sell the project to them later.
For example, analysts have the task of collecting an audience. It was called “sampling”, “gathering an audience”, “selecting targeting”. I named the process launch-camp. A new term has emerged that is convenient for developers, product managers and other colleagues. It turned out that the name of the process became the name of the project and all participants began to better understand what it was about when they heard about launch-camp.
Then I created project pages on the internal Wiki, wrote dozens of posts in channels, held up to 10 meetings where I explained why we should invest resources in these projects.
How to proceed: use all available channels – messenger, Wiki, regular meetings, large product meetings, letters. This really needs to be done. You can try to attract project participants, let them work a little as evangelists of the new vision.
Step 5. Attract as many people and resources as possible to start the changes.
What I did: lost my luck. The analytics team got into the work half-heartedly: it seems that the guys lacked the experience to navigate, and I lacked perseverance.
The main users of the reporting that we wanted to automate ignored the problem. Perhaps because analysts continued to selflessly support the old process.
We were able to receive great support from product managers, developers and part of the analytical team. So grateful they got involved!
How to proceed: combat barriers that may prevent change, as the theory advises.
I can only suggest that we need to try to shake up passive colleagues more radically. Perhaps hold more face-to-face meetings with those potentially willing to help. If you have such experience, write in the comments how to act at this stage!
Step 6. Sell the first result to the team and end users so that everyone feels successful.
What I did: told all participants in the process about the MVP of the new project – about our first result. Reports that were previously collected manually by analysts began to be collected by the system. They were not very beautiful and sometimes had bugs, but that was already something.
MVP helped reduce the load on my team a little and convinced the development team that the project was feasible. And the ice has broken!
But we, together with the team, missed that the end user, quite conservative and passive, did not use our MVP. As a result, we did not receive valuable feedback on time.
How to proceed: focus on delivering the value of the early “low hanging fruit” to end users. It is important to collect feedback from end users and convince them to migrate to an MVP solution as early as possible.
Step 7: Build on the success and continue the change.
What I did: sad :(((
New Year's holidays never come on time for a team working on a big project. After the long weekend, the “rollback” began.
Planning is a complex process with many participants and variables. There are constantly competing initiatives that affect different parts of the processes and business. Sometimes even the most important tasks may not make it into the first priority backlog. This is what happened with my task.
The relevance of the problem has been forgotten, as has its connection with achieving the goals. Our change project entered the annual planning, but with a second priority. This threw off the momentum.
How to proceed: keep your finger on the pulse throughout the entire project. Don’t loosen your grip, maintain tension – hold status meetings, create a dashboard with visualization of the automation process.
If you realize that the pace of change is dropping, escalate immediately. It would be ideal if you can shift the role of the engine of progress to someone who has more weight in the team. By the way, it is absolutely normal for the initiator to remain outside the change team. For example, a novice specialist can identify a problem and tell everyone about it, but this does not mean that his next step should be to lead a project on which 30 people are working.
Step 8: Meet the new normal.
What do I do: I return to step 7 for the changes to take place.
Unfortunately, in my story, the beautiful moment of the new normal has not yet arrived. And I feel that I have to talk about the problem many more times and attract even more people to solve it. But I am confident that we will be able to bring the team to a new state. Therefore, I began to come up with and implement specific steps so that the team could engage in more interesting and useful projects for the business.
How to proceed (from theory): don't relax. We need to think about and evaluate the path we have taken. Be sure to take a break and take on a new project so that changes become part of the corporate culture. In general, this is how it works at Tinkoff.
And a smart, cheerful parting thought.
The implementation of changes, their scale and speed are one of the main markers of a successful team. It doesn't matter if the processes are imperfect, but they are changing for the better. And if there are no changes, then there is no development – neither corporate nor professional.
Don't be afraid of difficulties and changes! They make us, our teams and products stronger and better. And if you have your own stories of implementing changes, I’m waiting in the comments to share your experience 🙂
