I Showed My Team a Dashboard. Two Weeks Later They Showed Me Theirs.

I was building the wrong thing, carefully

For about a month I was writing an app called People Manager. It was going to be the one place I looked at my engineering team at Career Team: tickets, pull requests, cycle time, the things I bring to a one-on-one. It had a plan folder, a design, a few hundred commits. It was also going nowhere fast, and it took me a while to see why.

I was thinking like a developer, not like an AI orchestrator. I had sat down to build the thing the way I would have three years ago: a schema, a server, a page at a time, every screen typed into existence. Meanwhile the tokens that could have built it were being eaten by the other thing I had made, the robot that reviews my team's pull requests. I was spending the machine on the work and spending myself on the typing, which is exactly backwards.

I kept asking how to build it. The better question was what I wanted to see.

So one afternoon I asked the better question. I asked Claude for a dashboard instead of an app, pointed it at the data, and handed it People Manager as a reference for what I wanted. It was done before I had finished being skeptical about it. That dashboard is called Crew Watch, and I am now fairly sure I do not need People Manager anymore.

In fairness to the timing, I was already building dashboards with Claude before it was a feature. The review board was one. Then Anthropic shipped Claude Dashboards on October 8, and what I had been doing by hand got easier: a dashboard became a thing you ask for, pin, and keep, rather than a page you coax into existence. That launch is what got me to try the lazy version of People Manager at all, and the announcement is how I found it.

That is the small story. The bigger one is what happened after I showed it to my team.

Every screen in this note runs on mock data. The dashboards are the real ones, but every person, ticket, pull request and number in them is invented for this post. The real versions hold my team's work and Career Team's data, and those stay at work. This note is here to show how the tools work and maybe nudge you to build your own, not to show what is in mine.

The review kit, now with a window

The first dashboard I leaned on was the board for my PR review kit, the set of Claude skills that reviews my team's pull requests and posts under my name. It never approves or merges; approval stays mine. How it got from one hand-run skill in August to what it is now, and how every part of it works, is its own note: Seven Hundred Commits to Teach a Reviewer It Was Wrong. Here I only want the window.

What changed most is that I stopped managing it from a terminal. Every pull request the kit has touched has a card on the board, in the column of whoever owes the next move. I can queue one by pasting a link, correct a finding, see which lens has been wrong lately, and watch whether precision and cost are moving the right way. The reviews run on their own. I just get to look at them like a person instead of reading log files like a raccoon going through a bin.

The kit goes round and round. The one step it cannot take sits outside the circle.

Crew Watch, attempt number four

Crew Watch is the view I take into one-on-ones and planning. It took me four tries to get there, and the first three were all reasonable at the time.

Four tries at the same view. The third one did not ship, and it still did the most work.

DevLake deserves more credit than one box in a diagram. Apache DevLake is an open-source tool that pulls your Jira and GitHub history into one database and puts dashboards on top for cycle time, review time and what finished per sprint. It also has a dashboard for DORA metrics, including how often changes reach production and how long they take to get there. DevLake taught me what those numbers even were. Before it, I had opinions about how the team was doing. After it, I had a lake of real data and a set of queries that defined each metric precisely, which is the part that carried forward. When Crew Watch came along, those definitions became its spec, and the audit I ran checked Crew Watch's figures against DevLake's before I trusted them. DevLake answered the questions it was built for. It just was not built for mine, which were about people rather than pipelines, and that gap is what the next two tries were for.

DevLake measured the pipeline. My questions were about the people in it.

The honest footnote is that the afternoon was not really an afternoon. Crew Watch was fast because People Manager already existed. A month of deciding what the view should show, which numbers I trusted and which questions I actually ask in a one-on-one, was sitting in a plan folder, and the dashboard got to read all of it.

The app did not ship. The thinking inside it did.

