Who can work as a data analyst? Four traits you can practise

“Am I actually suited to being a data analyst?” It is easy to get stuck on that question before opening your first dataset. You might look for an answer in your degree, memories of mathematics lessons, or how comfortable you feel talking to strangers. I would start somewhere more useful: watch what you do when you try to solve a specific problem.

Analysis brings together focused work, conversation, technology and reasoning. You can feel comfortable with one part while still learning the others. I treat the four traits in this article as areas to practise. I would not use them as a personality test or an admission ticket to the profession. A few practical attempts will give you better evidence than another evening wondering whether you have a “technical mind”.

Let me use a fictional situation. A customer service manager says complaints are increasing and wants to know what to do. All the numbers below are synthetic. I am interested in how we reach a useful answer, including the questions we ask before calculating anything. You can work through the example with a spreadsheet and a notebook.

Communication starts with understanding the question

In the original version of this article, I used “ambiversion” to describe the combination of independent work and contact with people. I would now put the emphasis on observable skills. You do not need a particular personality label. You need to clarify a problem, ask about uncertainty and communicate a result that another person can use.

“We are getting more complaints” leaves plenty of room for interpretation. More than when? Are we counting contacts, orders with a complaint, or customers? Does the manager want to reduce a queue, identify a faulty product, or assess a change in delivery arrangements? These decisions require different analyses. My first questions would establish what the answer will be used for and when it is needed.

You could write: “I can compare the last two complete months. Are we interested in the share of orders with a complaint or the number of cases the team must handle? Those measures may move differently when sales grow.” The short explanation makes the question easier to answer. You are helping design the analysis instead of handing the entire problem back to the requester.

Listening matters when someone describes a process imprecisely. Rather than correcting every term, ask them to walk through one complaint from purchase to closure. Does a follow-up create another record? Can a case involve several products? Which event does each date represent? Five minutes spent understanding that process can prevent a detailed report about the wrong thing. A polished chart will not repair a misunderstood question.

Focused work needs deliberate organisation

After the conversation, somebody has to examine the data. If you enjoy talking to people, you may need to reserve uninterrupted time for checking results. If you prefer working alone, you may need to schedule a moment to share preliminary findings. Both are practical problems you can address without turning them into a verdict about your career.

Before starting, I would record the question, audience, date range, unit of observation and expected output. Then I would list what remains unknown. After an interruption, that note gives you a route back into the task. A file called “final_analysis_revised_again” provides rather less help. Your computer will accept the name; your future Monday morning may be less forgiving.

In written communication, separate the current decision from the open question. “I am analysing orders placed in August; I need confirmation of how long we allow complaints to arrive” is easier to follow than a paragraph mixing results, assumptions and requests. If this way of working suits you, develop it. It does not depend on being the most outgoing person in the room.

You can also agree on the format of updates. A short written note before a meeting gives everyone something concrete to inspect. A conversation can then resolve disagreement or missing context. Neither format needs to replace the other entirely. In the article about data analysis for introverts, I discuss how working conditions affect this balance. The useful question is how you communicate reliably, rather than how much you talk.

Independence means proposing a next step

An independent analyst can make progress on an incomplete request. That does not mean knowing everything or never asking for help. The UK government’s data analyst capability framework explicitly describes supervised work and learning alongside other professionals at its associate level. It is one organisational model, but it illustrates why complete autonomy on day one would be an odd expectation.

In our example, you can inspect available columns, the date range and the number of records. You can suggest definitions of a complaint and explain which one fits the question. Deciding whether a cancelled case belongs in an official metric may require the process owner’s input. Knowing where your understanding ends is part of taking responsibility for the result.

A useful question carries context: “The file contains open, accepted and rejected cases. I would include all three when assessing workload, but only accepted cases when measuring upheld complaints. Which decision matters most right now?” You demonstrate the work you have already done and make the next choice easier. That gives a colleague more to respond to than a message saying the data is confusing.

It also helps to agree on how long to investigate a problem alone. For a straightforward error, read the documentation and build a small example. If you remain stuck, describe the symptom, expected outcome and attempted checks. Two days of hidden struggle can cost a team more than one well-prepared question. Asking for help can be the action that keeps a task moving.

Technology requires curiosity, not a collection of tools

You do not have to be excited about every new application. You need a willingness to learn the tool required for a task and check what it actually did. Patience with error messages is particularly useful. A warning about an incompatible data type may be the first meaningful clue the file gives you.

Imagine order identifiers that look like numbers, with some beginning with zero. Converting them to numeric values can change their representation. Before clicking a conversion button, ask whether you need to perform arithmetic on those values or identify records. That question matters more than knowing five conversion methods in five different products. Understanding the data gives your technical choices a purpose.

For a first exercise, use a spreadsheet where you can filter, group and trace a result back to the original rows. Later, reproduce the same calculation in SQL or Python. Comparing two methods can reveal mistakes, although agreement is not proof of correctness. Both methods may implement the same wrong definition. The business question still needs its own check.

AI can help explain an error or suggest a formula for a synthetic sample. You remain responsible for understanding and verifying the result. If generated code removes missing values, inspect which records disappear and how the denominator changes. A useful habit is to test an operation on a few cases with known answers before applying it to a full table. That habit transfers between tools.

Reasoning gives a number its reference point

Suppose the first month has 40 orders with a complaint out of 1,000 orders. The second has 60 out of 2,000. The count increased by 50%, while the share fell from 4% to 3%, a decrease of one percentage point. Both statements are correct. They answer different questions and may support different actions.

