Grow in your team: make your work visible and help others

You want to be someone your team trusts with important work. You study, improve reports and help colleagues. Then a career conversation arrives and you struggle to explain what actually changed because of your work. All you have is a list of tools and the memory of several very long weeks. That gives your manager surprisingly little to discuss.

I would start with a more practical question: how can someone tell they can rely on me? I need to choose a useful problem, deliver an agreed piece of work and explain how to use the result. Helping others belongs in that picture too, with room left for my existing commitments. A calendar has limited respect for good intentions.

I will work through a fictional task in an analytics team. The situations, dialogue and numbers below are educational examples, not accounts of a particular client or my professional results. You can apply the same approach to a portfolio project. Just describe the conditions honestly, including any assumptions that would need checking in a real organisation.

Choose a problem you can take responsibility for

In this example, a team prepares a weekly summary of customer support tickets. It combines two exports, people interpret the definition of a closed ticket differently, and several colleagues edit the final file. The manager wants a clearer basis for planning the following week’s work. You want to improve your analytical skills and handle a more independent assignment. Those needs can fit together.

Before asking to own the whole project, I would find out what causes the difficulty. Does the report arrive late? Do the totals disagree? Can nobody explain where a number came from? Each answer leads to different work. Automating an export will not resolve an argument about what counts. A beautiful dashboard can display unresolved assumptions with impressive efficiency.

I would propose a small scope: a repeatable summary of closed tickets, with a documented definition and a completeness check. I need a recipient, access to the relevant data, someone to consult and a date for an initial review. I also ask which existing task will move or stop. New responsibility needs space in an actual working week, not just a place in a development document.

A prominent project can offer opportunities, but its name tells you little about what you will learn. Spending a month copying numbers into slides might leave you with very few decisions to explain. I prefer a piece of work where I can identify my choice, justify it and receive feedback. For a wider view of those responsibilities, see my data analyst career map.

Agree on completion and decision ownership

Before starting, I would write a short description of the result. Here, the file must cover a completed week, use an agreed definition of closure and make the calculation reproducible. Tickets without the required date appear separately. The recipient checks whether the layout supports planning. Someone who understands the source system confirms what the statuses mean. I prepare and validate the summary.

I do not need an elaborate responsibility matrix for every small task. I do need to know who can settle an open question. If two departments define closure differently, choosing whichever definition makes my calculation easier would hide a business decision inside the report. I would show the difference using examples, explain its effect and ask the appropriate person to decide. The agreement goes into a shared note.

The Roles and Responsibilities exercise in Atlassian’s Team Playbook provides a related starting point: compare expectations about roles and clarify gaps in responsibility. I treat it as a conversation aid. A small assignment may only need named responsibilities and a place to record unresolved questions, without adopting a new company ritual.

I also describe what the first version excludes. In our example, that means forecasting ticket volumes and evaluating individual employees. Without that boundary, readers may expect answers the data cannot support. A written scope also helps when every new suggestion starts becoming a condition for finishing the original assignment. A new request can be discussed separately, with its priority and cost made explicit.

Share progress when someone can use it

I start making work visible by agreeing on communication. For a short task, an update after the first data check and another before handover might be enough. Longer work may benefit from a regular schedule. I would not assume the manager reads the file’s change history every day. Equally, five updates about chart formatting are unlikely to help her make a decision.

An example update could read: “The summary covers the completed week and the ticket identifiers have been checked. Some records have a closed status without a closure date, so I show them separately. I need confirmation of the rule for those cases by Wednesday. After that decision, I can prepare the review version.” I would add a preview link and a few example records in the approved working environment.

That message makes the current state, limitation, request and next step clear. Someone can help before a delay becomes unavoidable. “Working on the report” gives the recipient much less to act on. A percentage complete can also be misleading when the remaining question might change the entire calculation. I prefer to explain what has been checked and which decision remains open.

Uncertainty should be visible beside the numbers themselves. A qualification in a separate message is easily lost when someone copies a table. I would mark the preview as a draft with the closure definition still under review. Once the issue is resolved, I update both the note and the result. This makes early feedback possible while keeping the status of the work clear to anyone who sees it later.

Record your contribution separately from the team’s result

After finishing, I would keep a short record covering the problem, my scope, collaboration, the result, evidence and limitations. In our example, my contribution might include the transformation, identifier checks and refresh instructions. A colleague confirmed status definitions, while the manager clarified the report’s use. The team delivered the summary together. Those statements describe different levels of responsibility without competing for credit.

“Improved reporting” is too vague on its own. I would link to the file or task, explain the change and identify who reviewed the result. A prototype stays a prototype in that description. One person opening a dashboard does not yet demonstrate regular adoption across the team. Distinguishing delivery, use and business effects keeps a contribution record from becoming an unusually imaginative autobiography.

Consider some synthetic numbers. Preparing a comparable report manually used to take 45 minutes; the proposed method takes 20 minutes. Across four reports per week, the difference is 100 minutes. If maintaining the solution adds another 30 minutes each week, the estimated balance is 70 minutes. This is a conditional calculation for the assumed workload, without evidence that the saving will persist in every situation.

For a real record, I would describe the measurement method, the number of observations and the activities included. I would also check output quality and any work transferred to other people. Faster preparation achieves little if the recipient subsequently spends longer finding errors. Without measurement, I could still write: “Removed manual merging of exports; the effect on total time needs observation.” That is a specific, assessable change with an honest limit.

Help colleagues move forward with their own work

A colleague asks why their summary contains more tickets than yours. The immediate temptation is to take the file, fix everything and send it back. You know how to do it, so that feels efficient. But a similar question may return next week, and you may quietly become the owner of another report. I would begin by examining one case together.

