Data analyst collaboration: 6 behaviours that make work harder

The worst analyst on the team? It is an easy label to apply after a disappointing project. Explaining exactly what went wrong and what needs to happen next time takes more work. Yet that explanation determines whether the conversation improves anything. Calling someone difficult to work with leaves plenty of room for speculation and very little direction for action.

I prefer to examine behaviour. Did someone promise a result without checking their capabilities? Change a definition without agreement? Leave a solution that nobody else can run? Those questions let us assess a particular piece of work. They do not require guessing a person’s personality, motives or conduct outside the office.

Below, I discuss six problems you may also recognise in your own habits. The conversations and assignments are fictional examples for practising collaboration. They are not stories about candidates from my recruitment experience. Imagine a team preparing a recurring active-customer report. It sounds straightforward. A few unspoken assumptions are enough to leave everyone counting something different.

1. Claiming skills without explaining their boundaries

A versatile analyst can be extremely useful. I see a problem when “I know SQL, Python and Power BI” replaces a conversation about the kind of experience involved. Someone may have independently maintained a report or simply followed a course exercise. Both experiences matter, but they do not provide the same basis for owning a recurring production process.

In our example, you promise to prepare the whole process. Just before the deadline, it becomes clear that you have never configured refreshes in the team’s environment. The missing experience is something we can discuss. The late disclosure creates the expensive part: nobody planned a consultation, and the recipient expects an automated report. The team must now address a technical gap and a delivery problem together.

I would describe my capability at task level: “I can prepare and validate the query. I have published reports with help, and I need someone familiar with our environment to walk through refresh configuration.” That makes it possible to divide the work and schedule a check. You do not need a public inventory of every weakness. You need an honest boundary relevant to this particular commitment.

When assessing someone else’s work, I ask for a decision and the reasoning behind it. What did they do independently? What did another person review? Where did they need help? A fluent story is not proof of competence. I develop the task-based approach in my article on checking an analyst’s skills. Here, the essential point is that both sides understand the scope of a promise.

2. Confusing negotiation with ignoring agreements

Questions about pay, remote work or availability are normal parts of discussing a working relationship. I do not infer character from them. You may need particular conditions and decline an offer that does not meet them. The company should also explain the actual scope and conditions before either side invests substantial time in the process.

The behaviour I want to address is accepting a commitment and then changing its terms unilaterally. You agree to a report review, fail to attend and tell nobody. You confirm that you will leave instructions, then decide documentation is beneath your level of expertise. Those are specific actions to discuss. A preference for working from home tells us nothing about whether someone will do either of them.

A useful response starts by checking whether the agreement was clear and feasible. Perhaps the deadline conflicted with another assignment, and two people were setting priorities independently. Perhaps the instructions were meant to follow the review, while someone understood the reverse. Before describing a lack of responsibility, I reconstruct the agreement. If a message was missing, I discuss that message and its effect on the work.

For the next assignment, I record an owner, a handover point and a way to change the plan. When deadlines conflict, I ask for a decision instead of promising two recipients the same calendar slot. Keeping commitments includes saying early that you cannot meet them. Pretending to be available until the last moment is not particularly helpful, even when it starts with good intentions.

3. Leaving others without information they need

Someone can speak little in meetings and leave excellent notes. Someone else can speak at length while nobody knows what was agreed. I therefore avoid using introversion or shyness as shorthand for collaboration quality. I check whether the right information reaches the right person at the right time, in a form that can be used without guessing missing context.

For the active-customer report, one basic question matters: what counts as activity? If you keep an unresolved doubt in your head, others may build charts using a different assumption. The problem is the absence of a visible agreement. A short note with two possible definitions, example customers and a question to the definition owner might resolve it.

In practice, I suggest agreeing on an update channel, an expected response time and a way to raise urgent blockers. Working Agreements in Atlassian’s Team Playbook offers a useful reference for discussing shared working rules. Instead of assuming that everyone watches chat all day, we agree where decisions go and when a live conversation is needed.

If someone struggles to explain a result in a meeting, allow a moment to organise a written answer and question. I would not turn one stressful exchange into a verdict on their entire working ability. Writing still needs specificity: “I need the definition confirmed by Wednesday because I cannot finish the comparison without it.” The format should help information move, without becoming an unnecessary test of social performance.

4. Closing the task without checking how the result is used

A report can satisfy its technical specification and still lead a reader towards the wrong decision. Imagine counting active customers from application logins. The recipient treats the result as paying customers because the definition is absent. The query runs, the ticket is closed and two people use the same number with different meanings. That gap is worth finding before publication.

I do not expect the analyst to make every business decision independently. I do expect a question about what is being measured and how the result will be used. If the scope is limited to a technical export, that can be documented too. The recipient then knows what the export does not establish. Trouble begins when that boundary disappears and a technically correct result acquires a broader meaning in the presentation.

During review, I show a one-sentence conclusion and ask the recipient to describe the next step. If their interpretation goes beyond the data, we clarify the wording. In our example, a clearer chart title and definition may be sufficient. Sometimes the query needs to change because the intended decision requires payment data, not logins. A small early sample is a good place to discover that mismatch.

Taking an interest in context does not mean accepting every additional request. A new breakdown or definition can change scope and timing. We need an explicit decision about what happens now. I discuss inconsistent definitions and ownership further in my article on data problems in companies. It is useful background when the same disagreement keeps recurring between departments.

5. Keeping all the knowledge in your head

