Transfer and accept responsibility—responsibly
With every project, sometimes more than once, a time will come to hand off responsibility for moving things forward, be it to another individual or another team.
How do you know when you’re ready?
“I don’t know what else to do” is a terrible answer. So is “it gets it out of my hands”; ditto “they have more information about it”. You want the answer here to be “the work is in the correct state to transfer responsibility to the next party”.
It helps to make the criteria for transferring responsibility and/or ownership as explicit as possible. This empowers people receiving inbound work to set firm boundaries against ill-defined tasks, and also empowers folks to say Yes, This Is Ready, And It’s Not Mine Anymore.
For example, before a software engineering team accepts a ticket as ready to have resources committed to it, they can require the three D’s of well-defined work:
- Definition: what “done” means, in sufficient detail that stakeholders are unlikely to succeed in pushing for scope growth later. (This also defines when the work gets handed off to the next party, if applicable.)
- Deadline, if any, and
- Dependencies this work has, or upon this work, to aid in sequencing.
Tickets lacking these criteria–or whatever you determine is crucial–can be safely pushed back upon without affecting any existing commitments.
Where are you seeing mushy definitions of work responsibility, and ill-defined work requests? Can you help delineate who should be focused on those tasks, so others don’t have their time and attention captured by work flailing?
