Reporting Up: Fostering Communication That Builds Trust

This is a guest post by Dee Ann Pizzica.

Have you ever been frustrated because you’re in the middle of a project, you’re working hard, and every time you turn around someone in leadership is asking you how things are going? It may be your manager, a team lead or the product owner, but the constant inquiries make you feel like others are afraid you’re not doing your job.

Whoever it may be, it doesn’t inspire confidence. Here are some ways you can communicate to promote trust and transparency within your team.

I sit in middle management on a distributed team. As a manager, my main function is supporting the team as they complete work. I was surprised to find that the majority of the time, this hinges on providing the right information to the right people at the right time so that everyone can achieve their goals.

Reporting information and progress in a fast-paced organization isn’t without challenges, but one thing I see time and time again is that proactive information builds trust.

In order to effectively build trust through proactive communication, there are things managers need to understand:

  • What they should report up
  • What the team should be reporting to them
  • When and where to share information to have the greatest impact

What Managers Should Report Up

Let’s start with what I report up, because that informs the expectations I have for my team.

Risks

I communicate several things to the leadership team, but the goal is to quantify the risks to deliverables and deadlines. Ultimately, I’m responsible for ensuring that my team is meeting commitments for new feature development, so I need to report any threats to on-time delivery. This information includes delays due to technical issues, unforeseen bugs, and any impacts to individuals or groups of staff members.

Project status and details

In my organization, the leadership team meets weekly. These check-ins are short and deliberate, and every contributor is prepared to speak to the status of their projects in flight.

We also keep a dashboard to track our projects. We update this dashboard regularly to reflect the current status. This usually means weekly, but if we’re having a busy week, it might be more frequent. The dashboard paints a clear and definitive picture of the progress that anyone in the company can access at any time.

We group each project by a functional area and track the following:

  • Project name
  • Original due date
  • Current due date
  • Project status (on track, at risk, delayed, completed)
  • Status notes

While every project has its own nuances and challenges, the dashboard reduces project information to simple dates and deliveries.

We also list any viable project under consideration. This provides visibility into any possible work that might impact the team in the next quarter.

Modern Test Case Management Software for QA and Development Teams

What the Team Should Report to Managers

There are a few things I always want to know about my team and the work they are doing. I have found that I feel a whole lot better about the situation when I don’t have to ask for these things. These are the basic pieces of information that reassure me that my team has their work under control.

If you’re stuck

Your manager or team lead doesn’t need to know every problem you run into and how you solved it, but if you’re going to lose half a day or more to an interesting (or uninteresting) problem, someone needs to know what’s going on.

  • When to say something: As soon as you know you’re stuck.
  • How to say it: Slack or some other chat tool is usually sufficient.
  • What to include: Indicate if you need help yet or not. Be prepared to answer questions about the problem, who you’ve talked to or what you’ve tried so far.

Note: If you’re looking for troubleshooting help, say so up-front and suggest a call or meeting.

Your manager can’t always see when you are struggling with a particular problem. Nor can we see all the ways you have attempted to work through it on your own. Depending on where and how you communicate with your team, it may not be obvious that you don’t know what to do next.

For every team and every project, it helps to set a threshold or timebox so you know when to ask for help. The timebox can range from an hour to several days. For many teams, there is no explicit rule; this means you may get stuck when everyone envisions their individual tasks are the most important ones. You might ask for help and not get any response in return.

It might be hard to admit that you’re confused, but knowing when to admit you need help is important. It’s worse to pretend you know what to do and waste time. The more time you lose, the greater the potential risks that your team can’t meet commitments. Your manager or team lead is there to help you unblock blockers, and they often have more leverage in getting others on the team to reprioritize.

That you’ve thought about what could go wrong

Before I became a manager I was a tester. Time in both roles leaves me obsessing about risks to the team’s success, so I always feel better when I see that my team has thought through things that could go wrong. It’s even better when my team has a plan for what to do in each of those cases. I’ve found that a list of risks, even without planned remediation, still gets the team thinking about how to build defensively.

  • When to say something: At the start of the project or as part of planning for any production launch.
  • How to say it: Project documentation that others on the team can access. This can be the output of a meeting or a document that anyone on the team can contribute to.
  • What to include: A list of potential risks and issues, severity if the risk should occur, and remediation or a rollback strategy.

Major scope changes and bugs

It happens all the time: You have an implementation plan, but some unforeseen issue comes up. Sometimes it’s a change in requirements. Other times the code doesn’t behave the way you thought it should and you need to head in a different direction.

  • When to say something: As soon as you see a major change in plans.
  • How to say it: Slack might be a good place to start. A quick huddle of the project team is often the most effective, especially if what you’ve found will impact others.
  • What to include: Indicate if you need help. Be prepared to answer questions about the problem and why the change is important. Discuss any impact to the schedule and functionality that may change.

