Leaving a job – reflections & timelines

I gave my notice, we agreed on 3 months, and we set to work.

The first month was about setting things in motion, and creating the right environment for a transition. We made an offer to someone on the team to take over my role as CTO, answered all questions that came up, and worked together as an executive team to make sure the next CTO was confident about taking over.

The second month was about letting my team know, and working to ensure that all the basics were covered. We talked a lot about their careers and our time working together, polished brag docs, and ensured everyone had a written performance review and “next year goals” that could be consumed by the new CTO and used fairly. We also discussed how the goals they had could change as they transitioned to a new CTO, and how to keep pushing for the things they care about. I knew there were things people in my team had wanted to do that they never got a chance to really focus on, and maybe this was a new chance for them to figure it out. We also talked about management; how I go about it, the things they don’t notice, the things they do notice. I talked a fair bit about the things I wished I had done better, too.

The third month was where I started to realize the timeline we set-up for me to leave had been perfect to ensure our goal of a peaceful transition. I was hesitant at first, because I dislike long periods where people are feeling uncertain, but it turned out to be a good idea. Having a 3 month transition period enabled me to leave the organization with confidence that I had done all I could, and that the new CTO was more than ready to pick up where I left. It also gave him time to reflect on what he was going to change and how, and which areas are important to him and which aren’t. It gave them all time to prepare as a new team, let off steam, and let themselves imagine how things could be better. I knew change was coming, and I told folks to expect things to change too. Even when the changes are good, (and I believe many of the things that are likely to change fast were good), it’s important to emphasize that this is to be expected, and to give people space to find joy and pride in the changes, and to allow themselves to be part of the change.

It can be hard as a leader to let go, and I did what I could to make it safe and good to align with the new boss, QUICKLY, without guilt or fear or weirdness.

When I took on the role, I spent a lot of time thinking about the things I wanted to achieve, and understanding what the cut-off would be where I’d feel I could leave without guilt.

By the time I was leaving, I was able to tick most of the boxes, even if (of course) I didn’t achieve or did great in many areas I hoped I would.

It’s Wednesday. My last day was last Friday. It still feels weird. I woke up in panic yesterday thinking I had missed my first 1:1 of the day.

Regardless of how weird and new it is to be out of an organization I loved working for, I’m confident I made the right call, and that I did a lot of the things I had wanted to make progress on: shifting the organization’s management style somewhat, making more decisions based on direct user feedback, making support a central piece, giving people more power to enact change, and giving my team a chance to own their areas entirely.

I wanted to add a small checklist of the things I did as I prepared to leave, in case it helps others who are planning a similar transition in a small team.

Comms & finding a replacement

  • Work with your boss on an appropriate notice period: set expectations on how/why this may change. For us, the basics were that if we couldn’t hire from inside the org, our timeline would probably need to change.
  • Agree on communications: decide right away how and when you will communicate your departure to your team. This may change, but it’s good to set a plan right away. In my case I:
    • notified exec team
    • meet with exec team to decide on next steps / how we would replace me
    • asked the (potential, at that point) new CTO about taking over
    • did a context & learning session with exec team + new CTO, then 1:1s and time for him to reflect and accept/reject the offer (he accepted, thankfully)
  • Once that was done, we notified the team. I told everyone who reported directly to me in our 1:1s, and the rest of the team via DMs. This worked out well. I also offered and did some extra 1:1s with folks who didn’t report to me but had things to discuss and wanted to chat. This was good because by the time people found out it was already clear there was a transition plan in place and there was no uncertainty on who would be the next CTO.

Working with direct reports on next steps

  • Ensured everyone had their brag docs up to date
  • Worked with everyone who directly reported to me on perf reviews (it was right at formal review season so this fit the timeline, but I would have done “final” reviews regardless since it helps the new leader know where people stand, and it helps lower the anxiety of the change)
  • Ensured we reviewed all salaries (it was, after all, salary review season too) and adjusted accordingly. This was important because I didn’t want to leave before ensuring we had confirmed salary adjustments. Salary is complicated, and it takes some context to understand how to deal with this, so I didn’t want a new leader to have to do it right away.
  • Everyone had goals for 2021 and things they wished they had done more/less of, and we set those up too in the transition documentation I sent to the new CTO.
  • Encouraged folks to go straight to the new CTO and ask about plans, goals, and changes. I knew it was coming, might as well help folks be comfortable with it.
  • We had (have) an intern from Outreachy, so beyond comms, it was important to also establish ways to contact me as her internship would continue well after I left.

