Start with the Outcome, Not the Person

When owners feel overloaded, the first question is often “Who can I hand this to?” That starts too late. Define the result before choosing the resource.

“Handle security” is not a usable outcome. A clearer version might be: “All active users have approved access and MFA; departed-user access is removed within one business day; backups are monitored daily and recovery is tested quarterly; exceptions have a named approver and expiration.”

The clearer version reveals the work, evidence, authority, and resources. It also reveals that one person may not be the complete answer. The outcome may require a manager, automated identity controls, 702it monitoring, documented approval, and a tested recovery process.

Use this sequence:

Define the observable outcome. What condition must exist?
Name one accountable owner. Who ensures it is handled?
Identify performers. Who or what carries out each part?
Verify capability and capacity. Can the work be done now?
Match authority. Can responsible people make the required decisions and obtain access?
Consider behavioral approach. Where will pace, communication, stability, or verification help or strain the outcome?
Supply support and evidence. What process, technology, information, vendor, budget, or redundancy is missing?

DISC enters at step six, not step one. That prevents a style label from becoming a shortcut around operating design.

Across the BOS, outcomes make ownership concrete. Communication is not “keep everyone informed”; it may be “urgent incidents reach the duty owner within five minutes and are acknowledged.” Information is not “document things”; it may be “an authorized replacement can retrieve and use the current recovery procedure without coaching.”

Try this: Rewrite one vague responsibility using: “When this is working, we can observe…” Then ask what resources become visible.

Related terms: Outcome · Accountable owner · Definition of done · Resource placement · Evidence