Categories
Managing while Remote Process & Change management

On experiments and improving our release cycles

[This post was originally published in Q1 2020]

A few weeks ago I killed one of my own experimental attempts to fix how we work, and replaced it with a different one, adjusting for the problems found in the first iteration. It took less than 24hs to involve the correct people, get their buy-in, and even iterate on my experiment definition to enable someone to be a lot more empowered so that our team can move faster.

It had been less than 24hs since we started the new experiment when we got the first big improvement. From a pull request being approved to it being in production, in 24hs. It used to take several days, because someone would approve, then it would be merged by the person sending the pull request (if it was a teammate), and then the merger would send it to QA. That would often add 24hs to the QA process just in tickets sitting there waiting.

In those 24hs, more tickets would get merged, adding to the workload of our QA and to the amount of things that could go wrong. Even with a plan to do weekly releases (our last iteration was doing some changes that could bring down release cycles from monthly to weekly, and it was not super successful even if we did improve our cycle time)

Recognizing when something isn’t working.

Our first attempt at improving our release cycle was a compromise. Because of historical reasons, we never made releases a very big priority until this year, so for months now we have been doing small improvements that bring us closer to our goal: when things are ready, they go out. In our last iteration, I decided that we would do weekly releases to production as a “baby step” towards releasing just as soon as something is ready.

The idea was that we’d get better at the release process, then shorter the cycles. So what improved

  • Releases went from monthly or longer to weekly or every two weeks.
  • Someone who had usually not done releases before started doing them.
  • Releases started getting more documentation on what was going live, we committed to always tagging and thanking contributors in release packages, and we started working towards ensuring docs get started on time. Release tags were going out, finally, in a timely fashion.
  • Releases got everyone collaborating to get them out. It used to be something that happened very much on the background, and they became a more active part of our weekly check-ins.

With 4 or more major improvements, you could say we succeeded. The reality is that we got a lot of good “side effects” of making releases a priority, but we didn’t get as close to “just in time” releases as we need to be.

The iteration of this experiment with weekly releases failed because the goal wasn’t ” improve a lot of important things”, the main goal was “a ticket should never wait more than a week to be in production once it’s sent for testing”.

We knew this, because we documented the goal from the start. It was clear that was where we wanted to be for this to be considered a success.

After doing this recap of “what is going well” and a very frustrating week when my release was not getting… well, released, I decided to kill this experiment, and start fresh with the “just in time” improvement.

There was some push back to doing releases weekly, with a general feeling that it’d take too much time out of the week, so I expected the same for “just in time”. What I found instead was that everyone accepted it pretty fast. To be honest, this hasn’t been something I’ve opened up for negotiation all that much. I’ve said time and time again that being able to release often is non-negotiable.

Does it feel shitty to do that as a leader who tries to bring everyone into big decisions? yea, totally. I feel shitty writing it here, too. But I also feel it’s the only correct decision. When long release cycles are your biggest engineering team cultural debt, and there’s a lot of people in the company who haven’t seen a release cycle that makes sense in many many years, you have this internet stranger’s permission to be the person who says “No, this actually will be done this way”, even if it costs you points in the short term. Explain until it gets boring, follow up, hear the team’s concerns, but make a decision.

As long as you reserve your right to be stubborn about 1 or 2 things and not all the things, I think this is a reasonable approach. If you are making all the decisions yourself, then you’re in trouble and need to go fix that, first.

Without releasing, the impact of the code you write is nil, or negative even, for a long time; the time you spend writing code consumes valuable resources (money, other people’s time, you time) without producing any value for long periods of time.

It may sound counter intuitive that if you can’t achieve weekly releases you should go for daily/just-in-time, but I think it’s actually the only way to go. If you can’t achieve weekly releases because something always goes wrong early in the process, the only possible solution is to minimize chances of “things going wrong” being a problem. Things will always go wrong, so it’s minimizing the impact of each thing going wrong and our ability to respond that matters the most.

We minimized this risk by making the person in charge of QA the one responsible for merging pull requests. Rather than make it so that developers merge their PR once they are ready, we are putting this responsibility in our QA so that he’s the one making the decision on “can we add this ticket to our testing environment, or not?”, and then deciding if a ticket makes it to production based on the results from testing.

Long term, I want us to have enough automated test coverage, observability and safety nets to do more releases, more often, faster, with less risk. For the moment, this is providing speed that we never had until now, and just enough safety to keep us sane.

Categories
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.

Categories
Managing while Remote

Open offices are not for everyone.

There’s this common statement about remote work: “Remote isn’t for everyone.” Yes, I believe that’s absolutely true. I also believe very strongly that shared offices are not for everyone, either. Even offices with doors that close aren’t for everyone. The problem is that open offices are considered the “one size fits all” of work environments. They’re advertised as a good default, but they only suit a portion of the population. We all pretend it’s both normal and okay to assume that everyone at a company has the same needs when it comes to their workspace and daily workflow. 