Working with my replacement during the transition

  • I don’t have access to my calendar from work to verify but from memory, the new CTO and I had about 16 meetings, each between 1.5hs and 3hs, during the last 7 weeks of my transition. These were working meetings. We would pick a topic, and go deep into it. Some were technical things I knew more about due to my own context. Some were management things. Others were organizational context on its own that he may not have had.
  • Hiring: we dedicated a lot of time to discuss hiring, and presented a plan to the exec team.
  • Ensured we had discussions about inclusion, diversity, sexism, racism, and how they impact people. This matter to me greatly, as I worked pretty hard to fix issues that still affected my team, and I didn’t want to risk these efforts being ignored later on.
  • Set the tone for the new role and what it entails, explain where things get messy for me, and give him time to reflect on how it would look like for him.

Wrapping projects up

  • I had two important projects to wrap up during my transition that unfortunately had gone mostly to me as the only backend engineer. I worked to ensure I finished the key components, released them, and then transitioned it. While it wasn’t as smooth as I wanted it to be, at least we felt ready for me to not be involved by the time I left.
  • Pair programming on things that were ongoing: we did some pairing on areas of the codebase that the new CTO needed to understand. This was meant for him to be able to  onboard new backend engineers later on, and take care of emergencies as needed.
  • We had a contractor working with us whose contract ended right around the time I was leaving, so I had contact details sent over in case it was necessary.
  • For most of the other projects, because they were owned entirely by people in my team, we didn’t have a lot to do. It was just a matter of ensuring there was awareness that they existed and where to go for help.

External comms

  • I wrote a blog post about my transition, and we used it to announce my departure to external partners.
  • My boss (ED) managed the comms to our board.
  • My boss managed the Twitter comms

This is the concentrated version of 3 very intense months. When my last day came around, everything was ready for me to leave, and it was just a matter of sending goodbye messages and preparing LinkedIn recommendations for everyone I had worked with there.

I’m now taking a little break to reflect and decide what’s next.






The fallacy of the brilliant jerk.

Early days

The signals were there from day one. One of your direct reports asked a question and Adrian answered with a mocking tone. You told yourself you’d have a chat with him after your next meeting. By the time your meeting is over, they are all cracking jokes together. You shrug it off, thinking it’s all in your head.

By the end of their first week, Adrian has built a new module that got the VPE’s attention. The VPE tells you how impressed she is with the new hire and congratulates you on your choice.

A week later, a senior engineer is looking frustrated. She’s sitting next to Adrian, and they seem to be discussing the new module your team is building. You take her aside and ask what’s going on. She explains that Adrian keeps derailing the discussion to shit on our tech stack. He starts talking about migrating the backend to a new language he started learning last month. You have a talk with him, and for the first time you see it: he thinks criticizing the languages and technologies you are using without context makes him look smart.  

Nobody in this team gets promoted above senior unless there is strong evidence that they are able to help others grow. No senior engineer hoping for a promotion suggests spending millions of dollars on a migration based on personal preferences. You make sure he understands this, too. They nod, but not even 24hs later, you get a lengthy rant about your organization’s technology stack. The word “incompetent” is in there. You can’t believe you got yourself into this mess.

More likely than not, you have a jerk somewhere in your organization.

Most of us have worked with the so-called “brilliant” jerk. This is the person who speaks the loudest and cares about one perspective only: their own.

The jerk is always looking for something to criticize. If they can’t find anything, they will derail all conversations towards the things they want to discuss, like the fact that they really hate the technology choices made by a CTO 3 years ago, or their dislike of the code review process, which they assure you they don’t need to go through because they are very talented. 

They don’t have time to help unless there’s an opportunity to bring someone down.

When a junior engineer asks a question, the rest of the team jumps at the chance to be helpful, while the jerk looks for a way to nitpick their word choices. When the junior engineer asks “How do I import a component in the React framework”, they answer “It’s not really a framework” with a snarky link, without even giving them the information they need.

We’ve all been inconsiderate at one point or another, but the jerk will find as many opportunities as possible to bring people down. Their intention is not to educate. They just want to look smart.

The complaint

It only takes 3 months for the first official complaint to reach you.

