{
  "author": {
    "name": "Dylan Fitzgerald",
    "url": "https://dylanfitzgerald.net/"
  },
  "blyg": "0.4",
  "changelog": [
    {
      "at": "2022-07-28T04:07:00Z",
      "note": "Imported from the Ctrl+Shift archive",
      "version": 1
    }
  ],
  "content_hash": "sha256:816d63f27a9eae61a7c8c41c36d672959024303b5ecc189ec318b6042c36f3bb",
  "content_html": "\u003ch1\u003eTransfer and accept responsibility—responsibly\u003c/h1\u003e\n\u003cp\u003eWith 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.\u003c/p\u003e\n\u003cp\u003eHow do you know when you\u0026rsquo;re ready?\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;I don\u0026rsquo;t know what else to do\u0026rdquo; is a \u003cspan class=\"underline\"\u003eterrible\u003c/span\u003e answer. So is \u0026ldquo;it gets it out of my hands\u0026rdquo;; ditto \u0026ldquo;they have more information about it\u0026rdquo;. You want the answer here to be \u0026ldquo;the work is in the correct state to transfer responsibility to the next party\u0026rdquo;.\u003c/p\u003e\n\u003cp\u003eIt 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\u0026rsquo;s Not Mine Anymore.\u003c/p\u003e\n\u003cp\u003eFor example, before a software engineering team accepts a ticket as ready to have resources committed to it, they can require the three D\u0026rsquo;s of well-defined work:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDefinition: what \u0026ldquo;done\u0026rdquo; 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 \u003cspan class=\"underline\"\u003enext\u003c/span\u003e party, if applicable.)\u003c/li\u003e\n\u003cli\u003eDeadline, if any, and\u003c/li\u003e\n\u003cli\u003eDependencies this work has, or upon this work, to aid in sequencing.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTickets lacking these criteria\u0026ndash;or whatever you determine is crucial\u0026ndash;can be safely pushed back upon without affecting any existing commitments.\u003c/p\u003e\n\u003cp\u003eWhere 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\u0026rsquo;t have their time and attention captured by work flailing?\u003c/p\u003e\n",
  "content_md": "# Transfer and accept responsibility—responsibly\n\nWith 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.\n\nHow do you know when you're ready?\n\n\"I don't know what else to do\" is a \u003cspan class=\"underline\"\u003eterrible\u003c/span\u003e 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\".\n\nIt 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.\n\nFor 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:\n\n-   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 \u003cspan class=\"underline\"\u003enext\u003c/span\u003e party, if applicable.)\n-   Deadline, if any, and\n-   Dependencies this work has, or upon this work, to aid in sequencing.\n\nTickets lacking these criteria--or whatever you determine is crucial--can be safely pushed back upon without affecting any existing commitments.\n\nWhere 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?",
  "created": "2022-07-28T04:07:00Z",
  "id": "7533t61n5dzxsdra2fe7g4rb1t",
  "kind": "thread",
  "media": [],
  "origin": "https://dylanfitzgerald.net/blyg/",
  "page": "https://dylanfitzgerald.net/blog/transfer-and-accept-responsibility-responsibly/",
  "transclusions": [],
  "updated": "2022-07-28T04:07:00Z",
  "version": 1
}