That is the part I would underline for anyone trying this. The expensive work was never the code. It was deciding what matters, and no model did that for me. A month of my judgment, written down, is what let an afternoon of Claude's typing land. I will take that trade every time, and I would not tell anyone the dashboard came from nothing.

I am keeping this part about how it works rather than what it shows, because what it shows is my team, and that stays at work. A small script pulls from Jira and GitHub into one data file, the dashboard renders it, and an audit I ran against the old DevLake numbers caught the places where the two disagreed before anyone saw a wrong figure in a one-on-one.

What it changed in one-on-ones

Before Crew Watch, the numbers we looked at were the usual ones: commits, lines changed, pull requests opened. I consider those unproductive stats. They count activity, and nobody walks out of a one-on-one knowing what to do differently because their commit count was average.

So I built Crew Watch to be people-centric. Each person is compared, anonymously, to the rest of the team, so the comparison points at where to focus instead of at who is ahead. The questions it lets me ask are the ones I actually want answered:

• Someone moves really fast. Good. Maybe we should look harder at code quality on their work, so the speed is not borrowing from later.
• Someone has a lot of kickbacks. Then the question is why. Perhaps the tickets are not written well, perhaps the ticket is not being read closely. Either one is fixable, and they are fixed in different places.
• Someone is a senior. How many code reviews do they do compared to the team? A senior should be carrying more of the reviewing, and the number shows whether that is happening.
• How do your story points weigh against how long the work takes, compared to the team average? That is a conversation about estimating, not about effort.

I wanted the feedback I gave to be something a person could act on.

I frame it the same way: the numbers are a diagnostic and a comparison with the team, not a grade, and they are read over a quarter rather than one sprint. That framing is what lets someone hear "your kickbacks are high" as a puzzle to solve together instead of a verdict.

It landed. As a snapshot, over five weeks of one-on-ones:

• The dashboard came up in most of them, and nobody pushed back.
• One developer said that seeing their numbers next to the team's finally gave them a clear direction.
• Another called it a useful tool for self-reflection.
• Several left with one concrete thing to work on, a root-cause look at their own kickbacks or a daily review habit, which is the whole point.

That is a handful of people saying so out loud, not a survey, and I would rather say that plainly than round it up.

My whole AI policy is a demo

I do not hand my team an AI policy and hope. I show them what I built, rough edges included, and let them decide it looks easy enough to try. Nobody gets inspired by a mandate. People get inspired by watching someone they work with do the thing, on their real problems, and come out the other side with an afternoon back.

So I show my team what I build whenever I can. Not as a performance, more as a dare. I joke that if I were still a full-time developer I would have automated my whole process end to end by now, and the joke is doing a job: it tells them the tokens they have are for exactly this, and that making their own work easier is not a side project, it is the work.

A couple of weeks ago I demoed the review board and Crew Watch. In that couple of weeks, three of them built their own. I did not assign any of them.

The best thing a demo can do is make someone else open their own session.

Kercwin's epic checker

Kercwin is the tech lead of my team, and inspired by the review board, he built an epic checker. It reads every ticket and open pull request against the epic's architecture plan in Confluence, and puts each new decision or conflict in front of the person who owns it. The idea under it is our CTO's rule, move bugs as far left as possible, and it has earned a note of its own: Our CTO Said Move Bugs Left. My Tech Lead Built the Tool.

The part I did not see coming: I started sending it commits, and one of them lets my review kit fold the epic check's decided deviations into its verdict. His tool now makes my reviews smarter.

Kyle's Obsidian board

Kyle is a junior on my team, and I see a lot of potential in him.

In my one-on-one with him last week, he showed me a dashboard he had built in Obsidian to run his own work: his tickets, his pull requests, what is waiting on him and what is waiting on someone else. He had built it shortly after my demo. Nobody asked him to, and it is not for me. It is for him.

