Define the outcome and the service boundary
An IT team can appear busy while customers wait for useful results. Begin by defining the service or product, the people it serves and the outcome that needs improvement. A support team might need more reliable restoration; a software team might need safer delivery of valuable changes. Those contexts require different evidence.
Describe the boundary and dependencies before comparing performance. A team waiting for external approval should not be told that working faster inside its own boundary will remove the queue. Map a representative item from request to outcome and record waiting, handoffs, rework and unclear decisions. This identifies where an improvement experiment could matter.
Use metrics to understand the system
DORA’s current delivery-performance guidance groups measures around throughput and instability. Use the current definitions for software delivery rather than repeating an old “four metrics” poster as a complete contemporary framework. Apply measures to a relevant service context and retain the definitions and data source.
Pair speed with quality and reliability. A team that deploys more often while generating more recovery work may not be improving the intended outcome. For support, compare restoration and recurrence alongside user impact. Avoid measuring individual value by commits, ticket counts or hours online; such counts can encourage fragmentation and discourage collaboration.
Make priorities and ownership explicit
Create a short shared view of goals, current work, blocked items and responsible decision makers. Limit concurrent work when excessive switching prevents completion. Establish how urgent requests displace planned work and who approves that tradeoff, instead of letting every stakeholder silently assign a different priority.
For an illustrative internal-platform team, distinguish user requests from incidents and improvement work. Identify an owner for each recurring dependency. Review where a second person can learn a critical task so the service does not rely on one expert’s constant availability. A clear operating agreement reduces avoidable uncertainty without requiring another layer of status meetings.
Build conditions for honest feedback
Google’s team-effectiveness research highlights psychological safety as a relevant team condition. In practice, leaders can invite concerns, acknowledge uncertainty and respond constructively when someone identifies a mistake. This supports learning while retaining clear expectations for reliable work and respectful conduct.
Run a short review of one delayed item. Ask what information was missing, where the process made the right action difficult and what the team can test next. Avoid turning an incident review into a search for a person to blame. Record the agreed action and follow through; repeated feedback sessions without change can reduce trust.
Run one bounded improvement experiment
Choose a specific hypothesis, such as reducing approval waiting time through a clearer decision rule. Define a baseline, small change, owner, review date and balancing measure. Keep the experiment narrow enough that the result can be interpreted. Multiple simultaneous changes make it difficult to know what helped.
At review, compare outcomes and unintended effects. Retain, revise or stop the change based on evidence and team feedback. Support learning with protected time, pairing and targeted training where a demonstrated skill gap exists. Certification can be useful for a relevant capability, but it should not become a universal remedy for unclear priorities, poor tooling or an overloaded system.
Official references
Certification requirements and programme terms can change. Use the issuer’s current page and your account to confirm details before applying or paying.