Why Your Report Developers Need More Than Just Technical Training

I've been running Power BI and wider analytics training for many years now. I have been working in business intelligence for over a decade, starting with a pure SQL role, moving to an engineering role and naturally gravitating more towards the part of business intelligence which put me in the seat of understanding and talking to the business about their needs, objectives and challenges. I like to think through this change I saw many of the personas that exist and developed a deep understanding of what actually creates real value for organisations investing in their BI developers, report developers, data analysts... or whatever title we have now or will have in the future.

Here is the thing I find that is so common... it's so easy to lose sight of the purpose we use data in the first place, the need of business intelligence. But here it is, it's to improve the decision-making process. That's it! It's about helping us make better decisions to improve some part of the organisation, its people and the direction. Whether it's generating more sales or profit, reducing expenses, improving efficiency, being more compliant, mitigating risks or driving up productivity. We do this by establishing solutions that offer actionable insights. Yet, so many solutions I see being produced end in disappointment, even though we invested so much time, money and effort.

The "So What" Moment

Many years back, I received some feedback from a C-Level person positioned in one of the largest retailers. This moment stayed with me and was a turning point in my career. I had done everything right technically… was involved with a large team of business analysts, data engineers and assisted in the development of the data platform, run the modelling workshops, designed the solution, built a set of beautiful Power BI reports that sat on top and ingested the needed data. It was a great achievement and everyone loved the reporting solutions. I have to say, the look and feel of them was next level. Then came the time to showcase this to a very senior person. I walked through the underlying architecture, the data model and how it enables self-service and of course the reports. The response… "So what". My heart dropped. After asking a few questions to understand more it was pretty simple as I think back to it. They were simply saying so what if we have used the right tech, structured the model correctly, built beautiful reports, used the analysis features, etc. All they cared about was how this solution would benefit the business and help them achieve their goals. That's when it hit me… we had built a technically perfect solution that didn't clearly answer the business questions that actually mattered.

The Over-Emphasis on Technical Training

Now, don't get me wrong, I'm not saying technical training isn't needed - of course it is. However, if we want to build higher value reporting solutions that are actually used for the right reasons and genuinely offer value, now more than ever we need to go beyond technical abilities.

Yes, there are people with multiple roles, some working on the tech side, some the business side and they have separate responsibilities. Not implying one person must do it all! But if we're focusing specifically on report developers, and you're looking to upskill your report developers, a big chunk of that development should go on what happens before even launching Power BI, Tableau, Qlik, MicroStrategy or ANY other BI tool of choice.

I believe the training offered must have an element of deriving real requirements, working with end users more closely, facilitating workshops, learning techniques on how to pushback, reading the room and integrating more deeply with the business. We always hear about making the business more data literate, but how about making us, report developers, more business savvy?

Also, just to add, whilst I am writing this blog as being beneficial for the organisation to invest more on their report developers, I believe this is incredibly important for the individuals also. With AI advancing rapidly, my thinking is those who just focus on receiving requirements and building reports... well, AI is here to stay and it's getting better at that every day. If you want more on this topic, read my blog: Will AI Replace The Report Developer?

The Shift: From Tool Mastery to Report Effectiveness

The shift I am starting to see (and pleased to see) is this… More organisations are moving away from just wanting report developers who can master the tools and instead are looking for people who can deliver effective reports. They want developers who understand the "why" behind the report, who can challenge requirements when needed and who can ensure that what gets built actually drives some sort of business outcomes.

This shift excites me because it addresses the fundamental gap I've been preaching about for years. Because when report developers operate with this mindset, everything changes. The reports they build aren't just technically sound, they're strategically aligned. They don't just display data, they answer real business questions. They don't just get deployed, they get used and more importantly, they drive action. And look, I should also say, does every report hit the mark? No it does not. However, I always say let's at least build with action and value in mind as if we don’t surely we are doomed from the start in building something that simply won't deliver.

So, here's the reality… most report writer or developer training don't include this needed information. They start with the: Let's start ingesting data into the canvas and BUILD, BUILD, BUILD! It's about features, functions, the best practices for data modelling and visualisation and all other shiny stuff relevant to the tool. Again, are these critical skills (the tech side)… absolutely. But if that's where the training stops, we're only giving them half of what is needed

Training Beyond the Technology

So, what does the other half look like? I've recently been upskilling people who aren't even using Power BI... they're using Tableau and Qlik. In these training sessions, we have zero tech talk and I mean ZERO! Instead, we focus on the strategic and analytical thinking that must happen before anyone touches a tool. This is my data storytelling and requirements gathering service, and as I said I am genuinely excited to see more organisations seeking this for their workforce.

The feedback has been phenomenal. Here's what participants have said until now:

• We're having conversations we've never had before... conversations we should have had a long time ago
• This goes beyond reporting... it forces us to really think about what we are doing
• It's nice having a clear approach we can follow
• Spending less time in Qlik made the outcome better

You see, being good at building reports and dashboards needs time away from the tech, away from the data, time away from your screen.

What Report Develop Training Should Also Include

If you're evaluating a training course or reporting writing training program for your reporting team, here's what you should ALSO be looking for. These are SOME of the non-technical elements that will determine whether your team builds reports that sit unused or solutions that drive real business value.

