When I stepped into my first management role, I was starting from zero in almost every sense. New product, new team, new people, entirely different processes. I did what any reasonable person would do: I talked to everyone. But conversations alone weren't enough. I needed to see what was actually going on.
Why I started building dashboards
I approached those first weeks on two tracks in parallel. One was the human track: having casual conversations with literally everyone, understanding what people cared about, what frustrated them, what they were proud of. The other was the data track: reading the dashboards that already existed, and then building my own.
Building my own turned out to be the more valuable exercise. When you read someone else's dashboard, you get answers. When you build your own, you get questions. Every metric I tried to define forced me to ask: how does this work? Why do we track that? What do we do if X or Y happens? That process of construction made me understand the team far better than any handover document could have.
There's a simple way I think about why data matters in management: how can you drive something without seeing how it reacts? It's like driving a car or flying a plane without knowing your speed, your location, whether you're accelerating or slowing down. You might get somewhere, but you're flying blind. Once you have metrics, you can watch how they change after you make a decision. You can set a goal and track whether you're moving toward it. You can show engineers exactly what you see and where you want to get, which gives them a reason to care.
What the data actually showed
Pretty quickly I ran into the limits of Jira. I wanted to see something specific: of all the tickets a team completes, how many get done within a single sprint? How many spill into a second sprint? A third? A fourth? It sounds simple but Jira doesn't support that kind of view out of the box.
Fortunately we had EazyBI, a reporting tool that sits on top of Jira and lets you write custom measures. The name suggests it's approachable. It isn't. It takes real time to learn, and even more to get good at. But the payoff is that you can build whatever view you actually need, not just what the default tooling allows.
Over several quarters I went from getting comfortable with it, to building dashboards in it, to adding more sophisticated measures like rolling averages and cycle time distributions. What started as a survival tool became something I genuinely relied on to understand team patterns, spot anomalies, and have honest conversations about work.
The lesson I didn't expect: the data can lie
The most important thing data-driven management has taught me isn't how to build dashboards. It's how to question what they show.
At one point I was looking at cycle time across teams. Most teams were sitting around 20 to 30 days. One team was showing over 60. That's a significant gap. The obvious interpretation would be a performance problem. But before drawing any conclusions, I wanted to understand the number itself: how is it calculated, and which tickets are included?
I started opening the actual tickets behind the metric and going through their histories manually. What I found wasn't a team working slowly. It was tickets that had been forgotten: issues left sitting in "In Progress" or "In Review" for months, slipped off the team's radar during busy periods or after priorities shifted. They were outliers dragging the average up. The data was technically accurate. The story it was telling was completely wrong.
I marked those tickets as outliers to correct the metric, and created a new automation to catch similar situations going forward. The cycle time went back under 20 days. A problem that looked like a team health issue turned out to be a data hygiene issue.
That episode shaped how I approach every metric now. A number without context is just a number. Data tells you where to look, not what to conclude. You still need judgment.
Predictability as a proxy for team health
One of the metrics I track across teams is sprint predictability: the percentage of committed work that actually gets completed in a sprint. It's not about whether plans are sacred. Plans change. What predictability measures is something subtler: whether the team has a realistic picture of its own capacity.
Consistently low predictability is a signal. Sometimes it means the team is over-optimistic in planning. Sometimes tickets get pulled in before their prerequisites are ready. Sometimes work isn't being broken down small enough to actually close within a sprint.
With one team I spent about three months on this directly, through sprint coaching and agile mentoring. The coaching wasn't abstract. It was specific: don't include a ticket in the sprint if the prerequisite work isn't done yet, it won't get finished and it will just steal your mental capacity. Break work into smaller pieces. Smaller PRs are easier to write, easier to review, and actually get merged. The goal was to help the team feel less stuck, less burned out, and to see real progress rather than just effort.
Over roughly three months, that team's predictability roughly doubled, from around 25% to around 50%. The number mattered less than what it represented: a team that was planning more honestly, feeling less overwhelmed, and moving forward with more consistency.
Making the knowledge available
After spending considerable time learning EazyBI properly, I made a short series of internal videos for other managers. About three videos for about 20 minutes each, walking through how to set up analyses, build dashboards, link them from Jira, and define custom measures.
The motivation was simple: I had spent a lot of time figuring this out. If I could give someone else a shortcut, I should. It's not a grand philosophy, it's more like reverse thinking: what would I have wanted when I was starting? Someone to show me the basics so I wasn't spending weeks in trial and error.
I do the same thing with books. I lend and share books with peers and colleagues regularly. Knowledge that sits with one person is less useful than knowledge that circulates.
Making work visible, as a concept, extends beyond dashboards. It's also about making what you've learned visible to the people around you.
If you're managing a team and working through similar questions (building visibility, making metrics meaningful, or figuring out what to actually measure), I'd be happy to think it through with you. Get in touch.