For many of us, open offices are actively harmful. I get a lot more done when I have granular control over my environment, my breaks, and how I work. I can’t get that kind of freedom in an office, with or without doors that close. Would I like to have the sweet spot of a work situation where I can go into the office when I feel like it, do some whiteboarding with my team, and then go home? Yes, totally, but it’s a very unusual setup, and not one that’s available right now in most companies.

Working remotely is not inherently harder than working from an office. Saying so implies that offices are “ground zero,” the absolutely neutral choice for a workspace. They aren’t. Remote work is hard, and so are offices. For some of you, offices are the easy choice. For others, remote work feels like a haven from the noise and distractions of the modern office environment. It’s not a universal feeling or choice.

Remote work is hard because work is hard. Remote collaboration is hard because collaboration is hard. Remove “remote” from either statement and they’re still true: Work is hard, collaboration is hard. The struggles of teamwork don’t disappear because the location has changed. 

Our work is challenging, and no amount of in-person collaboration will change that. Healthy team dynamics are hard to create and maintain. They take a lot of work, they don’t just happen. Dealing with performance issues is hard. It’s hard as a remote manager, and it’s also hard as a manager who shares an office. Hiring is hard. It’s hard remotely, and it’s hard in person. You are making a difficult decision with limited information in a short period of time. 

I don’t believe the future goal is to not have offices at all, but to have options. The key is to make it easy and normal to go remote; to have more companies who align with remote work and offer that experience; to have companies who think about whom they want to be when they grow up and have decided remote is for them. I believe the future includes hybrids where you sometimes go into an office, and sometimes you work remotely. I believe the future also includes some companies with an “office culture,” and that’s okay. 

Remote work, much like offices, isn’t for everyone.

There will always be offices. Physical spaces where humans meet to collaborate are natural and needed. I just hope there are more remote-oriented companies in the future because it means more of us will get to work in spaces that make sense for us. But this will only happen if we allow ourselves to really think about what spaces make us feel productive and happy and stop worrying about how it will look for investors and customers if our employees don’t go into HQ each day. I genuinely think this re-orienting of how we view the workspace will come true.

Categories
Hiring Management Managing while Remote

Remote developers need to grow in remote organizations

Intro.

Most companies and teams know the benefits and the need to hire junior engineers; after all, that’s where seniors come from. While that’s true for many companies, for many remote leaders or folks who are considering a remote job, the idea of hiring early career engineers seems to trigger an automatic NO reaction. I’ve talked with people who have been managing remote teams for years, and they still feel like Junior folks won’t fit in, will not onboard correctly, will lack opportunities for growth or plainly hurt their company.

Is it hard? Yes, remote is always hard. Here’s the thing: open offices are hard too (for me, much much harder, for others, maybe not), but we still bring junior engineers into open offices, so we might as well bring them into remote environments and support them as they learn how to work.

I believe by saying we cannot hire juniors into remote environments we are doing our companies a disservice, and we are giving our teams the wrong message when we say only seniors can join our remote team.

We need to get better at this.

We can’t insist that remote is the future while sustaining that a new generation of engineers cannot join us for the next 5 to 10 years.

We’re telling senior developers and managers that it’s best for juniors this way.

We are assuming that junior folks don’t know what’s good for them when we disregard their interest in working remotely by saying things like “it’s best to learn in an office”.

Not everyone can go to an office and get a good job that will give them opportunities for growth. Many people function better in remote environments, and I don’t see how being a junior developer stuck in an office will be better if you can’t deal with open offices or noisy environments.

We are saying they will have too much of a hard time, that it’s better for them if the people in offices take them and grow them before they can join our teams. That’s not always the case, and that’s not always desirable.

When we say “only seniors can join a remote team”, we are giving juniors way less credit than necessary.

 

The real concern with hiring junior developers seems to be the amount of support they’ll need, not the fact that they’ll be bad engineers, so I have to ask: why do we act like we are hiring a kid that needs constant vigilance, instead of realizing we are supposed to be hiring a mostly grown, adult human being?

Remote employees don’t learn how to be remote from working in an office.

Most of us started out in offices, and we all had to unlearn some things to thrive in a remote environment.

Do you want to just drop junior engineers in a team and hope for the best? No, of course not. Do you want to start with junior engineers before you have figured out the very basics of remote work? Nope.

But many of us work in established remote companies. Companies that have been here for a while, companies with senior people who can mentor others.

Use that. Teach new people how to do remote well. They have no bad habits from 10 years of office work, so you have a really good chance at helping them learn how to be remote.

Creating a new generation of remote leaders starts by practicing remote leadership.

How will we create an excellent, empathetic, remote first leadership pipeline if we are preventing seniors to learn how to help everyone regardless of where they are located? Learning how to help other people grow remotely is a new skill for many senior developers.