You get a DM from Felipe, one of your senior engineers. They want to have a meeting with you today. As soon as you get the message, you get a knot in your stomach. Ten minutes later, Felipe has told you that Adrian is not a good fit for the team. Apparently, Adrian told Susan that she needs to stop wearing make-up if she wants to be taken seriously as an engineer.

You ask Adrian to explain, and he says it was a joke. He goes on a rant about the good old days, which you have to assume means “2019”, because they barely have 5 years of industry experience. You shake your head and explain that’s not an appropriate joke. For starters, it wasn’t even funny. You tell him to apologize right now. He nods, and the conversation is over.

Knowing you can’t go back to your desk until you calm down, you stay in the conference room for a few minutes listening to music.  It only takes 15 minutes for Susan to knock. She tells you that Adrian refuses to apologize for his behavior. You tell her how much you value her as an employee and assure her that you’ll deal with this. When you ask Adrian, he says he apologized. It turns out that Adrian’s version of an apology is “I’m sorry you were offended”. You explain how that’s not an apology at all, and you ask him to try again.

It’s 5pm, and things seem far from resolved. You bring Adrian back for a candid conversation. If this happens again, you will escalate it to HR. You know HR won’t help you unless they see Adrian as a risk to the company, but that seems to scare them into behaving for a while.

Fear is driving you to make bad decisions.

A more experienced leader would have fired Adrian that day, but this is your first time dealing with a so-called “brilliant jerk”. You think you can solve this. You think his contributions make up for the problems he caused. Furthermore, you’re scared your boss is going to think you don’t know how to hire good people. Your brain is spinning, and you feel like a failure.

A week later, Adrian yells in a meeting because someone else broke the build. He seems to have forgotten he caused a major production incident two days ago by ignoring the team’s processes. When that incident brought a client’s site down, everyone rallied to fix it. Not a single engineer pointed out who was to blame. That’s the culture you always wanted to build.

Trust has been broken.

A while later, Susan leaves. You don’t have to ask. She’s leaving because you didn’t act.

You failed to recognize the importance of this situation, and now it’s too late.

By now, it’s been almost a year. Now the jerk is a feature of your company, someone who nobody knows what to do about, or at least they won’t tell you… because in all those days, weeks, months, your brain played a little mind trick. Once this person started acting like a jerk, you started valuing their technical contribution as if it was the most brilliant code you’d ever seen.

Your team got the message: none of you are as valuable as the jerk.

Nobody wants to work with a jerk.

When the jerk receives something broken, they broadcast it. But when they push something broken, they get direct, one-to-one feedback from the person trying to work with them. This is how they stay employed. This is how they keep a reputation for being brilliant.

You hear “not-jerk broke the build” from them all the time, but you rarely hear “jerk broke the build”.

Nobody wants to hire a jerk.

You would never hire an incompetent jerk. Every little annoyance becomes a reason to remember how many times they saved your ass in a tight deadline. In those moments, the jerk starts to become not just a jerk, but a brilliant one.

You tell yourself you’ll talk to them once that new feature is done. It can’t be that bad, right?

Is the brilliant jerk really brilliant?

I want to give you a moment to think back on your jerk. The one that’s still in your team, the one that your boss admits “is not that great with people, but he sure is smart!”. The one who works alone because their teammates gave up on pleasing them.

Think critically. Take your time. If you ignore the impact they have on your team’s morale and just focus on their technical capabilities, are they really that great? Do you need them, or are you just scared of what you need to do next?

I will make a wild bet: they probably aren’t as critical to the company as you want to believe. They seem great when they save you from a last-minute problem, sure. But did they also cause the problem? Think back. Did they really save you? I bet they caused the issues more often than not.  That release they just saved? The deadline may have been met without heroics, if your team had not been busy dealing with a jerk’s bad attitude and going back and forth on decisions all month long trying to please him. The deadline may have been reached, if you had fired the jerk when he acted that way towards Susan. Susan may still be here, and Felipe wouldn’t be looking for work as you sit down to negotiate yet another deadline.

What about the really brilliant ones?

We generally want to believe that jerks are brilliant, because hiring and keeping someone who is both an average engineer and a jerk for a long period of time would make us look even worse than we already seem to be. The thing is, it’s very rare for someone who is a giant problem for your team to be performing at senior+ levels in their work, because engineering is a collaborative activity, and the highest performers are those who push their teams further rather than make them dependent on them or bring them down.

