Skip to content

Instantly share code, notes, and snippets.

@zmagg
Last active May 5, 2016 08:30
Show Gist options
  • Save zmagg/5635beafbff15a6b667742e27ae96798 to your computer and use it in GitHub Desktop.
Save zmagg/5635beafbff15a6b667742e27ae96798 to your computer and use it in GitHub Desktop.
strategies i've used to leave projects without quitting

I consider myself reasonably OK at leaving projects without quitting, at Etsy. That's an important qualifier, as Etsy as an organization is very comfortable with diving deep to understand code and systems and co-debugging and generally what Julia would call, "becoming wizards together". Because of that, I've not found a lot of organizational pressure to stay on a project as the solo expert when you're ready to leave.

Some strategies I've used that have worked to wrap up work on a project and move onto a new one.

  • Go on a vacation. One week is frequently sufficient. Create the bus factor for yourself. Observe the things you do leading up to being gone for a week: probably you're meeting with coworkers to sync knowledge, or writing more documentation, or possibly even presenting exceptionally gnarly part of the system that you worked on. You can preemptively do these things even if you don't go on vacation, but I find being entirely disconnected an important part of demonstrating your trust in other people to be the experts on the systems you used to work on (I say used to! because you're gonna stop, right, right??) I think this demonstration of trust is exactly what Julia is talking about in: "to make someone an expert, ask them questions". You're demonstrating trust both to the person and to the organization, by taking that time off. Also like, YO! You're taking a week (or more!) off in between projects! How good is that for your very own brain!!
  • Something I've seen other people do, that I'd like to do in the future, is asking $other_person explicitly if they're cool with taking questions for $system_you_used_to_work_on. That opens up space for them to acknowledge this work as real, to reflect on themselves as the new expert, and even ask clarifying questions of you preemptively.
  • We use IRC channels as a heavy part of asking&answering questions at work. This sort of maps to Slack channels, but not entirely. A strategy (h/t Rafe) I've used is simply waiting to answer a question, allowing someone else to potentially pick it up. When this doesn't feel good, I check in with the person who asked the question at the end of the day to make sure that they found an answer to it.
  • I've found that a lot of the difficulty in moving off a project and onto a new one is actually inside yourself and not on other people. It feels good to be an expert. You're presumably moving onto a new project where you won't be the expert, at least not at first, and new things are much harder than simply sitting back and being the expert. Convincing yourself that you actually want to move on, or that you actually want other people to help share the load, is step 0. Are you enjoying being the only one who can fix something? The save the day hero? Working in a defined area that you understand well?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment