The Typical Work Day
In this post, we’ll cover the typical data analyst’s workday. This won’t be the case for all organizations, but based on our experience over the last 10 years at least 6 different companies, there are a lot of commonalities across organizations and workloads.
Quickly checking important KPIs supporting the business, systems supporting metrics reporting go wrong all the time, you have to be proactive in making sure that data is complete/consistent – if there is something wrong, work to triage the problem AFAP. Providing bad data to the business undermines the confidence the business has in your work.
The first meeting of the day kicks off with a morning sync/stand-up with the team on any new business requests, system issues, and daily status updates that the team needs to know about. This is generally an update from the team lead with each team member providing their individual work updates for the day. If any issues are brought up, team members are generally paired up to try and solve them and escalations to other technical teams may happen as necessary for further input. These team meetings can take as little as 15 minutes to 30 minutes, but are generally critical to the functioning of the team and to helping team members coordinate on critical work items.
There are usually many long-term projects to work on, but those often get interrupted by urgent requests from some department for data to make a decision. You’ll spend 2 hours a day dealing with these ad-hoc requests, especially in sales or marketing driven organizations where decisions on client engagements or spend need to be made quickly. Ad-hocs can be as simple as a CSV file output, the delivery of a dashboard in a system like Looker, Tableau, or DataStudio, or some analysis/findings. You’ll probably do this work in SQL and Excel most of the time, which is why there are some fundamental skills you’ll need to know, however more complex analyses will be performed in Python.
Hopefully, you’ve just had lunch or are getting back from your last morning meeting and are ready for some deep-dives into your data. The “data-janitorial” work begins. Around this time you usually switch into getting Businesses never seem to cease obtaining horribly formatted/structured data. This is where knowing Python/SQL or Excel-ninja skills are critical. Dont expect the type of data you get in classes/assignments that are perfectly formatted. You’ll seriously spend about 80% of your time dealing with data transformation, manipulation, and filtering which keeps you from the fun stuff of actually analyzing data. This will apply to ad-hoc and project work.
Project work & stakeholder meetings – this is where the rubber meets the road. A lot of delivering a successful project or analysis is making sure you clearly understand all the data definitions, expected output in terms of findings, reports, etc. It’s definitely a bit more unstructured than you’ll be used to. Most people in businesses actually dont know what they want from data but still want it… So you’ll spend a lot of time validating/confirming you’re on the right track and that the data you’re querying is actually what you’d expect . This probably sucks up about 6 hours of my week minimum, but I’m in management so I need to shield my employees from a lot of this BS, but you will be exposed to this.
Now that not only you, but members of your team are really cranking out work, you’ll inevitably end up QAing someone else’s work on the team or checking your own work again. Data can be really complex in the real world. Easier to make mistakes than you’d image. So maybe it’s a good time to take a second look at any critical assumptions in your analysis and have a fresh pair of eyes look your work over. Remember what assumptions can do!
Your day is wrapping up and you want to get out of work in the next hour or so. Now’s when you need to start looking back on the work you’ve done throughout the day to communicate with internal stakeholders on how analysis/projects are trending. It’s time to send out critical analysis/reports before the business is offline for feedback and confirmation everything is complete. Now’s also a good time to identify any open items or issues you’ve run into during the day to send to your colleagues to make sure you’ll get answers to those questions as soon as possible in the next working day. You’ll want to save your work and any partially completed analysis to your GitHub account or in an online service like Google Drive to make sure you can pick up where you got started in the next working day.
Now, this is an odd one, and won’t happen often in most organizations, but you can certainly count on one or two late-night high-priority requests. Let’s say a stakeholder or an internal customer finds an issue in a system, report, or needs an analysis done by the next morning. This can happen because of many factors, the organization’s Board, clients, an external audit request, a technical outage, etc. These stakeholders or issues will require an occasional late-night work session. If you’re in a good organization, you’ll be recognized and rewarded for your efforts here. These requests mean time away from your friends, family, and life. While they can seem unavoidable, it’s very important to make sure your management knows that these should be kept to a minimum as much as possible.