How I use Grafana dashboards to run engineering meetings instead of slide decks
Replacing weekly status slides with live Grafana dashboards eliminated performative reporting and forced teams to instrument what matters.
For eighteen months, our weekly engineering meeting followed the same format. Each team lead spent two hours before the meeting building slides. Status updates. Burndown charts. Risk registers. A formatted summary of what everyone already knew from Slack and Jira. The meeting itself took an hour. The total cost was roughly twenty engineer-hours per week for a meeting that produced no decisions.
I killed the slides. I replaced them with five Grafana dashboards. The meeting dropped to thirty minutes. Decision quality went up. Preparation time dropped to zero.
Leadership got more concrete for me once I realized release engineering and infrastructure are really trust systems. It also builds on what I learned earlier in “The founder said ship in two weeks. I said no. Here is what happened..” The infrastructure stack, ctrlpane, and even my dotfiles all orbit the same idea now: the best teams move fast because the defaults are stable, not because the heroics are impressive.
The Five Dashboards
Every weekly engineering meeting now opens with the same five dashboards pulled up on a shared screen. No slides. No preparation. Just live data.
- Deployment frequency and lead time: how often we ship and how long changes sit in the pipeline. This replaced the “what did we ship this week” slide with data that updates itself.
- Error budget burn rate: how much of our SLO error budget we have consumed this week, this month, and this quarter. This replaced the incident summary slide and made reliability visible as a resource, not just a goal.
- Feature progress: story points completed versus planned, but displayed as a trend line over the last eight sprints, not a single-sprint snapshot. This replaced the burndown chart that everyone gamed.
- Infrastructure costs: daily AWS spend with week-over-week comparison. This replaced the quarterly cost review that always surprised everyone.
- CI pipeline health: median build time, flaky test rate, and deployment success rate. This replaced the “developer experience” section that nobody measured.
What Changed Immediately
The first change was preparation time dropped to zero. Nobody spends time building slides because the data is live. Team leads walk into the meeting and see the same dashboards everyone else sees. There is nothing to prepare, curate, or spin.
The second change was more important: conversations became data-driven instead of narrative-driven. When a team lead used to say “we had a good sprint,” nobody challenged it. When the deployment frequency dashboard shows a 40% drop in deploys and the error budget shows a 3x burn rate, the conversation is different. Not confrontational. Just honest.
The third change was the most valuable: teams started instrumenting things they never measured before. When the CI pipeline health dashboard showed that flaky tests were consuming 30% of build time, the platform team prioritized fixing them. Not because I asked. Because the dashboard made the cost visible to everyone, including the engineers who were writing the flaky tests.
The Meeting Format
The meeting is thirty minutes, structured identically every week:
- Minutes 0-5: Walk through the five dashboards. Anyone can flag an anomaly. No narration unless something looks wrong.
- Minutes 5-15: Discuss flagged anomalies. What happened, what are we doing about it, who owns the follow-up.
- Minutes 15-25: Decisions. Anything that needs a decision from the engineering leadership group gets discussed. No decisions that could be made asynchronously are allowed in this slot.
- Minutes 25-30: One topic deep dive, rotating weekly. A team lead or IC presents a technical challenge, architectural decision, or post-mortem for group input.
The strict format eliminates drift. When someone starts narrating their sprint, I point at the dashboard. The data is there. We do not need a verbal summary of what the data already shows.
What I Got Wrong Initially
The first version of this approach failed. I built the dashboards and threw them into the meeting without context. Team leads felt exposed. Error budget burn rates were visible to everyone, and some teams felt publicly shamed when their numbers were bad.
The fix was to reframe the dashboards as team-owned, not leadership-owned. Each team controls their own dashboard panels. They choose what metrics to display. They set their own targets. The engineering-wide dashboard aggregates team dashboards, but each team decides how their data is presented.
This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build lifeos and bisen-apps too.
Live dashboards only work when the team owns the data. If dashboards feel like surveillance, people will game the metrics. If dashboards feel like tools, people will instrument what matters.
Six months in, the dashboards have become the single most useful engineering management tool I have. Not because they replaced meetings. Because they replaced the fiction that slides create. Slides tell a story. Dashboards show what actually happened. Good engineering leadership requires seeing what actually happened, especially when the story is uncomfortable.
The shift from slide decks to live dashboards changed how leadership consumed engineering metrics. Instead of a monthly presentation with stale numbers, they could check the dashboard at any time and see current state. The transparency reduced the number of status update meetings by half because the information was always available. Engineers spent less time preparing presentations and more time improving the systems the dashboards monitored. The dashboards also created accountability in both directions — leadership could see when reliability degraded, and engineering could show the impact of infrastructure investments in real time.