Software factory metrics

Measure the system in dimensions

Start with a decision rather than a dashboard. A factory team may want to know why work is taking longer, whether an automation change reduced friction, or whether faster delivery increased rework. Each question needs a different slice of evidence.

Useful dimensions include:

• Throughput: completed changes, deployment frequency, and change lead time.
• Flow: cycle time, waiting time, queue age, work in progress, and handoffs.
• Quality and stability: review findings, rework, change failures, and recovery time.
• Work mix: features, maintenance, incidents, defects, and enablement work.
• Developer experience: friction, feedback speed, and the ability to make progress.
• Outcomes: customer behavior, reliability, revenue, or another result the work is meant to change.

These dimensions answer different questions. A higher change count may coexist with more defects. A lower cycle time may reflect smaller work or a change in intake. A positive developer survey does not prove that releases became more dependable.

Make the definitions inspectable

Document the event that starts and ends each measure, the population included, the time window, and the source system. Keep repositories, services, and work types comparable. Show distributions and representative examples when an average hides a long tail.

How Weave fits

Weave can bring code output, pull request timelines, review patterns, and quality signals into the same investigation. That makes it possible to move from a factory trend to the changes and queues behind it. Use those signals to form a hypothesis and test an improvement. Add delivery, incident, product, cost, and developer feedback data when the decision depends on those parts of the factory.