Mistakes to avoid Onboarding engineering teams

Onboarding 101: learn how people in your organization get paid.

Similar to “Tell them When, Where and How to show up” this is another “simple” mistake with a big impact. It seems so simple to avoid… but if it happens it makes your company or team look incompetent, or simply like you don’t care enough about the new person in your team.

Here it goes. A mistake to avoid:

Not paying the first month’s salary on time.

It’s obvious, right? Someone works for you, you pay their salary. I’d never think this happens until it happened to me.

I was working with a great team, having a great month… and when pay day came, my salary wasn’t there. The first day, I didn’t think much of it. After all, delays may have been the fault of the bank. By the fourth day, I was pretty sure something awful had happened.

It turns out, the outsourced company that handled our monthly salary payments didn’t have my information on file from the first day, and that caused delays on the process later on.

“I haven’t been paid… do you know what’s going on?”

If you do your homework, even if/when this happens, you will have an answer to help them

One day, you’re happily working with your team. The next day your pay isn’t there, and you’re left to wonder if this place is being managed correctly. Who are these people, after all? You only just met most of them.

When you don’t already have a high trust relationship and something like this happen, it can be a big blip on the company’s record. It may not matter right away if nothing bad happened due to the delay, but it won’t be forgotten instantly, either.

Get familiar with the process used to get people paid for the first time.

I don’t work in Finance. I’ve never worked in an HR department. But because of early experiences I had, I’ve often been the person nagging other departments to ensure pay would be sent on time to my direct reports, that their contracts were sent in a timely fashion, and that all the basic things were covered on their day-1 onboarding.

I know how it feels when money is not in your account on the day you expect it. I know what it’s like when your contract hasn’t been signed by your managers, and you’re not sure what that means for you. It’s little things, in that they can be fixed in 5 minutes… but it’s hugely important to get them right, or we are risking breaking people’s trust.

If you’re a people manager and don’t know what the process is to get someone paid on time, make sure you become familiar with it. It can be as simple as asking Finance “Is all the information for Jane up to date in the system? I’m just going through my checklist.” or as involved as asking for a demo on how this is handled. A simple “I’m curious about this part of onboarding a new employee, can you tell me more about the process?” can help you understand the parts of the process that can go wrong, and if you ask “How can I be helpful?” they may even let you know of a simple thing you can do to avoid silly, completely avoidable, but ultimately bad mistakes.

Isn’t this micromanaging another team?

Maybe! That’s an excellent point. And to that, what I will say is that it’s your job to learn how your organization works. If you are fully confident that this could never happen, and you understand how the paperwork moves through the organization? Go right ahead and ignore it.

If you’re not quite sure why and how you get paid? Please, ask someone in HR or Finance to do you the favor of teaching you how these things work so that you can sleep soundly at night. Would you look down on someone from another department if they ask you to explain tech debt? Probably not. I know I love it when I can collaborate across disciplines to improve the organization. This isn’t that different. When I’ve done it, I’ve always been wiser about our org after the fact. You don’t have to be a jerk about it. You can just ask a few questions. The key here is that you’re ultimately going to be responsible for this person’s onboarding and their performance, and it’s going to be on you to keep things running smoothly.

Not paying someone on time is the kind of mistake that looks bad on everyone, not just the person writing the checks.

Humans make mistakes, it’s not a big deal.

I agree. I make mistakes too. Big or small, we all mess up something at some point (sometimes, a lot… I’ve been there!)

It’s unreasonable to expect that nothing will go wrong, ever. But the truth is that paying people on time is a baseline expectation that must be met. As managers, we can be helpful in ensuring things get done on time for our directs.

If it ever happens, and it’s the result of human error, and you understand the process well enough to explain it to your direct report? You’ll be in much more solid ground than if you’re just as confused as they are.

Management Short thoughts

More thoughts about management.

I wrote this as my answer to an application question for a remote company a few years back. It’s a bit outdated, but I thought I’d share it anyway.

In a broad sense, to me management is about people and the things that stop them from achieving what’s important at an individual, team and company level.

It’s about understanding and helping solve the issues stopping a team from being in their A-game, which starts with the individuals and ends with the company as a whole. If a team has issues because people are distracted thinking about how bad their CI solution is, or someone is blocked every morning because they aren’t getting the information they need from another department, it’s a manager’s job to find out and help the team come to a solution. The best solutions come from the people closest to the work, but the responsibility of finding and facilitating the resolution of those issues is on the manager; sometimes that means just supporting the team on a decision they made, and sometimes it means solving it yourself in one way or another.

I believe one of the best things you can do as a manager is becoming skilled and comfortable at delegation and facilitation, and always pushing yourself to delegate larger and more important work to the people who demonstrate they can do it. It means you are comfortable looking from outside, coaching people to excel at their assignments, and being accountable for work that you had very little to do with in the day to day.

It’s about delegating authority, rather than only tasks.

