Long Suciu built a suite of Power BI dashboards at Gartner that pulled directly from Jira data and refreshed daily. In this segment of his conversation with Patrycja Radwanska on the Let’s Talk Operations series, he explains why the dashboards worked when most internal dashboards do not, how sprint goal visibility changed the way engineering managers spent their mornings, and why showing people the size of their backlog is the most efficient path to getting them to clean it up.
The Design Principle: Readable, Accessible, Understandable
Suciu is blunt about what makes a dashboard useful. It is not the sophistication of the visualizations or the number of data sources it aggregates. It is whether the audience it was built for can read it, interpret it, and act on it. That sounds like the lowest possible bar. It is, in practice, the bar that most internal dashboards fail to clear.
The Power BI dashboards he built were designed with engineering managers and product leaders as the primary audience. Not data analysts. Not BI specialists. People who had 15 minutes in the morning before their first meeting and needed to know if anything required their attention. Everything that appeared on the dashboard had to pass a readability test: could someone who opened this for the first time understand what it was telling them within 30 seconds?
Sprint Goals on a Single Screen
The first dashboard showed every team’s stated sprint goal. Not buried three clicks deep in a Jira project. Not in a Confluence page that nobody had updated since the previous sprint. Right there, on one screen, all teams visible, updated daily.
The effect on organizational behavior was immediate and surprisingly broad. Engineering managers could see at a glance what every team was working toward. A product director who believed another team was going to work on their dependency could see, without asking anyone, that the team had other priorities. That visibility alone eliminated an entire category of meeting – the “just checking in to see if you are doing the thing you said you would do” meeting that consumes hours across an organization and produces nothing except the confirmation that you should have looked at the dashboard.
“A product director could read what one team might be doing and then start the question – but I need them to do something for me.”
The dashboards also showed sprint progress and work distribution within each team. This served a more nuanced purpose: before asking a team to drop what they were doing for an urgent request, a stakeholder could see what would have to be traded off. The conversation shifted from “can you do this?” to “what are you willing to give up to do this?” – which is a fundamentally more productive question because it acknowledges that capacity is finite and priorities are real.
Backlog Visibility: The Dashboard Nobody Wanted
The backlog size dashboard was, by Suciu’s own description, the one that made people the most uncomfortable. When you put every team’s backlog size on a single screen, the disparities are impossible to ignore. Some teams were going hand to mouth, with barely enough work queued up for the next sprint. Others had backlogs so large that, if they stopped creating new tickets entirely, it would take them two years to complete what was already there.
The uncomfortable truth was that most of those two-year backlogs were full of tickets that nobody would ever work on. Ideas that seemed urgent six months ago and had been quietly forgotten. Bugs that were not really bugs. Feature requests from stakeholders who had moved to different departments. The backlog had become a digital attic – a place where things went to be stored indefinitely and never examined again.
Suciu’s approach to cleanup was deliberately framed in a way that was hard to argue with. He would identify tickets created over a year ago, calculate what percentage of the backlog they represented, and then ask: “Are you okay if I just archive them all?” Phrased that way – logical, specific, quantified – the emotional resistance to deleting anything met the practical reality that nobody was ever going to work on it.
“It doesn’t make logical sense for them to say no out loud, even though deep down inside they’re like, no, we don’t get rid of tickets.”
The objection that came up most often was “what if that bug comes back?” Suciu’s answer was disarmingly simple: if it comes back, you create a new ticket. Or you unarchive the old one. The cost of maintaining a thousand irrelevant tickets in perpetuity – the cognitive load of scanning past them, the distortion they create in any metric that references backlog size, the false sense of busyness they produce – far outweighs the cost of re-creating the occasional ticket that turns out to have been relevant after all.
Incremental Dashboard Expansion
Suciu did not build all the dashboards at once. He started with sprint goals, proved the value, and then incrementally added new views that introduced new concepts. This was a deliberate strategy. Each new dashboard was an opportunity to change behavior – not through mandates, but through visibility. When people can see the data, they start asking questions about the data, and those questions lead to the conversations that drive improvement.
The principle underneath all of it is one he returns to throughout the interview: tools should reinforce the behavior you want, not create behavior you did not intend. A dashboard that shows sprint goals reinforces the behavior of setting goals. A dashboard that shows backlog size reinforces the behavior of keeping backlogs clean. The tool does not do the work. It makes the right work visible, and visibility – genuine, daily, impossible-to-ignore visibility – turns out to be one of the most powerful levers an operations leader has.
For the full interview breakdown, see our complete Expert Insight with Long Suciu.
Tools Mentioned in the Interview
The following tools and platforms were referenced during this conversation.
Related Content
Scaling Product Operations Without Breaking Teams: Expert Insights with Long Suciu
Long Suciu has spent 25 years redesigning how product and engineering teams plan, prioritize, and ship. He breaks down why story points are often the first thing to cut, how a six-week quarterly planning cadence brought alignment to 30+ teams at Gartner, and why tools must reinforce behavior rather than replace it.
Cutting Lead Time From 52 Weeks to 13 by Mapping the Customer Journey
Long Suciu helped a travel industry API team cut their delivery lead time from over a year to a single quarter. The method was not a process overhaul -- it was a conversation about customer journeys that caused a product director to see a feature they could ship immediately.
A Six-Week Quarterly Planning Cadence That Scales Across 30 Teams
Long Suciu built a quarterly planning process at Gartner that eliminated the chaos of ad-hoc project sponsorship. He breaks down the exact six-week cadence -- think, share, solidify -- that brought alignment to more than 30 product teams.