Communicating During a Deliberate Shutdown

what to say and how

• Clinicians systematically fail patients by focusing on what medicine can do rather than asking what the patient actually wants [Gawande2014]
• Project closure conversations often fail in the same way
• Discussions with team members, funders, institutional sponsors, and users should:
  • Establish a shared understanding of the situation
  • Make each party's values and priorities explicit
  • Negotiate a plan that meets those goals rather than being what is technically easiest
• Focus on:
  • The least bad outcome for each stakeholder
  • What trade-offs they are willing to make

Honest Enough

• Framing matters
  • "Putting into hibernation" provokes less hostility than "termination" and keeps the door open for revival
  • If it is the truth and credible
  • It's possible to be one without the other
• "Tell people what you know, as soon as you know it" is easy to say but hard to do
  • Information gaps cause more anxiety than difficult truths
  • Conflicting verbal and written instructions cause lasting harm
  • On the other hand, you often don't know what's happening
  • And constantly-changing pronouncements raise the temperature as well
• [Wruck1990] found that indirect costs of financial distress (lost contributors, cancelled collaborations, management distraction) are substantially larger than direct costs such as legal fees or asset sales
  • Indirect costs arise because distress signals inability to fulfil commitments, triggering defensive behaviour that accelerates decline
  • An information vacuum does more damage than an honest announcement would have

Mechanics

• Don't start by announcing shutdown
  • Announce that you are stopping work and invite known successors to take over
  • Do not accept successors you don't already know (supply chain attack risk)
• Give users real deadlines and enough time to act
  • Two to six months between announcement and shutdown is enough
• Use the project's announcement channels and others, not just the repository README or project home page
  • The latter reach core project members, not the wider circle
• Tell people reasons (as much as you can), timelines, and what will happen to assets
• Update the project home page to list:
  • Key achievements
  • Current state (working, broken, incomplete)
  • Where code, data, and results are (going to be) archived
  • Next steps or alternatives for users
• Don't bother with:
  • User-facing tutorials
  • Exhaustive dependency documentation
  • Adding additional tests as if you were doing a new release
  • Bug triage
• If possible, have someone outside the project run structured exit interviews to find out what should survive rather than what went wrong
• Hold a wake for the project (i.e., a combination group retrospective and memorial)
  • What went well, what didn't, and what stories people will remember

How Leaders Leave

• [Sonnenfeld1988] studied what happens when leaders leave the organisations they built and identified four departure archetypes
  • Which one applies to you is shaped by how central the project is to your identity
  • Recognizing the pattern in advance shapes the handover conversations
• Monarchs refuse to leave until forced out and undermine successors
• Generals depart reluctantly, maintain close ties, and often attempt to return
• Ambassadors leave willingly, remain available to successors, and are the most satisfied post-exit
• Governors leave cleanly for new pursuits and disengage entirely