How to know if your dev team is working well

Every few months someone asks a version of this on r/startups: how do you know if your dev team is working well? The replies split into two camps. Track velocity and commit counts, says one. You can’t measure engineering, trust your CTO, says the other.

Neither is much use to a founder who signs the payroll and can’t read a diff.

The question under the question

You’re really asking two things: whether the team is working on the right stuff, and whether what they ship stays shipped. Work aimed at the wrong target and work that gets redone twice both look like productivity from the outside. That’s why “are they busy” is a dead end. You already know they’re busy.

Counting doesn’t answer it

Commits, pull requests and story points are the numbers a non-technical founder can get without help, so those are the ones founders reach for. The SPACE framework, written by researchers from Microsoft and GitHub, makes the case that no single number captures engineering productivity. You need satisfaction, performance, activity, collaboration and flow read together, or the number misleads you.

Counting also changes what’s counted. A team that knows PRs are being watched will open more of them, smaller. Nobody decides to game anything; it just happens once there’s a scoreboard.

Standups and demos fail differently. Standups exist to unblock the people doing the work, so they surface today’s task and today’s obstacle, never what a month adds up to. Demos show whatever demos well. The three weeks spent stopping signups from silently failing has no demo.

Output got cheap, so it says less

If you last thought about this before 2023, the ground has moved. Writing code is fast now, and what comes out isn’t uniformly good. Stack Overflow’s 2025 developer survey found the top frustration with AI tools is “solutions that are almost right, but not quite,” at 66% of developers. GitClear’s analysis of 211 million changed lines found refactored code dropped from 24.8% of changes in 2021 to 9.5% in 2024, while duplicated blocks climbed sharply.

So a big week of output tells you less than it did three years ago. Google’s 2025 DORA report puts it neatly: “AI doesn’t fix a team; it amplifies what’s already there.” A team with problems now has them faster.

Four things you can check yourself

Did the thing they said would ship, ship?

Write down at the start of the month what the team says will be done by the end of it. Compare when you get there. You’re not looking for 100%, you’re looking for a ratio that holds. Four promised and three delivered, month after month, is something you can run a business on. Four promised, one delivered, then six promised next month, is a scoping problem, and scoping problems usually sit on top of an architecture problem.

What came back?

Ask once a month: what did we ship last month that we’ve already had to touch again? Bugs, rollbacks, hotfixes, complaints. Some rework is normal and healthy. The thing to watch is the pattern: the same area returning every month, or a growing share of the week going to work that was supposed to be finished.

Can they explain it twice?

Ask an engineer what they built. Then ask what it changed for a customer and how you’d know if it worked. Good teams answer both without effort. If the second answer never arrives and everything loops back to what was technically hard, you may have a team building well and pointed at nothing in particular. That one is yours to fix, not theirs.

When does bad news reach you?

Every team has bad news: an estimate slipping, a dependency rotting, a decision from last year that’s turned expensive. The only question is whether you hear it as a warning or as an incident. If your last three surprises all landed on the deadline, the problem isn’t reporting discipline, it’s that nobody felt safe saying it early. No dashboard will show you that.

Doing it monthly

Twenty minutes in a doc: what they said would ship, what actually shipped in plain English, what came back, and what surprised you. Three months of that beats any dashboard, because it tracks alignment and durability instead of volume.

The awkward line is the second one. Working out what actually shipped, in words you can use, means someone has to read the merged work and translate it. Usually your most expensive engineer, on a Friday, until they quietly stop doing it. That’s the part DevSummary takes over: it reads your GitHub activity and writes the plain-English version on a schedule.

If the answers come back bad, don’t start by installing metrics. Say plainly what next month has to produce and why it matters commercially, then ask the team what would stop it. Most teams that look like they’re failing are working hard on the wrong things, waiting for someone to tell them so.