The service team may have more cases to handle even though the share of affected orders is lower. A quality manager may see an improving rate but should still check whether the periods are comparable. I would communicate both measures and define them. A red indicator beside the increasing complaint count does not explain this situation very well.

Now consider the harder questions. Did every order in the second month have the same opportunity to generate a complaint? Did the submission form change? Were telephone complaints missing in one period? Did a product with fewer complaints become a larger share of sales? Correct division is the beginning of verification. A relationship between two numbers does not establish its cause.

This is what I mean by critical thinking: I look for conditions under which my explanation would stop working. I am not trying to challenge everything for entertainment. A report that cannot establish anything is not much use either. I want a clear separation between what we calculated and what we currently suspect. Similar problems appear in my guide to data cleaning.

Accuracy should serve the decision

You could inspect data indefinitely, so I would first ask which errors could change the recipient’s decision. Staffing requires information about case volume and effort. Investigating a faulty batch requires product identifiers and delivery dates. The checks should follow the intended use, rather than becoming a tour of every column simply because it exists.

The Government Data Quality Framework discusses dimensions including completeness, uniqueness, consistency, timeliness, validity and accuracy. These offer useful questions, not an automatic score for your file. A date can have a valid format and still describe the wrong event. An export can contain every available row while an entire contact channel is absent from the underlying system.

I would record each important issue, its possible effect and how I handled it. For example: “Five cases have no order identifier. I include them in the case count but cannot assign them to the share of orders with a complaint.” The reader can see the boundary of the result. They should not have to discover a hidden rule by comparing the report with their own spreadsheet.

An unresolved issue does not always stop the whole analysis. You may be able to provide a reliable count of contacts while postponing a breakdown by product. State which part is usable and what remains uncertain. This makes progress visible without pretending that every output has the same level of support. It also helps the requester decide whether gathering the missing information is worth the effort.

A practical exercise reveals more than a declaration

Create a small table of fictional orders and a separate table of contacts. Include a follow-up about an existing case, a contact without an order identifier and an order placed near the end of the period. Mark the data as synthetic. Your task is to answer a manager who wants to decide whether the service team needs another person.

First, write three clarifying questions. Then identify what you can already calculate and what the dataset cannot tell you. Produce one results table and a short message containing a finding, a limitation and a next step. If the data contains no handling times, do not calculate required staffing from the contact count alone. Explain which additional information is needed and why.

Show the result to another person and ask them to explain the conclusion in their own words. Can they distinguish a contact from an order with a complaint? Resist the temptation to correct them immediately. Their interpretation will show which parts need work. You are testing whether the communication works instead of assuming a well-written paragraph must be understood.

Finally, change one input condition. Add another contact to an existing case or remove a date. Predict the effect before recalculating. If the result surprises you, investigate why. This small experiment provides concrete evidence of whether you understand your own analysis. It is also a useful way to prepare for explaining a project during an interview.

Evaluate your behaviour without judging your identity

After the exercise, record four observations: how you asked questions, handled ambiguity, checked the tool and changed your view when the evidence changed. Avoid writing “I am bad at analysis”. “I did not check whether one customer could have several cases” gives you a specific next attempt. A broad negative label mostly makes the evening worse.

Pay attention to your energy as well. Were you curious about the discrepancy? Did you want to understand the process or just produce a chart as quickly as possible? Did correcting the result feel satisfying? One answer proves little. Fatigue, unfamiliar material and a poorly chosen exercise can affect the experience. Try again with a process you know from work or everyday life.

Choose one habit to practise over the next week. You might define measures before calculating them or write a short note after each requirements conversation. You do not need to rebuild your entire working method at once. A manageable plan lets you notice improvement. If you change everything simultaneously, it becomes harder to tell what helped.

Check the environment where you will learn

Before exploring job descriptions, practise responding to feedback. Suppose a colleague points out that some orders had only one day in which to generate a complaint. Defending a chart because it took an afternoon to make will not fix the comparison. Trace the objection through one order, then propose a method that gives both periods a comparable observation window. A thirty-day window could be an exercise assumption to discuss, rather than a universal complaint-handling rule.

Practise the reverse situation too: a reader wants an inconvenient category removed. Explain how excluding it changes the population and the meaning of the result. You might show both scopes, clearly labelled, while asking for the business reason. Do not silently change the definition to support an expected conclusion. Working well with people sometimes requires questioning a request or stating that the available data cannot support it.

These cases combine flexibility with responsibility. Sometimes you change your own method; sometimes you explain why a justified limitation must remain visible. In both cases, use a checkable example. That gives the conversation a shared reference point instead of turning it into a contest of confidence. You can rehearse this with a friend by taking turns as analyst and report recipient.

Your behaviour is only part of the picture. Ask a prospective employer who supports beginners, how analyses are reviewed and what happens when two reports use conflicting definitions. Request an example of a new starter’s first task. That tells you more than a description seeking an “independent, communicative data enthusiast”.

If every question is treated as weakness, developing independence becomes harder. If nobody checks results, it is easy to confuse fast delivery with good work. Consider the learning conditions when assessing your fit for the profession. Before blaming your character for every difficulty, examine whether the task, expectations and support were sensible.

I would begin with one small problem and honest feedback. These four areas help you name what already works and what needs practice. Take a process you understand, ask a better question, calculate an answer and show it to someone who needs that information. Your next career decision will then have something firmer behind it than a personality label.