You have to be comfortable saying no often and explaining your rationale as needed, but you also have to be able to check yourself and reevaluate If someone comes to you with a concern about a decision you made.

Understanding and communicating the value of what we’re doing so that others have the context to make smart decisions is one of the most high value things you can do as a manager. People deserve to understand why their work actually matters, and they produce much better work when they do.

An effective manager should be comfortable switching between coach and the person being coached, being able to put yourself in a position to ask questions to get to the root of a problem without letting your ego get in the way.

Being a decent manager can mean being aware that you have very little control and still owning up to whatever the team is achieving or not. It’s finding the time to be connected to the work that the team is doing and being able to facilitate decisions, but not letting yourself hide from problems in the comfort of coding. It’s also remembering that your work touches real people with real lives.

Management Short thoughts

Ensuring new tech leads get a chance to succeed

When assigning technical leads, take care to put them in a situation where they will succeed easily, especially if this is their first time with a tech lead role. The tech lead role is one of the most challenging roles to go into because you live in a sort of limbo where you are still mostly doing IC work but have much more responsibility.

If it goes badly the first time, you might lose a high potential IC over a project that was doomed from the beginning. Try your best to set up all your new tech leads for success, and eventually you might just get lucky and find your replacement in one of them (you know, for when you’re hit by a bus or a bike or something).


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 Managing while Remote Process & Change management

Building product development processes.

Early in my career, I used to think process was something people introduced because they were bored and had nothing better to do apart from bothering us, the productive,  bread winning devs that built the thing.

Years later I found myself working with a team that had all the elements of a process and none of the glue that holds it all together. There were strict rules for some things, zero rules for others, and no idea of why each rule was introduced or how. “Why do we do it this way?” was something I asked a lot…  always coming back with little to show for, or a very unsatisfying answer like “that’s how the previous manager did it”.

Process and tools were all pain inducing, with little to no regards of what the team actually needed to succeed, what their own pains were, how they could solve those pains or mitigate them.

And so, I did exactly what anyone with no previous management experience tends to do: I made the team work exactly like we worked in a previous team I had been a part of… a team were things just got done and quality was always a concern… a team of senior engineers with almost zero things in common with this new team except for the fact that we were building something.

I was looking at process as a series of steps instead of a framework that helps us achieve what we need.

I was thinking of the process as a thing we would have some day in the future, not the thing we already had. It was messy and undocumented, but we had a process, and you can’t really push for something new without understanding what came before.

Somehow, the new process took. It became “how we work”, and we were vocal about it. We would argue with other teams when they looked down on us for doing code reviews. We would suggest using git and explain why we wanted every release to be tested and tagged. From time to time one of us would mess up, and we would try to adjust how things worked, and step by step things would get better.

Years later, that process had been tweaked by many others, and it was ours instead of mine. It had grown and learned, and it was no longer “Romina’s thing”, it was our thing. It was cause for many disagreements and valuable discussions, for many issues that could have been prevented if we had seen the error in our ways, but also of many moments of joy, many innovations, many attempts to make it better, shinier, more useful, and for that I’m grateful.

Your team having a process is a journey, not a goal. Your team already has a process. It may be messy, undocumented, and maybe they don’t know it exists, but it’s there.

To create a process, you need to first find the one that already exists. You can’t dismantle something you don’t understand. I mean, clearly you can, but believe me, it’s a lot harder.

Your shiny new product development process is not very useful until it’s collectively owned, and it’s definitely not useful until people who have been there a while stop needing to constantly go to documents to figure out how it works.

It should be simple, it should prevent errors, it should help you identify issues when they happen.

A good process makes your work feel easier, I almost want to say it should bring some joy.


PS: Imposing a process on that team worked, at a surface level, because people were genuinely scared of what would happen if we didn’t change things fast. It wasn’t successful, and it certainly wasn’t easy until we had gone through many iterations and collectively changed it for the better. While it was “my” process, it felt forced and awkward. When it finally became our process, things got increasingly better, and it no longer depended on me to make it happen.

Management Short thoughts

Engineering Management is like Debugging

Engineering management is a lot like debugging and bug-fixing at times.

Sometimes you don’t know much about a failure except that it happened. Sometimes the solution is clear but risky in some way, and sometimes you just know what needs to be done and wonder why you didn’t do it earlier.

More often than not, there’s a problem coming up that you didn’t expect and don’t fully understand. As with code, those bugs are hard to figure out, but when you do, it’s extremely rewarding.


Managing while Remote

Challenges of remote work

I’m a huge fan of remote work. It’d be hard to convince me to take a role where I need to go to an office every day.

Even as a remote work believer, there are still days when I wish we could get everyone in the same room for an hour without it being a big deal and involving air travel.

Where you live still matters.

Since many companies opt to hire “Remote US”(or wherever they are from) your options will often be limited by location.

This is especially true if you don’t live in the USA. The competition for remote jobs is huge, so the stakes can be higher at the interview stage. In that case, chances are that you will work in “remote worldwide” companies (which are not the majority) and it’s likely you will be setup as a contractor or hired through a 3rd party “employer of record” service.

