Measure impact, not hours

The argument in the social post is simple. Stop treating hours as proof of value. Start asking what changed for the product, the customer, and the business. In software, that sounds obvious. It is not how many teams are still managed. Hours are easy to count. So are commits, tickets closed, and lines of code. That is exactly the problem. The easier a number is to count, the easier it is to optimize for the number instead of the work. The SPACE framework, developed by researchers from GitHub, Microsoft Research, and the University of Victoria, was built around this point. Developer productivity, they wrote, cannot be captured by a single metric or dimension. It includes satisfaction and well-being, performance, activity, communication, and efficiency. A dashboard full of activity data is not the same thing as useful output. (queue.acm.org) That sounds academic until you look at what happens inside companies. Once a measure becomes a target, people learn to game it. That is Goodhart’s law, and software teams run into it constantly. If leaders reward visible effort, people produce visible effort. More messages. More status updates. More reopened tickets sliced into smaller tickets. More time online. None of that guarantees a better product. Google Cloud’s DORA research now warns against this directly. Its recent work stresses user-centricity, stable priorities, and continuous improvement over chasing isolated performance targets. (research.google) The deeper shift here is from labor accounting to systems thinking. DORA’s four key metrics became popular because they track software delivery performance in ways that connect to real operational outcomes: deployment frequency, lead time for changes, change failure rate, and time to restore service. Those are still proxies. But they are closer to customer impact than time spent at a keyboard. DORA’s long-running research has tied strong software delivery performance to stronger organizational performance, and its 2024 report drew on responses from more than 39,000 professionals. The point is not that every team should worship four metrics. The point is that engineering work should be judged by whether it helps the organization ship reliable improvements, not whether people looked busy while doing it. (cloud.google.com) That is why the post calls this a culture lever. Metrics do not just describe a team. They teach the team what matters. If leaders obsess over hours, engineers learn that presence beats judgment. If leaders obsess over output counts, engineers learn that quantity beats quality. Research from Google on developer productivity points in a different direction. Factors linked to higher perceived productivity include code quality, manageable tech debt, good infrastructure and tooling, clear goals, strong communication, and sane organizational processes. Those are conditions that let people produce impact. They are not signs of heroic overwork. (research.google) This matters even more now because AI is making activity cheaper. A team can generate more code, more pull requests, and more apparent momentum than before. DORA’s 2025 report on AI-assisted software development says AI acts as an amplifier. It magnifies the strengths of healthy organizations and the dysfunctions of weak ones. If a company already confuses motion with progress, AI gives it faster motion and worse confusion. If a company already measures outcomes, AI can help it reach them sooner. The metric choice comes first. The tooling only makes the choice more visible. (research.google) There is also a human reason to stop equating long hours with contribution. Research on developer experience has found that older approaches focused on output or task time miss the reality of the job. Software work is full of interruptions, debugging, coordination, waiting, and rework. Separate research from Google found that code quality, infrastructure support, and clear priorities matter more than performative busyness. Microsoft-affiliated researchers studying developers’ real and ideal workweeks found a gap between how engineers actually spend time and how they want to spend it. Teams do not need more pressure to look active. They need fewer obstacles between effort and effect. (queue.acm.org)