How do you present results to different levels of an organisation?

Introduction

The purpose of this article is to explore how to tailor the presentation of performance testing results to different levels of an organisation and avoid common pitfalls. While audiences are often described as “technical” and “non-technical,” a more useful distinction is between those who are detail-oriented and those who are outcome-focused. Effective communication is essential to avoid misunderstandings, reduce friction, and ensure your work drives the right decisions.

Performance Testing is the process of validating that your infrastructure and/or application can handle the expected volume of users and transactions, while meeting response time and resource utilisation requirements. Communicating the results of this testing is just as important as the testing itself—different stakeholders care about different aspects of the results.

Detail-Oriented Stakeholders (Engineering Level)

Engineers involved in development and implementation are primarily interested in root causes and technical details. They may want to participate in testing, review scripts, and delve into metrics such as response times, throughput, and error rates. They value:

• Root cause analysis
• Logs and traces
• Repeatability and consistency of issues
• Access to raw data and dashboards

Best Practices:

• Use screen sharing or pair working to review results collaboratively
• Provide access to interactive dashboards and logs
• Include detailed metrics and technical context

Common Mistakes:

• Over-simplifying data
• Sending static reports or screenshots instead of live access

Outcome-Focused Stakeholders (Senior Leadership)

Senior stakeholders are more concerned with risk, readiness, and business impact. Their key questions are:

• Is the system ready for launch?
• Are there any risks or blockers?
• What is the effect on users or customers?

They prefer high-level summaries, visual dashboards, and clear risk assessments.

Best Practices:

• Use traffic-light indicators (e.g., Green/Amber/Red) to show test status
• Summarise key outcomes and align them with business goals
• Highlight only critical issues and their impact

Common Mistakes:

• Overloading them with raw data or technical jargon
• Failing to connect test results to business requirements
• General Communication Advice

Regardless of the audience, some principles apply universally:

Tie tests to business requirements: Always clarify what each test is validating and why it matters. Answer “So what?”: Every graph or metric should have a clear takeaway. Use visuals: Charts, dashboards, and infographics can convey complex information quickly and clearly.

Real-World Examples

Working with Engineers

After a failed test revealed long response times and errors, I used Application Insights and Azure Monitor to trace the issue to Cosmos DB, which was returning HTTP 429 errors. Collaborating with engineers, we increased the request limit in the short term and optimised indexes and code to reduce request units in the long term.

The view above can be shared as a link and would show a live view from the Azure Portal. The specific issue is evident, and further metrics and investigation can be efficiently conducted from this starting point.

Working with Senior Stakeholders

I created a Jira dashboard that summarises test statuses using a traffic light system (Not Run, Red, Amber, Green) and lists defects with a Severity Level 2 or above. Each item could be expanded for more detail, allowing stakeholders to drill down only when needed.

The view above is a good example of a dashboard provided by the X-Ray test management tool, which shows how you can offer a live view of progress and key issues.

Conclusion

I think that tailoring your communication to your audience is essential. Engineers need detail to fix problems; senior stakeholders need clarity to make decisions. By aligning your presentation style with their needs, you’ll improve collaboration, reduce confusion, and drive better outcomes.