An expert who understands a complicated process is valuable to a team. Making every minor change depend on that person’s presence creates an organisational problem. If only one colleague knows how to run a report, their holiday becomes an infrastructure event. Another “just message me if needed” will not resolve it. Knowledge needs to be passed on in a usable form.

For our report, I would leave the active-customer definition, sources, period, refresh procedure and basic checks. I would also explain why a particular group is excluded and what to do if a check fails. Code may reveal how a filter works. It often cannot reveal the business reason honestly. Those decisions are especially easy to lose during a handover.

The useful test of documentation is another person’s attempt to use it. I give them the instructions and access to the agreed environment, then observe where they need to ask. I avoid immediately supplying every next step, because that would test my availability instead of the instructions. After the attempt, we fill specific gaps. A short task note may be enough; an encyclopaedia of every click is unnecessary.

The team also needs to allocate time for the handover. If only new-feature speed is rewarded and documentation is always deferred, the isolated expert may be a product of that system. I therefore examine both behaviour and working conditions. We agree on a small piece to transfer, a recipient and a trial date. Responsibility for the solution should not depend on an endless stream of private messages.

6. Choosing a tool before understanding the constraints

I like having tools I can use fluently. Deep expertise helps solve problems that others find difficult. Trouble begins when every request automatically becomes a case for my favourite solution. It then becomes easy to overlook licences, the recipient’s skills, maintenance arrangements or the fact that the output may be needed only once.

Suppose the active-customer report is required weekly and will be refreshed by a team familiar with the existing tools. A new technology might improve something, but it still needs a maintainer. Before proposing it, I identify the actual difficulty. Is it processing time, manual copying, inconsistent definitions or access to the result? Each of those problems may call for a different response.

I would compare two small trials using the same data and acceptance conditions. We would check correctness, reproduction, error handling and the ability to hand over the work. Without timing measurements, I would not claim a percentage performance advantage. If the prototype works only on my computer, I would record that condition. A tool earns its place through the assignment’s requirements, beyond looking attractive in my portfolio.

Sometimes the existing tools really do fail to meet the need, and proposing a change is worthwhile. A clearly described problem, evidence from a trial and the transition cost make that discussion easier. Technical curiosity does not need to be suppressed. An educational experiment simply needs to be distinguished from a commitment the whole team will maintain. The latter needs agreement on responsibility and boundaries.

Describe what happened and the change you need

I find the Situation-Behavior-Impact approach described by the Center for Creative Leadership useful for organising feedback: identify a situation, an observed behaviour and its effect, then ask about intent. It is a conversation aid. I would not treat it as a guarantee of resolving conflict or evidence that I already understand the other person’s motivation.

An example could be: “At Wednesday’s report handover, the active-customer definition was missing. Two people interpreted the result differently, and we had to revisit the calculations. How did you understand the expected explanation at delivery?” After hearing the answer, we agree on a change: the next version will place the definition beside the chart, with confirmation from the recipient before publication. There is a concrete item to review next time.

If you receive a general comment such as “your communication is poor”, ask for a situation and the expected message. The issue might be a late blocker update or an unclear explanation of a result. Each needs different practice. You do not have to accept every interpretation without discussion. It helps to identify a fact both sides recognise and an observable meaning of improvement.

I avoid making a public list of someone’s failures into entertainment for the team. A conversation about an error can be calm and firm at the same time. If the behaviour continues despite agreements, I document the facts and involve the person responsible for the team’s work. An article or a prepared phrase cannot replace established processes for addressing serious collaboration problems.

Check whether you are assessing a recurring problem

A single mistake tells us something about one situation. It is not enough for me to describe someone as a person who always lets the team down. For a recurring problem, I gather comparable cases: the agreement, what happened, when the other person received information and the effect. I distinguish direct observation from a corridor story. A rumour does not become reliable evidence when copied into an evaluation form.

I also check whether the conditions changed. If a report previously worked and new sources were then added without review time, a drop in quality does not by itself establish a loss of skill. We need to understand the changed workload and whether the responsibility remained realistic. Errors still need correcting. Understanding the conditions helps choose an action that addresses their cause instead of simply increasing pressure on another person.

After agreeing on a change, I give it a chance to work in a comparable assignment. We record the expected result and review point. If the earlier problem was a missing chart definition, we assess whether that definition is present and understandable. We do not add an unknown criterion afterwards. This also makes progress visible; otherwise, feedback can become a permanent catalogue of old mistakes.

Review your habits against an actual assignment

Choose one recently completed assignment. Open its description, result and agreement history. Check whether the recipient could understand your level of independence, the deadline and the limitations. Find a point where somebody else had to guess. Instead of grading yourself as a good team member, identify a missing piece of information or a missing decision. That gives you something actionable.

Next, choose one change for the upcoming assignment. It might be a short refresh guide, an earlier sample or a clear statement that you lack experience with one component. Agree with another person on how improvement will be recognised. For example, they should be able to reproduce the report without sending a private message. You do not need a promise to transform your entire personality within a week.

After the trial, examine its cost as well. Did the new note help, or did it duplicate information in three places? Did the meeting resolve the definition, or could one comment have done the job? Good collaboration should make work easier to complete. If a new routine does not help, change its form. Calling something a process does not automatically make it useful.

The same principle works in an interview: describe a specific part of a project, your responsibility boundaries and how you checked the result. The interviewer can ask for the reasoning and a brief handover using synthetic data. That provides more evidence than judging who sounded most confident. Above all, I would want to know whether our work together leaves a result we can understand and continue developing.