How do we empower and create the next generation of remote leaders if we are actively stopping a huge part of the developer population from joining us in remote work?

If we only hire other seniors, we are preventing them from acquiring what should become an important part of their leadership toolkit: mentoring folks in all skills levels, remotely.

Hiring only seniors is putting the burden to grow engineers on other people.

Seniors don’t grow in trees. If you only hire seniors, you are also saying someone else is supposed to do the work of mentoring and helping those junior people improve.

It makes me think that maybe you won’t help me with my own professional development goals either.

Show us that you don’t just think on the short term.

Having a junior person in your team gives the message that you are investing in the future of your team, and you’re not just thinking in the short term.

Everyone in your team will have excellent opportunities to help others get over their mistakes, learn, iterate, and do better next time.

It will force you and your team to think even more often about how safe people feel to fail and experiment, and if you play it right, it would mean that people of all levels will feel safe to make mistakes, share them and learn from them, instead of hiding things under the rug when something goes wrong or being terrified of getting a stretch assignment because it could be risky if you need too much help or get something wrong.

Give your team the message that remote work does not mean it’s everyone for themselves.

People with less assumptions can help improve your workflows.

Here’s another reason why your team needs junior developers: the senior folks will have an invaluable opportunity to use the brains of new people who have fewer preconceptions about how things should work.

People with less preconceived notions on how things have always worked will help you improve workflows and tools in ways that benefit everyone, including very senior ICs. This can provide fresh opportunities for seniors to work on engineering-lead projects that will help them showcase their skills, both technical and leadership oriented.

For people who want to advance in both the IC-track and management track, having projects where they control the goals and can provide proof of what they achieved is really beneficial, and for their managers, it can be an easy way to boost morale.

What can you do to help remote junior developers succeed?

With all this, I guess what’s left to say is “what can you do to help your new, remote, junior team member succeed?” I don’t know if you’ll like the answer, but it’s almost the same things that you did in those shiny offices:

  • onboard them both in the technical aspects of the job and in the “this is how the company runs” aspects.
  • check in about onboarding in 1-1s. Regardless of level, I like to ask simple questions like “how do you think this decision was made”  or “do you know who approves your vacation requests?” to understand how onboarding is going for them.
  • make sure they know that you care about what they produce and how they interact and help the team, not how many hours they worked.
  • on the previous note: also make sure they know overworking is not okay and that you expect them to ask for help.
  • pair programming: try to find the time to pair once a week with junior folks. Be explicit that you expect juniors to be pairing up with seniors and even managers (when the manager codes). Coding together is an easy path to bring down walls.
  • ensure they are participating in code reviews (if you have them) not just as the person whose code is being reviewed, but as the person reviewing code. Find tiny changes they can help review so they get used to both sides of this and integrate fast with the team.
  • provide opportunities for them to do interesting things at the level they are at.
  • give them feedback often. Once a week is okay. Once per month is too little.
  • ask for their feedback often. Once a week is okay. Once per month is not enough.
  • ensure they have a few seniors in their team so that they have people they can go to when they need help.
  • provide extensive coaching on onboarding and mentorship to your senior engineers. This will be like onboarding a new person in some ways. Check in often to ensure they understand what is expected of them and can adjust their approach if something isn’t going as planned.

There’s no special magic that makes it impossible for junior developers to succeed in a remote environment. Your company doesn’t need a 200-page guide on how to make it work for them before you consider hiring one.

If your seniors are doing great, if there is psychological safety, if you have a team of peers that are eager to help each other succeed, you have what it takes to mentor juniors.

You’ll set them up with a manager that does their 1-1s weekly, you’ll help setup 1-1s with senior developers, you’ll make sure they get to know their team, you’ll provide guidance on how the company operates… this is not that different from what you should do for new people regardless of level. It’s not even all that different from what you should be doing in a very large, probably very noisy open office.

As a little time goes by, you’ll notice their work patterns, how they want to be helped, what interests them and what seems to not be their strongest suit. You’d need to notice this stuff for senior folks too. If anything, seniors can sometimes be harder to get to their A game because you might not have walked the path to the next level yourself. Maybe before being a manager you made it to tech lead, but you were not a staff engineer, so you can’t guide them at a technical level as much as you can with a more JR engineer, and since you are not as skilled as an engineer as they are, your only recourse is to help them navigate the organization instead of the code…. this is way harder to do in a remote organization than sitting down with someone to pair for a few hours or reviewing code more often than you’d like (and to be clear: we still need to do that part, we still need to help senior folks navigate the organization)

Hire Juniors. Help them become mid-level. Keep them happy and growing.

If you do this well, you’ll eventually have a new group of seniors in your team: the ones that stayed with you from their junior and mid-level years, and the previous senior folks, the ones that developed their mentoring skills and are now leading others in whatever capacity they enjoy the most.

Categories
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.

 

Categories
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.

 

Categories
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 levels.fyi, payscale.com and glassdoor.com 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.