Always be quitting

A good philosophy to live by at work is to “always be quitting”. No, don’t be constantly thinking of leaving your job 😱. But act as if you might leave on short notice 😎. Counterintuitively, this will make you a better engineer and open up growth opportunities. A thread 👇.

So what does it mean to always be quitting? It means “making yourself replaceable”; “deprecating yourself”; “automating yourself out of your job”. You might have heard these more-popular names (which you’ll need to do your own research) and they hint at how to act.

The key lies in NOT being indispensable. If you are, you’ll be stuck at your specific job for as long as that job is relevant with little chance to disconnect (no vacations, no growth). And when (not if) the job becomes unnecessary, so will your position.

Paradoxically, by being disposable, you free yourself. You make it easier for yourself to grow into a higher-level role and you make it easier for yourself to change the projects you work on. Confused still? Here are 10 specific things you can do:

1. 📕 Document your knowledge. Every time someone asks you a question, they are highlighting a gap in the documentation. Take the chance to write the answer down (in a document, bug, code comment—wherever) so that the next person doesn’t need YOU.

2. 🏁 Document your long-term plans. People should know what’s coming up in your projects and/or team by looking at those plans, not by relying on you to tell them “in real time”. Plan a few months ahead so, if you leave, your peers won’t be lost from day one.

3. 🤝 Document your meetings. Keep (public, within the team) notes for all meetings you attend, listing who was there, what was discussed, and any conclusions. Reference those notes from design documents. Your replacement will need these to catch up.

4. 🚶‍♂️ Bring others to meetings. If not a 1-on-1 and you are the only person from your team attending a meeting, involve someone else. Different perspectives are useful, but more importantly, you are avoiding becoming the only point of contact.

5. 👩‍🔧 Train people around you. The goal is for them to be independent (what is usually considered “seniority” in a typical engineering ladder). Familiarize them with the plans and technologies and make sure they know how to use the documentation.

6. 👩‍🎓 Identify and train your replacement. In the same vein as training others, to switch roles you’ll need to replace yourself. Identify who that replacement might be and actively and continuously coach them.

7. 🔑 Give power to the people. Trust them to do the right thing. If you are in a leadership position, don’t make it so people come to you asking for permission. Let them make their own choices. Guide them so that their choices are based on the right data.

8. 📧 Do not make yourself the point of contact. Establish mailing lists or other forms of communication that can accommodate other people, and then grow those groups. (The exception is when management needs names for accountability.)

9. 👨‍💼 Delegate. Once you have given power to others, included them in groups and meetings, and documented your knowledge, they’ll be ready to take work from you. Delegate work that can make them grow and focus on the things only you can do.

10. 🏫 Always be learning. Take the chance to grow your knowledge in any area you are interested in, and keep it fun. Bonus points if that area aligns with the future path you want to take.

Note that nothing here implies abdicating responsibility. You still have to be responsible for all the projects and teams you own, and you have to be for as long as you are in your role. This is important because this responsibility is what will open up new gates.

Lastly note that, by doing all of the above, you are actively making your whole team better, not just yourself, even if you are an IC. In fact, you are practicing a subset of the skills sometimes associated with staff/principal+ engineers.

Update (2021-07-12): Article also available in Chinese thanks to 涛叔 (Taoshu).