Sure, there are some who are truly competent if they can work alone. But realistically, all jerks cannot also be amazing engineers, despite the myths that we have been fed over the years. Even if you don’t account for the damage they do to their teams, it’s just not worth it.

In the end, it doesn’t matter how smart they may be.

It’s not worth it. Stop fighting a lost battle.

Next time you excuse the jerk in your organization, ask yourself if they are a net positive. What would happen if this person gave their notice tomorrow? Would someone in your team fight to keep them? Or would they be counting the days until they are gone?

Is keeping this person in the team so important that you are willing to lose your ability to hire and retain great people? Are you willing to continue to prioritize them over their team’s mental health?

If there’s a chance that you are just making excuses for the benefit of your own ego, it’s time to have a chat with your team.

Your team will respect you more for it. Given enough time, all of us will end up hiring a jerk at some point; what we do about it matters just as much as the fact that we did it. Mitigating the damage is the next best thing if you failed to prevent it. Stop making excuses, and work to rebuild the trust that’s been broken.You will respect yourself more for this, too.

Management Salary

C-Suite is making me promote someone without adjusting their salary: how do I talk about this with my team?

Being asked to keep someone at the same salary when they are taking a promotion can feel unfair.

It makes it hard for you to get a productive team…

It makes you feel scared that you’ll lose your team’s trust…

… and you know that if you don’t find a solution, even people who enjoy working with you may start looking for greener pastures.

The bad news is dealing with this type of issue comes with the territory, especially in small companies.

The good news is that you don’t have to go to your team in defeat… yet. There’s something you have to try first.

You have to go back to your bosses, with data.

Go to the root of this problem: the executives who asked you to do this. This is the time to be an advocate for your team. All that political capital you’ve been building up? Now is the time to use it.

First, let’s gather some data.

FYI: for simplicity, I’ll call your direct report Jane.

Create a new document that details

  • Jane’s current role and salary
  • Jane’s next role (post-promotion)
  • Industry rates (local) for both her current role and the one she’s being promoted to. If you find the data online, make sure you save the links for all your sources. For the USA, and can be a huge help to get a rough idea. In many industries and locations, you will need to do a lot more legwork to get it done. Talk to peers in other companies, check out job listings that may hint at ranges.
  • Try to figure out how much value *you* and your bosses really put in this position. Write down
  • The critical projects Jane is working on.
  • The problems you will face if Jane decides to leave.
  • The critical accounts/external facing people she interacts with
  • The people she is mentoring, coaching, or managing within your org.
  • Jane’s performance review and promotion package should be linked in the document and easily readable. If you have them, also add links to your team’s performance reviews and salaries, just in case you need to use them.

Remember: the point of this data is to start a conversation. You don’t want to set all the numbers in stone before you step into the room.

Make a separate private document to brainstorm on your own

  • Based on the information you have, get a good idea of what the ideal scenario looks like and write it down. Be prepared to negotiate.
  • If there are non-salary perks that you can throw into Jane’s new total compensation package, like more vacation or education assistance or stock options/rev share that she could be interested in, note them down too. Again, write it all down.
  • Write down a few alternative scenarios for total compensation.
  • If you have access to data such as your team’s profit margins, revenue they bring, key deliverables that are impacted by your team, etc, note them down here as well to have them handy.
  • Estimate how long it’ll take to hire a replacement if Jane leaves, and what will be impacted.

Schedule a meeting with the people who can make a final decision.

Make sure you have all the data you gathered and that you can share it with the people in the meeting.

Make sure your meeting has a short agenda explaining what will be discussed and that the key people accept the meeting.

Important – Don’t:

  • Approach this as a “fight”.
  • Place blame.
  • Assume they are evil/don’t care/will say no. It may be that they didn’t fully realize how important this person is to your team.

15 minutes before your meeting, take a break and relax

You want to appear confident and calm. Drink water, have a coffee, whatever helps you feel ready. The point of your meeting is to get both the company and your direct report a win. By ensuring your direct report feels valued and respected, you are helping the company retain their employees. You are not going into this to get a “win” for yourself, but to get a result that makes all parties as happy as possible.

During the meeting

Present the problem – 5 minutes.

Here’s a script you can adapt with your own words.

Problem statement