Speak specifically and fluently on the topic, but also boil it down to the biggest risks in the most concise manner possible. What impact does this issue have for customers? How does this affect the work the team has currently? What is the impact to the value the product provides?

Managers and team leads are going to be interested in the details of problems and are often great candidates for assisting with resolutions. It’s best to include them in any discussion of a scope change or a major bug that may change the timelines and deliverables.

If you can’t be at work

Most managers don’t want to dictate your schedule, decide if you are too sick to work, or tell you to choose your job over your family. We would rather support you as you make these important choices. If we are able to offer you such flexibility, there is one key thing we need from you in return: You have to show up or communicate clearly if you can’t.

  • When to say something: As soon as you know you’ll be away.
  • How to say it: Slack or some other chat tool is usually sufficient.
  • What to include: Duration needed and a brief explanation.

And if you’re part of a distributed team and your manager doesn’t see you, don’t assume your manager knows that you’re back at work. This may seem kind of silly and obvious, but recently I had a miscommunication with one of my team members in this very situation.

One of the developers on my team had to be out for several days because the flu hit everyone in his house. He reached out to me the night before each anticipated absence. During the second affected week, I hadn’t heard from him. He didn’t call out that he wasn’t going to be working, but I also didn’t see him active on Slack. I decided to have the difficult conversation and tell him I needed to know if he’s not working. He assured me that he’d been hard at work the entire day prior. Given his current assignment, he didn’t have any reason to say anything to me and felt awkward just announcing he was back at work. When in doubt, over-communicate.

If you’re okay

Life presents all kinds of challenges. Most everyone I’ve worked with cares deeply for the well-being of their teams. It’s not just because we want to see work completed, but also because we like the people we work with and want to see them succeed.

I try to stick with open-ended questions to give my team the opportunity to share at whatever level they’re comfortable.

  • When to say something: As soon as you’re comfortable speaking up.
  • How to say it: An in-person meeting or call is usually best.
  • What to include: If you need time away, what support you need, and if you’re feeling unproductive or distracted.

This is important because when you’re distracted by personal issues, it can have a direct impact on your performance. Sometimes it’s better to ask for time off than to try to silently work through something that is demanding your attention. If it’s an issue that will take a long time to resolve, it may not be reasonable to take time off, but it’s still best to discuss it. Your manager will have no way of knowing how to help you if you don’t bring it up.

Status

Last but not least, a daily status update goes a long way toward building trust. This doesn’t need to be an exhaustive list of everything you’ve done in a day, but it should hit the highlights.

  • When to say something: Daily.
  • How to say it: Slack or a standup meeting.
  • What to include: Any accomplishments, how you’re feeling about the work and if you need anything from anyone else.

Some teams manage to pack a ton of value into daily standup meetings. Others find these meetings disruptive and distracting, or individuals feel pressured to justify their existence.

If your team is questioning the value standups provide, try a written daily status update. This doesn’t even need to be from each member of the team. Often, one contributor from the team can summarize the day’s achievements and struggles in a few short bullet points. This is enough for the management team to report up, and it can work well as long as the team members communicate with each other.

Report Up and Build Trust

The more actively the team reports up, the more comfortable communication can be. Ideally, your manager will set expectations for you based on their needs.

If you’re ever in doubt, be proactive! Ask your manager about the frequency and type of information that would help them be more successful. If you need information and support, you should ask for that too. Trust is a two-way street, and you’ll get much farther with open communication.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform


Dee Ann is a passionate and curious software tester. She has over 15 years experience in support of small and enterprise-scale custom mobile and web applications with highly complex business logic for clients across a wide variety of industries. Dee Ann is currently working as the Director of Engineering at BRD where she collaborates with a talented team on a cryptocurrency wallet app for iOS & Android.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

Agile

Agile QA Process: Principles, Steps, and Best Practices

The agile QA (Quality Assurance) process is a set of practices and methodologies aimed at ensuring that software developed within an Agile framework meets the desired quality standards. It aligns with Agile development principles, emphasizing collaboration,...

Agile

Regression Testing in Agile

In TestRail, you can triage risks faster by monitoring the progress of all your regression testing activities in one place

Agile

Crafting a Robust Test Strategy: 6 Key Approaches

Effective testing isn’t a stroke of luck; it’s meticulous planning. Detecting and resolving issues early is the crux. This necessitates a well-crafted test strategy that sheds light on the entire testing process.