I ask for the expected result, the actual result and the smallest relevant data sample that shows the difference. In this example, joining tickets to status history might create several rows for the same ticket identifier. I demonstrate how to detect that, then ask the colleague to apply the check to the remaining data. The useful lesson is recognising the cause and validating the result.

I also set a boundary: “I have twenty minutes now to help diagnose this. If the model needs rebuilding, let’s put that work in the queue and agree who owns it.” Adapt the wording to your relationship. An urgent incident may require a different response under the team’s procedures. An ordinary request for help should still have an explicit effect on your other commitments if it expands.

After the shared investigation, leave a short instruction or example. If several people encounter the same problem, suggest a team discussion. Atlassian’s Working Agreements exercise offers a way to agree how people work together. I would use that conversation to clarify where questions go, expected response times and the route for urgent cases. Help then has understandable conditions, without one person’s constant availability carrying the entire process.

Leave a solution someone else can take over

I would finish the handover with a reproduction attempt. Another person gets the instructions, access to the approved source and an example of the expected output. They try refreshing the summary and recognising an error. I watch for the points where they need information that seemed obvious to me. Those questions expose gaps in the description or in the solution itself.

The instructions should explain where the data comes from, which period it covers and what one record represents. I would include the sequence of actions, a ticket count check, known limitations and the maintenance owner. An experienced colleague may not need every click documented. They will need decisions that cannot be inferred from the table, such as the agreed closure rule and why certain records appear separately.

If maintenance stays with me, I confirm that responsibility. If another person takes it over, we agree when the transfer happens and how to report problems. Uploading a file to a shared drive does not automatically create an owner. Source changes may also make the instructions obsolete. It is useful to know who will notice and update them before that happens during a deadline.

This work can attract less attention than a new dashboard presentation, but it provides concrete evidence for a development conversation: someone can use the result without your continuous presence. It matters for technical specialists too. My article on data analyst career paths explores the wider choice between management, data science and business responsibilities.

Address the team’s problems and make risks explicit

Career advice can easily reduce everything to keeping your manager happy. I would ask what problem sits behind a request. The manager wants more charts because questions about workload keep returning in meetings. Perhaps clarifying one measure and showing missing data would help. Before adding another dashboard tab, I would explain that option and check whether it meets the need.

When I see a risk, I describe it with a reason. “A ticket can appear several times in this summary, so comparing individuals would be misleading. I can prepare a team summary after resolving that issue.” This example challenges the quality of an analysis without judging anyone’s intelligence or intentions. The conversation should lead to a decision about the work and a clearer understanding of its limitations.

Google’s account of Project Aristotle in re:Work identifies safety in asking questions, dependability and clear expectations among the factors associated with team effectiveness. Those findings concern Google teams and have limits when applied elsewhere. They offer no guarantee of individual promotion. I use them as a helpful reference when discussing everyday collaboration, rather than as a universal formula for career success.

If questions routinely lead to punishment or ridicule, a better update may not solve the underlying problem. I would document specific situations and use an available, safe route for raising the concern. One employee cannot carry full responsibility for an organisation’s culture. Improving communication is useful, but the environment also needs to allow an honest account of mistakes and uncertainty in the data.

Learn through a task and propose a small trial

I connect technical learning to a problem I am trying to solve. If manually combining exports introduces errors, I can practise the relevant transformation and validate it on a copy of data approved for that work. Completing an interesting course is insufficient reason to rebuild production reporting. I first compare outputs and ask someone to review the proposed approach and its maintenance needs.

A useful learning objective might be: “I want to explain independently why joining these tables adds rows, and prepare a check for that.” I know what to practise and how to assess progress. “Learn all of SQL” offers much less help with planning the coming week. A wider technical foundation grows through specific capabilities that you can demonstrate and combine in a real task.

I would also start personal ideas with a limited trial. Propose one report, an agreed amount of time and criteria for continuing: matching results, simpler operation and acceptance by the recipient. If the trial fails those criteria, record what you learned and stop it without inventing a success story. Discovering that maintenance costs outweigh the benefit is useful before the team commits to a larger change.

A feedback request should identify what needs assessing. Instead of “How am I doing?”, I would ask whether another person can reproduce the report and understand my explanation of its limitations. Then I turn the answer into a specific improvement. I do not need a new technology every week to show progress. Sometimes the valuable change is learning to finish and hand over work that I previously only knew how to start.

Discuss your next responsibilities explicitly

I would bring two or three concrete examples to a development conversation. One demonstrates delivery of an agreed assignment, another shows collaboration or knowledge transfer, and a third might concern a risk I identified. They do not need to be spectacular. What matters is that someone can assess my contribution, the result and its boundaries. A long activity list provides less clarity than a few well-supported examples.

I also explain what I want to try next. In our example: “I would like to lead a similar assignment from requirements through to handover. Which capabilities do I still need to demonstrate, and what task would let me practise them?” That opens a discussion about actual responsibility. We can then agree on support, assessment criteria and a date to revisit the topic. I write down the agreement afterwards.

More responsibility does not automatically mean promotion. Clarify whether this is a temporary trial, development within the current role or preparation for a specific position change. If the organisation cannot offer a next step, you need that information for your own decision. Good results and support for colleagues provide evidence, but they do not create an available role or a promise about employment terms.

For a starting exercise, try a two-week period. Choose one small assignment and agree on its outcome. Send one useful update, request a specific review and take the work through to handover. At the end, record your contribution and one improvement for the next attempt. You will have something practical to discuss: a piece of work whose choices, results and limitations you can explain calmly and precisely.