What I’ve Learned from One Year as BI Analyst
A couple of weeks ago I celebrate my first anniversary at my current company, Glints, as a Business Intelligence Analyst. Nothing to celebrate except what I learned this past year.
I have a different role when I was at my previous company where I usually play to provide a data solution for the client. The advantage of having a “consultant” role for many types of clients is I can get exposure to various problems that required various solutions. But after one and a half years at that company, I move to Glints and become a BI Analyst, and of course, there are many new experiences here.
In this post, I will try to share some of the key points of learning that I get since I join Glints. Some of them you might think are a bit cliché but for me, it is worth sharing.
Simplicity
This is the very first lesson that I think I can remember since I arrive. As a new joiner, I immediately join a project to centralize the report to a dashboard so the operation team can reduce the manual process. The intention is great and this is what you need to do to become a data-driven company. But I found the SQL script of the ETL process is very complex and long. I need some time to read carefully and understand the concept even just want to add one simple feature.
Fortunately, the team that built this process is still around so, yeah, you can ask around. But what about if you came to continue a project that was left by a former employee? Oh man, that’s hard. Sometimes we will try to patiently read the long script, but end up starting a new one instead of continuing the legacy.
From this experience, I learn to build queries as simply as possible. The evaluation process would be like this: “Imagine that one day you will leave the company and people have to read your code.”
Imagine that one day you will leave the company and people have to read your code.
So what kind of simplicity that we talking about here?
The very first thing that we need to consider is formatting. Some people would say it’s about preference. But I believe there is a difference between preference and the intention to watch the world burn. You can choose any kind of formatting that you think people can easily understand your query.
Next, if you already tried your best to provide a proper formatting but your query becomes more complex (because it has to be) then consider to breakdown your query using Common Table Expressions (CTEs). I found this article (CTEs in SQL: 5 Tips for Data Scientists to Write Better SQL) that wraps up the benefits of using CTE and is aligned with my experiences.
In addition, we can also implement the simplicity spirit when building a report/dashboard. If you use a data tool like Metabase that requires you to write the query in each visualization, you will face a condition where you need to use the same query again and again to a different approach of visualization. It is hard to maintain since you need to go one by one of the questions to change the query.
You can simplify this by using the Models feature or other tools like this that I think are very helpful. So anytime you need to edit the main query, you only need to change the Models then it will affect all the downstream usage.
In the end, it is better to give an effort to make your work simple rather than give you or your successor a headache to continue the project.
Mastering New Skills
To be honest, before join this company I always think that there will be always two side of coins, the business side and the technical side. People like business users or stakeholders, in general, do not need to know about the query written by the data team by saying “it is too technical”. Yes, that is the main focus of the data or analyst team, but if the stakeholder knows a bit about these “too technical” things the benefit is real.
The next lesson is inspired by some stakeholders that I met here. Even though they do not have any data background, they show me that they have a will to gain this skill. They usually learn from external sources or invite a data analyst for a weekly call to discuss how to query or something. I also did that on some occasions, to a group of business users or to a single person. I love doing this.
The reason is quite simple, it will make my job easier. First, for a simple question like how many transactions on this week or how many users applied to a specific job, they can do it by themselves. They do not need to wait for my reply on Slack or submit a ticket just for these simple questions. Of course, if the question becomes more complex I will help with that, but many times they also want to know how is the process so they can gain more knowledge. It is amazing.
Second, the hardest and most boring part of creating a report or dashboard is the quality checking part. An analyst is also a human, we did make a mistake, it can be the wrong query or something. If the analyst lacks context to the report, the business users might help with their sense. Of course, it is a great gift, but if the business users only said “the trend should be not like that” and had no more explanation, it will make the analyst no direction on where to begin the checking. It will be a different story if these two sides can discuss or maybe the business user can bring their own calculation so we have a much clearer direction.
This story is not only for the relation of analysts and business users, as analysts, we are “the users” of folks from where the data coming from, like the Data Engineers team. Learning their expertise also can give the analyst a bunch of benefits. For example, knowing about how the data pipeline works will give more understanding of the data that we used and help in the time of troubleshooting. This is what I get in my current role, not only focusing on the analytics side but also giving me the opportunity to learn and practice in this area.
Maybe people can say that you are not paid for doing outside of your role, but mastering them will be a great investment for the future and help your current work.
Minimize Assumption with Communication
(First of all, I am not talking about statistical assumption)
Communication between people across data usage is important. From the beginning where the data is being produced to the analyst and ends up to business users. Each of these parts generates its own context and information about the data which should be flowed to the next team so it can be used as expected.
For instance, the developer will make a change on a table for a new feature in the platform, this proposal should be transmitted to the Data Engineers who do the ETL so they can make sure there is no issue will happen in the process. After that, the analyst also should be aware of these changes and make sure will give no harm to the analytics part. Besides preventing bad things happened, this communication also can be useful to give a chance for improvement that can be made for some analytics in the future.
Proper documentation is a step further from direct communication which can give more benefit for future reference. Documentation can be written at every step of business and can be crucial. Even for simple metrics like revenue, there are many possibilities here:
- What kind of revenue? Gross or net?
- Is there any exclusion happened?
- What currency that being used?
- and so on
People can come to the dashboard and use that metric in the wrong place if we lack some of this important information. So what is what really happened where there is no proper information? Then asked. But poor for the metric/dashboard owner that is being asked frequently by different people. How to minimize that? Then make better documentation.
Besides the vertical relationship, we can also take a look at the horizontal relationship. In this case, is the communication between analysts. Knowing your peer’s work is good to have so you know who is a better person to look out for a question. Knowing your peer’s work can also prevent you from doing the same task that has been done by your peers. Why do you need to create the same query if the other analyst has already built it?
All of these advantages only can be a real thing if we have good communication in a vertical and horizontal relationship.
Key Takeaways
A year as BI Analyst may be a short time, but if it gave me a bunch of good experiences I think it deserved to be shared. Here are the three key takeaways that I shared above:
- Keep your work simple and easy to understand.
- Mastering new skills outside your expertise is a great investment.
- Maintain good communication to prevent assumptions in data usage.
What do you guys think? Do you agree with these?
Let’s connect with me in LinkedIn.
