Commitment‑reliability metrics
A thread argued teams can earn autonomy by tracking how often they meet shipped commitments and flagging risks early, creating data‑driven “contracts” between engineers and managers. The post recommended measuring percentage of shipped commitments and using that signal to reduce oversight as reliability improves, framing this as a direct fix for missed‑deadline cycles (x.com).
A software team can treat deadlines like promises, not guesses, by tracking one number: the share of commitments that actually ship. (dora.dev) Pawel Hajdan, a former Google tech lead who now advises startups, argued in a recent X thread that teams should measure commitment reliability and use it to decide how much oversight they need. His website says he worked on Chrome infrastructure, Google Cloud and later Citadel Securities. (pawelhajdan.com) The basic idea is simple: if a team says it will deliver 10 things in a cycle and ships 8, its commitment reliability is 80 percent. Hajdan’s post paired that score with early risk reporting, so missed dates surface before the end of a sprint or quarter. (growingscrummasters.com) Software groups already use delivery metrics, but most standard dashboards measure speed and stability after code moves. DORA, the Google-backed research program, tracks deployment frequency, change lead time, failed deployment recovery time, change fail rate and deployment rework rate. (dora.dev) That leaves a gap between a manager asking “Will this ship when you said it would?” and an engineering dashboard answering “How fast do we deploy?” Hajdan’s proposal tries to fill that gap with a planning metric tied to shipped work, not just released code. (cloud.google.com) The appeal for managers is control by evidence instead of check-ins by instinct. Google Cloud’s Four Keys guide says teams can baseline delivery metrics, track them over time and use dashboards to validate improvement. (cloud.google.com) The risk is that any single number can be gamed. Agile coaching material that discusses commitment reliability says teams often use historical reliability to plan future work, which can help with capacity decisions but can also encourage smaller or safer commitments if leaders reward the percentage without looking at scope. (growingscrummasters.com) DORA makes a similar distinction in its own framework by separating throughput from instability. A team that ships often but creates rework or incidents is not performing well, and a team that hits every promise by under-committing may not be either. (dora.dev) The thread’s practical message is that autonomy can be earned with a visible record of meeting commitments and escalating risk early. In organizations stuck in a cycle of missed dates and tighter supervision, that turns trust into a number leaders can inspect over time. (cloud.google.com)