I found that genuinely cool, and a little inspiring in the other direction. A junior developer saw a manager's dashboard and did not think "nice tool for managers." He thought "I could have one of those for me," picked Obsidian, and made it. That is the exact instinct I was hoping the demo would plant, and seeing it come from a junior made it land harder. It is also the habit that turns a junior into a senior: noticing the friction in your own work and fixing it instead of carrying it.

Cyrus's PR desk

Cyrus is a fresh graduate who joined the team about three months ago. He built My PR Desk so he would stop digging through GitHub to find out where his work stands. One page shows his open pull requests with how many approvals each has and still needs, who reviewed it, whether the checks pass, and which comments and threads are new since he last looked. Below that sits everything merged in the last two weeks, and whether each one has reached UAT yet. A separate tab lists the team's open pull requests, puts the ones waiting on him first, and lets him approve from the row. A small bar shows how much of his Claude plan he has used.

The part I like most is how it runs. A script on his laptop pulls from GitHub every ten minutes and writes a file the dashboard reads, with a refresh button for when he cannot wait. The laptop does the fetching rather than the model, so keeping it current costs no tokens at all.

Three months in, he had noticed the thing that ate his day, checking GitHub over and over, and built his way out of it. He now knows the moment his work reaches UAT, and the reviews he owes are the first thing he sees.

One person's tool made another's better

That is also why I keep sharing and nudging. It is not only so each developer has an easier day, though they do. A developer who loses less time to friction gives that time back to the team, and what one of us learns, the rest of us get to borrow.

Kercwin's checker is the example. I hooked it into my reviewer, so my reviews now know which deviations from an epic were decided on purpose. Before that, the reviewer flagged a deliberate change the same way it flagged a mistake.

Kyle and Cyrus are the other example, and nobody planned that one either. They built their boards together. Kyle picked Obsidian because he did not want his own board tied to Claude and how much of his plan it used. That worry is why Cyrus's desk fetches the way it does: a script on his laptop does the pulling, so the dashboard runs without spending a single token. One junior's constraint became the other junior's design.

One person's tool made another person's tool better, and the whole team gets the sharper review. That is the lesson I would keep from all of this: share what helps you, because it rarely stops at helping only you.

The rule that comes with the tokens

I push hard for AI, because I think it is where the work is going and I would rather my team arrive early than late. But the push always comes with the same rule, and it is the one I give my students.

You own what you ship. If Claude wrote it, you still have to be able to explain it, defend it in a review, and say why it is right. Do not post a comment, open a pull request, or send a chat message you could not have written yourself or do not understand. Make it readable by a human, because a human is going to read it. The tool is allowed to type. It is not allowed to think for you.

The rule holds for me too, which is why letting go of my own reviewer took so long. The review board now runs fully automated, and I no longer check each review before it posts. I trust it fairly well by now, for reasons I can show rather than a feeling, and how I got there is the whole of Seven Hundred Commits to Teach a Reviewer It Was Wrong.

That rule is why I am comfortable cheering them on. Kercwin's checker does not decide anything. It puts the decision in front of the person who owns it. Kyle's board does not do his work. It shows him where it is. Cyrus's desk does not approve anything on its own; the button is his to press. The machine drafts, and someone with their name on it signs.

What I have not earned yet

Two weeks and three tools is a good story, not a trend. I do not know yet whether this sticks, whether the rest of the team builds something, or whether the epic checker still gets opened in three months. Crew Watch replacing People Manager is my judgment after a short run, not a proven fact, and the app is parked rather than deleted in case I am wrong. And a dashboard is only as honest as the data under it, which is why the audit came before the one-on-ones and not after.

What I am sure of is smaller. I built a board so I could stop reading log files. I did not show it to my team only to show off. I wanted them to see what they could build with a nudge in the right direction. They took the hint, built their own, and one of them made my reviews better in the process. If you lead people and you have been sitting on something you built, show them. The worst case is they nod. The best case is they show you theirs.

The judgment is human. The typing, by design, is not.