Why I enjoy being a data analyst: four reasons and one example

I enjoy working with data because it lets me move from a vague question to something we can examine. Someone says performance has deteriorated. I open the data, clarify definitions and discover that one sentence contains three different problems. Each calls for a different response. That moment still interests me.

In my original article, I named four reasons: varied tasks, understanding the business, technological possibilities and work that feels like an investigation. I still stand by that selection. Here I want to make it more concrete, because “an interesting job” tells someone considering a career change very little. Especially when there is also a report waiting to be refreshed for the thirtieth time.

I will work through an invented example involving late deliveries. Every number is synthetic. This is not an account of a new client, employer or personal project. I am constructing a small exercise so you can see the decisions an analyst makes and consider which parts of that work might appeal to you.

Starting with a question that sounds simpler than it is

Imagine a message from the person responsible for deliveries: “We have more delays. Check whether service quality is falling.” There were 40 late shipments in the first week and 60 in the second. At first glance, the answer looks obvious. The number of problems increased by half. We could already produce a red chart and send it around.

First, I ask how many shipments were delivered in total. There were 200 in the first week and 400 in the second. The late-delivery rates are therefore 20% and 15%. We have more late parcels but a smaller proportion arriving late. Both statements are true. The team handling complaints could have more work even though the overall delivery-performance percentage improved.

Before labeling either result good or bad, I establish the purpose of the analysis. Are we planning complaint-handling capacity? Assessing the promise made to a customer? Choosing a part of the process to investigate? The count of incidents, their proportion and the severity of a delay answer different questions. One red or green dashboard tile cannot settle all of them.

I clarify the definition too. Late relative to which promised deadline, using which recorded date and time zone? Are we counting only completed deliveries? What happens to a shipment still in transit? Without those decisions, a correctly calculated percentage can compare different things across successive weeks. The arithmetic can be right while the comparison remains misleading.

Reason one: I change the kind of work within one problem

The variety I enjoy comes from what the task needs next. First I discuss the meaning of a delay. Then I inspect a file’s structure, calculate a metric, compare groups and explain the result. Even this small delivery example needs several modes of thinking. For a while I am being technically precise; shortly afterward I need to describe the finding in ordinary language.

Every day does not provide that complete range. Some roles focus heavily on recurring reports, some weeks involve maintenance, and some tasks stay inside one system. The O*NET description of Business Intelligence Analysts includes tool maintenance, documentation and user support alongside analysis. It describes a US occupational category and provides a useful task checklist, rather than a promise about a particular vacancy elsewhere.

In our example, variety does not require five new applications. I can move from a conversation to data and an explanation within one workbook. What interests me is the change in perspective. A user sees more complaints, an analyst checks the denominator, and the process owner needs to decide what to do next week. Those perspectives need to be connected.

Switching attention also has a cost. If another urgent question arrives every few minutes, variety starts to feel like disorder. For a well-organized task, I therefore protect time for focused work, record agreements and establish when the result will be delivered. A long list of topics does not automatically represent a large amount of useful completed work.

For someone considering this career, I suggest a simple observation. Do you enjoy returning to the data after a conversation, then returning to a person with the result? Those transitions serve a purpose in analysis. If only one stage interests you, that is useful information too. You might prefer a more specialized role or a team that divides the work differently.

Reason two: I learn how a business works

Delivery data shows me part of a process that begins much earlier. A customer chooses a service, a warehouse prepares the order, a carrier collects the parcel and systems record events. A final delay can originate at different stages. To prepare useful analysis, I need enough understanding of that process to ask a meaningful question.

I find that aspect of the profession appealing. I learn how business activity becomes a record in a dataset. Instead of treating a status column as self-explanatory truth, I ask who updates it and when. Instead of counting every row, I establish whether one row represents a shipment, an order or a status change. That knowledge directly affects the calculation.

Being close to a business also requires restraint about impact. A report alone does not change a process. Someone needs decision-making authority, resources to act and responsibility for the consequences. I can provide analysis and a recommendation. I cannot guarantee that every recommendation will be accepted or claim the entire outcome of work carried out by several people.

For this delivery example, I would suggest two separate conversations. The service team needs to assess the workload associated with 60 late shipments. The delivery owner needs to know whether performance changed within individual services. A shared dataset can help both, but their answers and next steps may differ. Matching the finding to its recipient is part of what gives analysis a purpose.

I also value the ability to give a bounded answer. With only a delivery date and a promised deadline, I can describe lateness. Without intermediate events, I cannot honestly identify the stage that caused it. I would rather name the missing measurement than blame the warehouse based only on the parcel’s final status. A specific boundary to our knowledge is useful business information.

Reason three: tools offer several ways to solve a problem

I like having options in how I work. A spreadsheet helps me inspect a small dataset. SQL helps retrieve and combine data from a database. Code can reproduce transformations, and a BI tool can make results available to several users. What matters to me in that description is the purpose of each activity. A list of software names is not an analysis plan.

For two weeks and two delivery types, a small table is enough. I do not need an entire system to check forty divided by two hundred. If the same question returns regularly, the dataset grows and several people need a shared definition, it becomes worth designing a repeatable process. A tool change should respond to a problem we have actually identified.

Freedom of choice has limits. An organization may have established infrastructure, access policies, approved software and people maintaining a particular report. In that setting, I recommend something we can hand over and support. An impressive script offers limited help if nobody else can run it and the result is needed while I am away.

I therefore ask about refresh frequency, the source, change control and the intended reader. Then I choose the simplest solution meeting those requirements. Developing my technical skills still matters, but I try not to turn every reporting request into a testing ground for a new library. Usually, the user did not ask to participate in my technology experiment.

