It’s Julie’s last day at work. She’s already turned in her laptop to IT, sent her goodbye email to the team, and is wrapping up her last knowledge transfer meeting. Tonight, there’s a goodbye drinks with the whole engineering department at that bar everyone loves across the street from the office. You’ve followed all the processes as a manager to offboard this person correctly, and wished them good luck at their shiny new job with more stock options and a higher salary you just couldn’t match. “Good for her,” you think, as the night winds down over a final round of cocktails. But wait – you’re not done yet.
When you’re a manager, the way you treat the people that were on your team matters almost as much as how you treat the people that are. Your ex-employees are the people out there talking the most about your company and your team. They’re the people that get DMed when a new recruit is trying to find out what it was really like to work for your company and for you. And handled really well, ex-employees are often great folks for you to tap in a few years for the new team or company you’re working on, when they’re ready for a new challenge.
How should you treat the people you used to work with, so you won’t leave a bad taste in their mouth? Here are a few do’s and don’ts I’ve picked up from my own ex-managers over the last decade or so. Disclaimer: this advice won’t apply to every situation, including if an employee left or was pushed out on bad terms.
What to Do
Let them leave with dignity.A CTO I really respect taught me that letting people take the time they need to say their goodbyes and tie up loose ends, without rushing them out the door, pays dividends. He gave me the great advice to spend my last day on the job having coffee with everyone that had an impact on me, thanking them, and exchanging contact info.
Remember that it can be emotional to process endings, even if it was their choice, and last days can be full of paperwork and tears. It’s okay if they need to come back the next week and pick up a few more things, or need building access for a final meeting after their technical last day. Don’t be a jerk or make mean-spirited jokes about how much they must want to stay. Not cool. You want their last memory of this place to be a positive one: handshakes, hugs, and well-wishes.
Keep in touch (if they want to). Some of your reports or teammates probably view you as one of their mentors, and it can be hard to abruptly lose that guidance when they switch jobs. In your last 1:1, ask the person departing if they want to stay in touch after they get settled in their new role. If they do, set up a recurring reminder to check in with them every few months or a few times a year on their career over coffee or lunch. If they blow you off or don’t seem interested, take the hint.
Let them hang around. It’s natural for folks to miss some of their coworkers, the office, and aspects of the culture when they quit. So if you see them coming by for lunch or after work to hang out with some pals, say hello and be cordial. Obviously, also be aware of the security / guest policies of your company and make sure those are being followed. The benefits of knowledge-sharing (of things they’ve learned in their new role) with your team far outweighs the risk that they’re going to “steal all your people” or whatever other irrational fear your lizard brain has cooked up. Chill out; it’s nice to see their face again.
Take their feedback seriously. They likely understand and care about your product a lot. So it might not be long before you see a tweet or email from an ex-employee about the thing they used to work on. They might be reporting a bug or airing a grievance. While it might not be the most polite way for them to give this feedback, it’s still useful. This person is essentially doing free QA on a system they’re very knowledgeable about. If you see something like this, shoot them a message asking for more details and thanking them for the report. Stay classy and fix the issue if you can! You’ll make them feel heard and respected while helping them and lots of other users too. Win-win.
What Not to Do
Don’t blame them. A few weeks after an engineer leaves a team, there will be a bug that someone will blame on them—their code, their oversight, their fault. Resist this temptation. Your team has code review, unit tests, and architecture meetings to prevent this type of singling out of developers. Remind them that every issue is a shared responsibility, and focus on fixing the problem instead of dredging up historical evidence of whose fault it was. Don’t let folks blindly rewrite systems just because “only Jim understood how this worked.” Work to build a shared knowledge base and set of documentation so that no one person is completely indispensable.
Don’t make them work for free. There’s often a temptation to message ex-employees with “quick questions” about esoteric code or systems that they worked on after they leave the company. Please don’t do this. If you absolutely need these answers, hire this person at their consulting rate and pay them for their time and labor. This kind of arrangement is super common, and your company should hopefully already have a boilerplate agreement for this scenario. If not, now’s the time to draft one.
Don’t erase them from history. This isn’t Eternal Sunshine of the Spotless GitHub. It’s unprofessional and petty to remove folks as contributors to your open source projects (especially if they want to contribute in their spare time) or scrub their bylines from your engineering blog. I’ve even heard of bosses ignoring their former employees at conferences and industry events or blocking them on social media. This is a really bad look. Don’t be a jerk to people who worked for you.
Don’t ask them on a date. I wish this went without saying, but it doesn’t, because I’ve heard of this happening. If you had a crush on your employee and the only reason you weren’t asking them on a date is because of the HR policies in place to prevent that, now is not the time to flirt with them. The power imbalance that existed between you doesn’t magically disappear because they work somewhere else. This is a really bad idea, and you should do some soul-searching and work on your boundaries if this is your first impulse.
Many managers think a lot about how they treat their team, but very few I’ve spoken to have a philosophy about those who leave it. Treat your ex-employees like they’re professionals that helped you build and ship great things, because that’s exactly who they are. If you’re consistently nice and professional to the folks you’ve worked with in the past, it’ll help build your reputation as the kind of person that’s great to work for.
In September 2016, I was honored to be invited to speak at Joe and Charles’s incredible Release Notes conference in Indianapolis. Release Notes, an outgrowth of their podcast of the same name, approaches the software business as a business first and foremost. Their guiding principle is to discuss “everything but the code”.
Here’s the audio and slides from my talk. It’s called Write Your Way Out (yes, it’s a Hamilton reference). I spoke about writing and the importance of writing well as a software engineer, a product manager, and especially the owner of a software company. Watch it below and let me know what you think on Twitter.
The dates for Release 2019 in sunny Playa Mujeres, Mexico have just been announced (Oct 3—5). If you’re in the software business, I can’t recommend it more strongly. Get on the mailing list so you don’t miss tickets!
If I could show just one talk to every software engineer, it wouldn’t be a treatise on the elegance of algorithms, a lecture about accessibility in apps, or even the masterwork that is Englebart’s Mother of All Demos. Instead, I’d show them this frequently-referenced 1991 speech that John Cleese gave (transcript) to Video Arts, a company he co-founded. In it, he presents a blueprint for how to nurture creativity at work that’s based on his own experience in Monty Python and the work of experts like Donald MacKinnon, Johan Huizinga, and Edward de Bono. The talk’s thesis is that “creativity is not a talent; it is a way of operating”. His method for creativity involves regularly setting aside time and space to be in the open mode, when most of our lives and occupations push us into the closed mode.
Let me explain a little. By the “closed mode” I mean the mode that we are in most of the time when we are at work. We have inside us a feeling that there’s lots to be done and we have to get on with it if we’re going to get through it all.
It’s an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable. It’s a mode which we’re probably a little impatient, if only with ourselves. It has a little tension in it, not much humor. It’s a mode in which we’re very purposeful, and it’s a mode in which we can get very stressed and even a bit manic, but not creative.
If you’ve worked on a team making software, you’ve almost certainly heard the thought-terminating cliché, “That’s impossible” hastily uttered by a programmer. I know I’ve said it; I suspect we all have. Sometimes engineers blurt this out because a product manager is asking them to do something unsupported by system APIs; sometimes they really mean “It’s hard” or “It’s not worth it” or even just “I don’t want to.” And then other times they are afraid to admit that they just don’t know how to do what’s being asked of them, even if they have a nagging suspicion that it can be done.
Software engineers reject entire product ideas, categories of problems, and persistent bugs as completely impossible to tackle. What is it about the psychology of programmers that leads to this limitation of imagination? In Cleese’s model, it would seem that programmers are spending so much time in the “closed mode” that they get stuck there. So, what’s the alternative?
By contrast, the open mode, is a relaxed, expansive, less purposeful mode in which we’re probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful.
It’s a mood in which curiosity for its own sake can operate because we’re not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface.*
Programmers are problem-solvers, spending most of their day building, a task that demands they be in the closed mode, “wired in”. Implementing features to spec, tracking down and fixing bugs, and thinking like a computer are exercises in putting one’s head down and blocking out distractions, and are therefore incompatible with the open mode. When we train ourselves to see the world this precisely, dividing things into neat boxes and clear abstractions, it can hurt our ability to accept ideas outside our mental model. It’s why many programmers I’ve worked with have stories about tracking an inscrutable bug down to an unhandled condition in their code with a comment that reads // This should never happen. And it’s for just the same reason that many brilliant engineers dismissed ideas like the internet, real time direction-routing, and digital currency as impossible for decades before they were implemented. For a coder, there’s inherent anxiety in impossibiilty, anxiety that can push them toward surrender rather than creative problem-solving.
But during the earlier design and ideation stages of projects, before we start writing code, we need to remind ourselves and our teammates to remain open. Nothing’s decided, nothing’s set in stone, and therefore many things are possible that might not seem that way at first. The Waterfall model of development forces this openness to end when building begins, but newer software methodologies like agile development promote the idea that we should expect design iteration to continue during software construction and therefore allow for open mode thinking throughout a project.
Cleese also suggests ways to avoid choking off our creativity too early. He recommends collaborators establish as free an atmosphere as possible in the open mode. Improvisational comedians have a well-known shorthand for this kind of openness to whatever ideas are presented: “Yes, and”.
And never say anything to squash them either, never say “no” or “wrong” or “I don’t like that.” Always be positive, and build on what is being said:
“Would it be even better if…”
“I don’t quite understand that, can you just explain it again?”
Even if an idea that a coworker proposes is truly impossible, it can still have value. In Edward de Bono’s book Practical Thinking, he writes about the value of intermediate impossibles. Sometimes unrealistic ideas are just a step on the path toward something that will work brilliantly. For example, you might design an impossible sign-up screen that magically knows the user’s name and email, and then realize later in a brainstorm that you don’t need either piece of information at all and still end up with a great user experience. De Bono calls this lateral thinking. As opposed to logical thinking, which requires a linear progression of true statements (just like most computer programs), lateral thinking allows and even encourages impossible ideas as middle steps, as they often help us get to a better end result.
The use of an Intermediate Impossible is completely contrary to ordinary logical thinking in which you have to be right at each stage.
It doesn’t matter if the Intermediate Impossible is right or absurd, it can nevertheless be used as a stepping stone to another idea that is right.
As software makers, we could all stand to be more open to the impossible, especially given that the technology we create must help solve wicked problems outside our screens, like climate change, transportation, and healthcare, problems that will require immense creativity and teamwork. To overcome what seem like impossible tasks, we first need to believe that there might be a way to do so.
The next time you’re playing around with new ideas and someone tells you that they’re impossible, remind them of what John Cleese said, ”When you’re playing, nothing is wrong.”