As you all know, we are planning to promote Jane. She has performed above her level for the past year, and we think she is ready for a new challenge. Unfortunately, if we don’t offer her a salary that matches the new position, this could backfire. I’d like to understand more about this decision and figure out a path forward together.

The data to support why this is a problem

I took the liberty of gathering data for companies of our size in the same industry and locality. While each company is unique, I discovered that if we keep Jane at her current salary in her next role, we would be underpaying Jane by at least 15%.

Empathize, appeal to risk of failure.

I understand the company is not in a position to do a big salary increase this quarter and that we would all prefer to wait until the next pay raise period to adjust it. However, the risk of not increasing her salary at all is losing an important employee that we have invested a lot into. Replacing Jane would take us at least 4 months, based on historical data from our recruiting system. In addition to this, If Jane leaves over this, we would have a hard time replacing her by offering the same salary she has now to a new hire with the same experience, and we’d also lose time by having to train a new employee.

Hit them with your proposed solution

I’d like to offer Jane a provisional 10% raise above her current salary, starting the day she accepts the promotion. This leaves her 5% under the lowest estimated market rate, which is still a concern, but becomes a lot more manageable. Because we were planning to give raises in 6 months, I propose we also commit right here to an extra 10% raise after 6 months in her role. This would bring Jane’s total compensation to an acceptable level that would significantly lower the risk of her looking for a higher paying job.

From there, it’ll come down to questions, answers, and trying very hard to avoid a HARD NO.
  • The ideal outcome is to get a (win) decision made during a single meeting. Even a small win is better than a No.
  • If you fail to make a decision in that meeting, make sure there’s a clear follow-up date & time in all your calendars, and that you forward all relevant information to the people in the meeting. This is preferable to a hard No, which you should work hard to avoid. Ask “What can I do to help make this happen?” and follow up.
  • If it’s not looking good, and you feel a firm No is coming, try to get a second meeting instead of getting to No. This gives you time to regroup and do some homework. That’s a whole different article, I’m afraid, but the TLDR is that if a NO is coming on something this critical, you should try to instead keep the door open, and find ways to re-open the decision if you do get to that No.

Getting results for your team is a key component of good management.

I’ve used a version of this script in almost every negotiation for salaries I’ve had as a manager in small organizations.

Sure, it always leads to questions. Sometimes it doesn’t work out perfectly, and you need to continue working things out over time.

That’s okay.

Having a system when trying to negotiate an employee’s raise helps you get better at it over time, and being prepared gives the message that you take this issue seriously.

The point is to get the best deal you can by using the information you have of the market, your peers, your bosses, and your team.

You may need to adapt the risks presented above to your own situation. It really helps if Jane is part of a critical project that won’t finish for the next 6 months, because then you get to use that as well to confirm how critical it is to make sure she feels good about her compensation.

Other times, you are not sure of salary ranges, or there’s no big lever to pull, and you may need to do some legwork and figure out the correct ranges and motivations to use.

For small companies, this is action plan gets results.

I’ve gotten big raises for direct reports using almost this exact same script and plan of action, without even the benefit of sites like PayScale and Glassdoor (because they simply did not have data I could use)…. relying on peers and my knowledge of the market, and even using information I had from my own direct reports when they got competing offers.

I’ve managed to raise direct reports’ salaries outside the usual salary raise periods when I’ve discovered discrepancies, using a similar script.

When I’ve failed, I’ve lost trust as a manager, and I’ve been in the seat across the table as key employees quit due to bad pay. You learn very quickly that if you don’t act, your reports will take action in their own hands. While counter offers getting expensive is certainly a useful lever in some cases, it’s a terrible situation to be in… while you do nothing, your team is looking for the next thing. They are more distracted, less committed, and likely to get tempted by a competing offer….

As a manager, you really want to prevent that from happening.

TLDR, in bullet points

  • Gather data.
  • Present the problem.
  • Explain the risks in the current plan.
  • Offer a better plan that takes into account the company’s current situation.
  • Take the negotiation forward from there.
  • The ideal outcome is to get a (win-win) decision made during a single meeting.
  • If you fail to make a decision in that meeting, make sure there’s a clear follow-up date & time in all your calendars, and that you forward all relevant information to the people in the meeting. Avoid a hard no.
  • If you don’t reach an agreement, ask “What can I do to help make this decision?” and follow up.
  • Remember that getting results for your team is a key component of good management.

Even if you have only been a manager for a month, you can do this.