That first day in a remote team is weird.

Joining a remote team is great, but don’t expect the first day in a new company to be the same as joining a new team in an office.

I remember my first week as a fully remote worker, it was super weird and it took a little time to feel like I could even take a step away from the computer. I was notifying my coworkers of important events like “I’ll be out for the next 10 minutes” for no reason other than being worried they might think I was slacking off 🙂

If you can’t travel at all, you’ll miss out on really important opportunities to get to meet your team.

I found that going to team retreats and casual events helps improve personal relationships. There’s very little ways to replace the unstructured interactions that happen in a team retreat setting. Making coffee together in the morning, cooking for a group, walking around the block to go grab a drink or buy supplies, going on a fun day trip, solving unexpected issues that happen during the week…. these are all things that help you connect in different ways.

A team retreat feels like 6 months worth of interactions compressed in a single week or two. Instead of talking near the coffee machine for 30 seconds, you essentially live with these people for days, either in a big house or in a hotel. You don’t get that very often in offices, but I suspect some teams would benefit from this even if they have offices to go to every day.

The counterpart to “bonding in team retreats” is important, too: it can be done outside “in person” interactions, it works great, but in my opinion you need to also have some real world interactions, especially when someone first joins so that they can feel fully integrated.

Being the only team member who never met the team in person can be super weird, but after that first meetup, things get easier.

Sometimes I miss looking around the office and being able to see my coworkers excited about the same things as me.

The last time we got some great news that affected the team, I felt a little sad that I couldn’t be in the same room to congratulate the parties involved and hang out with the team after we got the announcement.

There’ll be one on ones, and GIFs in slack. There’ll be ad hoc chats and spur of the moment calls with folks.

But even then, it won’t be the same as being in the same room. It was just one of those weeks when I wished I could grab a cup of coffee or a beer after work, without needing a video call.

Any communication problem will seem to be related to being remote.

That one bugs me, but I’m guilty of this too. Some problems are clearly related to the remote aspect. John says “ok” in a DM and leaves, and now someone is left spinning for a day because they thought something was wrong. John is always so cheerful, why didn’t he add any emoji? WHY? Anyway, I’m not saying this happened to me… but yes, yes it did happen.

Some problems are more likely to be related to remote work.

Some problems would be even worse in an office.

There are things that would be more or less the same, but maybe they would present differently and have the same result, like John making a decision while chatting with Juan in the office and forgetting to document it and let the team know. Six months later, there’s confusion about how this happened, who made the decision and when. This is the type of thing that can happen in an office, but when something similar happens remotely, we tend to attribute it to remote work instead of just thinking “someone forgot to document a decision”.

What I’m saying is that remote workers are extremely aware of the fact that their work style may be problematic at times. This tends to be good, because we obsess over having every decision written down and sharing notes from meetings (and when we don’t, great people call us out, loudly).

Remote workers seem to be in a state of constant introspection about whether the remote thing is working out, and so we tend to think everything is a remote work issue.

Kanban board out of date? Must be the lack of whiteboards.

John forgot to mention a deadline before his vacation? Must be the remote thing, if we had seen John leave through the front door for the week maybe someone would have asked about it (in case you are wondering: people in offices also forget things sometimes).

You need to be explicit about keeping in touch.

Since you won’t run into people while you make your morning cup of tea/coffee/whatever, you need to be intentional about “running into” folks online.

If you don’t make an active effort to talk with your team, you may never actually have contact with them except for short messages in GitHub issues and other focused  tools/activities.

This is fixable by setting up 1-1 calls, instant messaging, hanging out in the remote “water cooler” type channels and talking with people there, etc.

It’s just different, and you need to be more intentional about it, especially at first.

Time zones

Time zones in a remote team are one of the main friction points. If you wake up and half your team already finished their day, you’ll need to adjust how you work.

In my current job we try to adjust things to be as async as possible, and it mostly works. This includes most of the on-boarding activities, day to day communication, development, discussions about strategy, etc.

Just because we need to work in a more async way it doesn’t mean that everything is done asynchronously, just that we optimize for our situation instead of optimizing for synchronous work. Sometimes we have to make sacrifices and join a late or early meeting, but generally the team tries to avoid having the main discussion be synchronously and opt for google documents instead to give people a chance to write down their thoughts and give their input ahead of time.

I really miss whiteboards sometimes

This one is weird, but I liked having the ability to walk up to a whiteboard with a team when I needed to collaborate on a hard problem.

Digital whiteboards are okay, but they don’t necessarily replicate the experience of the analog ones.

Solving this “lack of whiteboards” issue to me comes down to unlearning some behaviors, sending drafts of how I think something should work, getting on a call and discussing it, and then iterate on shared documents with others. Sometimes even creating the diagrams right there in the call and adjusting them together as a pair or group.


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.