1. Discovery and Requirements Gathering Skills

Your training should teach report developers how to run requirement gathering sessions, not just collect requirements by asking "What do you want". This means learning to facilitate conversations with end users, ask probing questions and uncover the real business need, not just transcribe what someone thinks they want.

Why this matter? Most failed reports fail because they solved the wrong problem or simply because there wasn't really a need in the first place. I would much prefer the issue of identifying a solution is not needed from the start, rather then building it, investing time in it and only finding out in the end. If your developers can't discover what's actually needed (or not needed), all their valuable time and skills can be used elsewhere. From personal experience, as a person who has been developing reports for many years, I would much rather pause a reporting solution/project and rethink, instead of continuing down a path where chances of success are slim. It does hit your confidence!

So, our report developer training should have elements on: How to prepare for requirements workshop, who to involve, how to identify the right people (very important), how to guide the conversation, techniques for getting stakeholders to articulate their genuine needs rather than jumping straight to "I want a dashboard and so much more.

2. Strategic Questioning Techniques

As mentioned, we should stay away from just asking "What do you want?" and instead ask more bespoke questions that uncover purpose, context and business impact:

• What is the purpose of the solution?
• Is it genuinely required, worth the time/money?
• How are they hoping the solution will help?
• What type of solution is it?
• Does it relate back to business objective or challenge?
• What are the KPIs?
• What elements impact those KPIs?
• What are the actions they can take?

So, our report developer training should have elements on: A framework of questions to ask, how to challenge requirements professionally and how to identify when a report isn't actually the right solution.

3. Business-First Thinking

Training should emphasise keeping early conversations focused on business needs, not technical capabilities. Your developers should be supported in learning how to understand problems, decisions and outcomes before discussing data sources, visualisations or features. When conversations start with tech, you go down the path of building for the sake of it and not what's genuinely needed. It might look good, spark early excitement, but not deliver the outcome in the end.

So, our report developer training should have elements on: How to structure requirements sessions, what to cover in each stage, and how to redirect technical conversations back to business value until the problem is clearly defined.

4. Documentation and Stakeholder Alignment

Your developers need to learn how to capture requirements in a way that creates shared understanding and gets formal sign-off before building begins. This includes creating data dictionaries, defining KPIs clearly and producing artefacts that stakeholders can review and approve. Most "that's not what I asked for" situations happen because there was no clear, agreed-upon definition of success before development started. Teaching this skill prevents costly rework and failed projects.

So, our report developer training should have elements on: Templates and frameworks for documenting requirements, how to get meaningful sign-off (not just "looks good") and how to identify gaps in understanding before they become problems.

5. Post-Implementation Follow-Through

Training should cover what happens after go-live of a reporting solution. This now goes into familiarisation, support, governance and empowering the users. It's how to support adoption, monitor usage, gather feedback, and measure whether the solution is driving intended outcomes.

So, our report developer training should have elements on: How to plan for adoption, what metrics to track, how to conduct follow-up sessions and when to iterate based on real-world usage.

How to Get Started

If you're looking to shift your report developer training beyond just the technical, here's where to begin: get a framework and build on it.

Great requirements gathering sessions don't happen by accident, they need some rails. A simple, well-built framework gives the conversation structure, keeps the right people engaged and lifts everyone's confidence, including your developers.

The framework should be visual and collaborative. In Metis BI we use Miro boards, A3 sheets with sticky notes or similar tools so ideas are visible and shared. This also depends on the organisation. Show what you're discussing at all times, write down the business challenge and why it matters, record the KPIs, link each one to its drivers, levers and likely actions. Every KPI should have a clear path to impact.

This can be taught internally and then adapted to your organisation, because every organisation and its users are different. What matters is having a repeatable approach that consistently delivers results, not just reports.

Note: If you want deep dive into the full items to include in Power BI Training, be sure to read: What is Power BI Training?

Summary

Technical training will always be important, your report developers need to know how to use the tools. In Power BI, think data modelling, DAX, data visualisation... But if that's where all the focus goes, you're setting them up to build technically perfect solutions that miss the mark on business value.

The organisations that are getting real ROI from their BI investments aren't just training their people on Power BI, Tableau or Qlik. They're equipping them with the skills to understand/identify business problems, facilitate meaningful conversations, ask the right questions and build solutions that drive actual decisions and actions.

This isn't about turning your report developers into business analysts. It's about giving them the additional elements needed to bridge the gap between technical execution and business value. That's where the real impact happens and it's what separates reports that get used from reports that get ignored.

Ready to Transform Your Report Developer Training?

If you're tired of investing in BI solutions that don't deliver, or you're seeing the gap between technical capability and business value in your own team, let's talk.

At Metis BI, we've developed a framework that's been refined over years of working with organisations just like yours. We teach report developers how to run effective requirements sessions, ask strategic questions and build solutions that are aligned with business outcomes from day one.

This isn't generic training, it's tailored to your organisation, your challenges and your team's needs. We focus on the skills that don't come from YouTube tutorials: facilitation, stakeholder management, critical thinking and translating business problems into reporting solutions.

Get in touch to discuss!