If you are starting out, practice this principle with Excel array formulas and later compare it with Python fundamentals. Look for the same underlying task: selecting inputs, calculating a result and handling a missing value. That connects the next tool with reasoning you already understand, rather than making every application feel like a separate profession.

Reason four: I work toward an explanation step by step

Let us return to the deliveries. The overall rate fell from 20% to 15%. Did the services improve? I split the synthetic data into two categories and obtain the following table. Standard and Express are simply group names in this exercise, with no connection to a particular carrier’s offering.

Neither group changed its late-delivery rate. In the second week, the service with the lower rate accounted for a greater share of all deliveries. The combined percentage fell because the proportions changed. I now have a more precise explanation of the difference between the weeks, although I still do not know why customers selected a different mix of services.

I enjoy that moment: checking another breakdown changes the interpretation. It did not require a mysterious algorithm. It required a meaningful grouping, a totals check and some patience. In the first week, 30 plus 10 gives 40 late deliveries. In the second, 30 plus 30 gives 60. The grouped totals reconcile with the numbers we started from.

I would not announce that every causal question has now been resolved. I have explained the arithmetic effect of the delivery mix on the overall metric. Explaining why the mix changed requires more evidence. Likewise, an association between two variables does not establish causation, as NIST emphasizes in its discussion of scatter plots. A reasonable hypothesis starts an investigation; it does not complete it.

The less glamorous work belongs to the job too

Before reaching that explanation, I need to check the basics. Does each shipment appear once? Is the second week’s file complete? Do we handle cancelled deliveries consistently? Do the two weeks cover comparable periods? This work rarely appears in an attractive thumbnail, yet it can determine whether the entire analysis has any value.

Now imagine the file is generated on Monday morning and some weekend shipments still lack a final status. Comparing the latest week with an earlier closed period could be unfair. I need a rule for closing the data or an explicit indication that the newest period is incomplete. Otherwise, an apparent improvement might disappear after the next refresh without any underlying operational change.

The job also includes revising explanations, documenting agreed definitions and answering user questions. Sometimes an explanation needs to be repeated because the reader has a different context or is checking the report between meetings. I try to improve the communication instead of assuming that showing the formula once should have been enough. Analytical autonomy works better when clear information remains accessible to others.

Every investigation does not end with a satisfying discovery. Inputs can be missing, definitions can have changed without a record, or the comparison can be inconclusive. Ending with an honest statement that we cannot yet decide is part of the work too. I then specify which measurement or check would let us make further progress, rather than leaving the uncertainty vague.

How I would communicate this result

Before writing the note, I also ask whether the percentage reflects the severity experienced by its reader. A one-day delay and a parcel missing for two weeks may share the same late-delivery label. A process-improvement decision could need the distribution of delay lengths and information about undelivered parcels. The proportion of late shipments alone cannot describe the whole customer experience.

I do not add metrics indefinitely, however. I ask which extra information could change an action. Delay length matters directly when a team needs to prioritize customer contact. If it only needs an estimate of incoming case volume, a detailed chart for every region can wait. That helps keep the work small enough to finish while the answer is still useful.

I also ask someone else to inspect the reasoning. They might notice that I used dispatch dates instead of delivery dates, or counted two status events as two parcels. Such feedback improves the answer even when it requires recalculation. Enjoying a solved puzzle can easily become attachment to an early explanation. I would rather record a hypothesis and the evidence that would reject it than defend a chart because it took a long time to produce.

My short note to this fictional team would say: late deliveries increased from 40 to 60 while total deliveries increased from 200 to 400. The combined late rate fell from 20% to 15%. The rates within both service categories stayed unchanged. The overall percentage changed because Express represented a larger share of deliveries in the second week.

I would add a separate limitation and next step. These are synthetic inputs; in a real task we must confirm complete periods and a consistent definition of lateness. The count of problem shipments remains relevant to service-team workload. To assess process performance, we should monitor both categories. To investigate where delays begin, we need events from the successive delivery stages.

Notice the distinction between an observation and a recommendation. The first comes from the calculated data. The second also considers purpose, available options and the cost of the next check. I write them so that a reader can challenge an assumption without having to reject the entire table. That makes discussion easier and exposes the point where an actual decision is needed.

I would also avoid treating file delivery as the automatic end of the task. I establish who will use the result and whether they need a one-off answer or recurring monitoring. A recurring report needs a definition owner, a refresh schedule and a way to report problems. Otherwise, an interesting analysis can quickly become another attachment nobody opens.

Try a small task and notice what you enjoy

Copy the four table rows into a spreadsheet. Calculate the weekly results, then write three sentences for a person who cannot see the table. The first should describe the count of late deliveries, the second their proportion and the third the change in service mix. Check whether each sentence is understandable without knowing the function used in the workbook.

Next, deliberately change one input and see which conclusions stop being true. Increase late Standard deliveries in week two from 30 to 40. That group’s rate becomes 40%, and the combined result becomes 70 out of 400, or 17.5%. The overall rate is still lower than in the first week despite deterioration within one segment. That should change how confidently you describe the aggregate result.

Finally, consider your reaction to the exercise. Were you curious about why the numbers changed? Did you check the totals without being reminded? Could you accept that the table did not explain the cause of customer behavior? Those observations are more useful than imagining yourself surrounded by three monitors displaying dashboards. The monitors are particularly easy to imagine.

To continue, read about choosing between data analysis and programming or communication in analytical work for introverts. For me, the appeal comes from connecting questions, data, tools and conversations. A small project of your own can help you discover which of those parts you actually want to develop.