Do’s and Don’ts for Discussing Compensation with your Manager

Compensation is no one’s favorite subject to discuss with their manager, but it’s sometimes a necessary conversation to have to ensure that you’re being paid fairly in accordance with the market both inside and outside of your company. Every company has its own philosophy and process around compensation, so it’s impossible to offer a strategy that’s guaranteed to win. The following do’s and don’ts are sets of crowdsourced wisdom that I’ve collected and utilized in my career, some from people I know and others from online resources like my all-time favorite post on the subject from Patrick McKenzie.

While they’ve achieved varying degrees of success as measured by adjustments to my pay, these tactics have always left me with a better sense of my value to the company without burning bridges with those I work with. This advice is intended for those looking to have a conversation around compensation at their current job but may be applicable to negotiating an offer at a new job as well.

Do’s:

  • Know your value: Compensation conversations with your manager are always held under an imbalance of information (think: salary bands, company budget, market data, promotion timelines, etc.) The best way to level the playing field (and bolster your confidence) is to develop an informed sense of your value before having the conversation. If your company has a culture of pay transparency among ICs, take advantage of it to better understand where you fall within your pay band. If you know folks in similar roles at other companies, see if they’re willing to exchange numbers, or look at sites like Glassdoor and levels.fyi. If you’re willing to put in the effort (and are well-versed in negotiation basics), engage in interviews with other companies to determine the value of your exact skill set and experience. Since your company will likely justify its comp offering by citing market data, bringing in your own market data can help you keep the conversation going within their framing and gives legitimacy to your request.
  • Help them help you: I’ve been surprised to learn just how little power managers sometimes have to make comp changes, often needing to translate any request to help you up their management chain and to HR. One strategy you can try is to provide them with an argument that they can use on your behalf. For example, I’ve heard from managers that one of the cases they can act on most immediately is that of large pay disparities across gender or race – presenting them with a differential between yourself and a peer of similar level, tenure, and track record from a more privileged class can be something they can bring to HR and address right away. For less clear cut cases, you can try to present an argument that would appeal to the business more broadly. Maybe there is a unique aspect of your background such as an advanced degree or relevant experience from a different industry, and you can make the case that the market data your company uses to make comp decisions doesn’t reflect niche profiles like yours (which you can back up with external offers or data points from other companies.) Or maybe your role requires a specialized skill set that isn’t reflected in your pay band, and reclassifying your role to reflect that would better align the company with the rest of the industry and make future hiring efforts easier. Regardless of the approach, sending your manager a followup email summarizing the argument can be useful.
  • Know what you want (besides money): I saw a great insight from Lara Hogan recently that “Many comp convos are actually core need convos.” In my experience, the desire for more money can be a manifestation of other types of dissatisfaction, as in, “If I’m going to be this unhappy here, I’m going to need a bunch more money to stay.” Unhappiness could come from any number of factors, including but not limited to brutal on-call shifts, unclear and contradictory top-down directives, abusive teammates, or ignored feedback. While sometimes comp requests really are just about the money, I’d encourage anyone going into one of these conversations to first take a step back and assess whether there are also non-financial areas of support they can ask of their manager that would improve their happiness. For example, maybe you’re feeling overworked and underpaid relative to the value of your output, and you can ask that the team hire more engineers to spread the load. Or maybe you feel that you’re no longer learning new things, and you can ask whether there’s opportunity for a team or role change or for professional development resources like courses and conferences. Managers often have little to no flexibility to make immediate comp changes and may ask if there’s any other support they can offer you, and it’s best to be prepared with an answer.
  • Understand how comp decisions are made: Gather as much information as possible around how compensation decisions are made within your company. This can be helpful, for instance, for timing your conversation appropriately within your company’s compensation review cycle. Julia Evans recently came out with a great blog post on questions you can ask over time to learn about the process at your company.

Don’ts:

  • Make threats: It can be tempting (and sometimes even effective) to threaten to leave the company unless they give you more money. Generally I don’t think this is a good idea, perhaps unless you’re really, truly happy with walking away. If you do stay, it’s likely that you’ll fray your relationship with the company and diminish your future chance of success, as folks generally aren’t super enthusiastic about helping those that threaten them. And if they deny your request, you’re left with little recourse having already played your most nuclear option. Instead, I try to be forward-looking in my requests, calling out the aspects of my job that I love and the upcoming opportunities where I could provide immense value to the business, all of which would be easier if my compensation more closely matched my market value.
  • Take it personally: Easier said than done, of course. But your compensation is not a reflection of your value as a human being. Period.
  • Avoid the conversation: The biggest disservice you can do yourself is to not have the conversation at all and assume that good work will be rewarded as a matter of course. While I don’t think that most companies are trying to undervalue employees, they are for-profit businesses at the end of the day and aren’t incentivized to pay you more than it takes to keep you happy. You are your best advocate when it comes to knowing your value as an employee and making it clear that you need to be paid accordingly.

An IC’s Manager Voltron

A couple of years ago, Lara Hogan shared a fabulous post introducing the concept of a Manager Voltron. The gist of the post is that the types of support needed for career growth are varied and nearly impossible to find from any one given person, so one can formulate a group of mentors, or “voltron,” to fill out areas of support that may be lacking from their manager alone. Lara also provides a handy worksheet to help readers identify folks who might be good components of their voltron. I thought I would supplement that resource by providing some more specific detail on who comprises my manager voltron, which also has a certain skew towards the type of support that’s useful for a senior IC.

My voltron

My actual, real-life manager voltron consists of the following people:

  • My manager: My official manager is an integral part of my voltron and provides a form of support that can only come from them, regardless of their particular strengths.
    • As the one formally responsible for my professional development and for delegating work on the team, I rely on my manager to have an in depth understanding of the areas in which I want to grow and to grant me opportunities to meet those goals. For example, when I tell her that project delivery is something I’d like to work on, my manager might delegate to me tasks such as writing a planning doc or scoping tickets on our team’s next big project.
    • My manager also helps me identify areas of growth that I may not be able to see myself by taking into account organizational values and a wealth of experience in managing other engineers.
    • I also rely on her for regular, honest feedback in the areas I wish to grow that align with her own areas of strength, such as communication and leadership. In a previous post I describe how I use 1:1s to solicit this feedback.
  • A more tenured peer on my team: A respected peer on my team provides guidance on a day-to-day level and is a lighter weight source of feedback than my manager.
    • As I work towards a better understanding of what makes a successful engineer on my particular team, I look to a longer tenured teammate as a day-to-day role model in a wide range of areas, such as development setup for faster iteration, best practices around testing and monitoring, code review norms, and communication with the team and stakeholders.
    • As a quick source of feedback, I rely on him as a gut check for ideas that I’m working on, such as whether a given technical approach is feasible or strategies for better communicating with our manager.
  • A very senior engineer not on my team: I rely on this person’s broad purview and organizational clout to source opportunities outside of my immediate team.
    • This engineer has awareness of the biggest projects folks are working on across the company as someone frequently solicited for architecture advice. When I tell them about projects that I’m working on or thinking about, they’re able to connect me to other folks who may have worked in a similar space in the past or whose upcoming release I may want to coordinate with.
    • This person also acts as my sponsor for opportunities for increased visibility within the org, putting my name forward when opportunities for cross-team projects or working groups arise.
    • As a long-tenured engineer within the company, they have insight into the promotion process and often give me concrete, actionable steps for career advancement based on their own experience.
  • An EM not on my team: Having a trusted manager outside of my reporting chain to turn to for advice helps me play devil’s advocate when conflicts with my own manager arise and provides additional transparency around organizational processes.
    • When I occasionally butt heads with my manager, I turn to her to help me better understand my manager’s position, which I can use to help us reach consensus faster. For example, when my manager gives me feedback I disagree with, I turn to this person to understand why that feedback may be important or relevant.
    • She also provides me with organizational transparency when my own manager is sometimes reluctant to provide it, which helps me understand things like promotion and compensation decisions and resource constraints my manager may be dealing with.
  • A strong technical leader outside of my company: This person gives me important perspective on issues that I deal with at work by putting them in context with the industry as a whole.
    • When I describe challenges that I face at work, she helps me determine what’s normal or weird based on what she’s seen in her own experience at different companies. This gives me comfort in knowing of others who share my experiences and helps me understand which of my frustrations I should put aside as industry standard or may be reasons to move on from my current role.

How I built my voltron

Most relationships with those in my voltron have come about organically as folks I have worked with directly, either presently or in the past. When I stop working closely with someone whose guidance I value, I make sure to maintain regular contact with them through a recurring 1:1 where appropriate or by reaching out every so often for advice or catch-up sessions.

If I feel that my voltron has a hole unfillable by someone I already know, I might think about folks in the org or industry with strong reputations and ask a mutual connection to set up an introduction. An important thing to keep in mind is that a good voltron feeds itself: the more trusted mentors that I have, the easier it is for me to find additional ones through their support.

How to give useful peer feedback (and not hate doing it)

Following another grueling performance review cycle, I’ve seen many of my peers gripe about the seemingly never-ending process of writing feedback for each other for a range of reasons: it takes up too much of their time, it’s difficult to craft in a way that’s useful to the reviewee and actionable by their manager, it can be selectively filtered by the reviewee’s manager in a way that’s harmful to them, and it’s just plain awkward. While these are valid complaints, I actually love giving peer feedback! But that hasn’t always been the case – it’s taken me some time to formulate the feedback process as a problem I’m interested in solving, as well as to craft feedback in a way that’s valuable to the one receiving it. It’s been well worth the effort, though, as I’ve found peer feedback to be one of the best ways to build strong relationships with my teammates.

How I motivate myself to give feedback

As an engineer, one technique that I’ve found to motivate myself to give good peer feedback is to view each of my teammates as a complex system to understand. Each colleague is unique in terms of the stage they’re at in their career, what their goals are, and what kinds of support and resources they need to achieve them. I enjoy trying to puzzle out each of these components through a combination of asking directly and matching those answers against patterns that I’ve seen work for myself and others as well as my knowledge of resources within the company that may be beneficial to them.

Aside from the problem-solving challenge, I’m also of course motivated by the desire to be an advocate for my teammates’ accomplishments to their management chain and to help them grow. And, selfishly, by giving my teammates actionable advice on areas ranging from problem-solving to communication, I’m making it easier for myself to build great products with them in the future.

Building good feedback habits

I’ve found that I can make things easier on myself come formal review time if I’ve already given some thought to what sort of feedback my teammates might be looking for and if I’ve established an informal feedback culture with them ahead of time. A couple habits that have worked for me:

Ask them what their goals are

My colleagues are all generally pretty self-aware about their areas of opportunity and what types of work they need to accomplish to get to where they want to go. At many companies, those ideas are even often made concrete in the form of either a formal or informal goal-setting process. I can help my colleagues better as a reviewer if we’re on the same page about what they’re working towards. If I’m particularly close with the person, I may ask them directly what they wrote down for their formal goals or if their manager told them they should be focused on something in particular. Otherwise, to avoid awkwardness, I try to use casual settings like lunch or a mid-day snack break to ask questions like:

What are you excited to be working on this year?

or

Is there something else you wish you were working on?

The answers to these questions often give me insight into what sort of opportunities my teammates find engaging, whether it’s learning about a new domain or embracing a stretch leadership role, as well as development opportunities they’re lacking.

Maintain a culture of regular, informal feedback

Though it’s sometimes difficult, I try to make feedback-giving a regular part of my interactions with my colleagues rather than only part of a review cycle. I do this for two reasons: it takes up less of my time during the review cycle if I already have a list of feedback for them, and it’s unfair to surprise my colleagues during a review with feedback they haven’t heard from me directly before. When I observe a teammate doing something well, particularly when I know it’s aligned with the areas of opportunity they’re working on, I make sure to tell both them and their manager, perhaps through an informal Slack message, email, or 1:1. When we complete a major project together, I often schedule time with them to collaboratively reflect on things that we can do better as a team next time, which creates an opportunity to deliver individual feedback as well. In either of these cases, it’s useful to jot down some bullet points in a doc to refer back to come review time.

What to do at review time

When it comes time to write formal feedback for my peers in the context of a company review process, I’ve also learned a few tricks to avoid some of the feedback pain points I mentioned earlier.

Ask them what they want feedback on

I had my mind blown during a recent review cycle when someone writing feedback for me Slacked me a simple question:

Is there anything in particular I should focus my feedback on?

I found this to be an amazing way to make sure that the feedback that I was receiving was relevant to the areas I was actively looking to grow in. Since then, when writing feedback for others, I’ve tried asking that question along with another:

Are there any accomplishments you’d like me to highlight to your manager?

Not only do these questions help me write feedback that’s actually useful to the person, they also save me time by narrowing my focus and help me establish a stronger bond with my teammates.

Frame feedback in terms of things they want

One common complaint I’ve heard (and experienced) about peer feedback is that managers can manipulate it by selectively highlighting constructive feedback as rationale for a poor rating or denied promotion. I try to turn this game on its head by framing constructive feedback in terms of opportunities that my teammates have told me they want. For example, if I know my teammate wants the chance to learn about Cool Thing X, I may say:

“One area of opportunity is for Beth to broaden her domain expertise and become a thought leader on the team in alternate areas of the problem space, such as Cool Thing X.”

 If I know that they really want to work on an exciting cross-team project, I may say:

“One way John can expand his leadership skills is by working on projects outside of his team’s immediate domain.” 

As an added benefit, the specificity of this type of feedback makes it easily actionable by their manager, though sometimes I make this explicit, as in:

“Jen’s manager can support her in building her domain expertise by offering resources such as a budget for online courses or conference travel.

Share it with them directly

While I try my best to be delivering regular feedback to my teammates throughout the year and consider it a failure if they’re hearing anything for the first time in a review, I strive to maintain full transparency by sharing with them directly the feedback that I’ve written for their manager. That way, my colleague has the full picture of what I’ve shared outside of the narrative their manager is telling, and I avoid them losing some of the message in translation by giving them the chance to ask clarifying questions.

Writing feedback can feel grueling and pointless, but by approaching it like an engineering challenge, building good feedback hygiene throughout the year, and putting the system to work for your teammates, it can be less painful and even enjoyable as you build stronger relationships with your coworkers and put the system to work on their behalf.

Having effective 1:1s with your manager

Inspired by @polotek’s recent post My Approach to 1-on-1s, I thought I’d offer my own approach to 1:1s from the perspective of the report rather than the manager. 1:1s are a key part of how I communicate with my manager and offer me an opportunity to address issues that I find important, ranging from team operations to career development. 

I’ve found these meetings to be most effective when I come prepared with an agenda of topics to discuss and strategies for communicating them effectively. I recognize that my manager’s time is valuable, and I want to show them that I value it by putting thought into how we use the meeting. Also, when I don’t come prepared with an agenda, the conversation is usually more superficial and less relevant to my direct happiness and growth. My 1:1 time is my one opportunity to focus the conversation on my needs, and I want to use it well.

I write down my talking points (usually between 1 and 5 per week) in a doc that my manager has access to, so that they can see that I’ve put thought into the conversation and begin to think through the topics ahead of time if desired. Over time I’ve calibrated the amount of detail to put into my written agenda prior to the meeting: usually around one line per talking point is a good balance. I generally jot down my topics throughout the week as they occur to me so that I don’t forget, but when I occasionally don’t have anything written down prior to the meeting, I’ll make sure to reserve some time at the beginning of the day of the 1:1 to give it some thought.

The talking points that I bring to a 1:1 generally fall into one of three categories:

Team operations (people and technical)

The one goal that my manager and I most strongly share is for the team to be operating as effectively as possible. As such, this is the area where I focus the majority of our time. I try to give feedback on things that I think are working well or not on our team and call out opportunities for ways that I think that the team could be operating more efficiently. Some sample topics for my agenda might include:

  • My teammate and I collaborated really well on that last project. Can we try to find more opportunities for us to work together going forward?
  • I think this project could be moving faster if Internal Tool X that we depend on for testing had Y features. Could we talk to the team that owns it to explain our pain points?
  • I think it’s really important for the growth of our product that we invest in tooling to make future development easier. How would you feel about migrating from technology X to Y as part of this project so that we can reduce development time on the next project?
  • I’m a little confused about the ownership of some of the responsibilities for this track of work. Can we get to a little more clarity on who’s doing what?

One strategy that I’ve found for effectively communicating my thoughts in these areas is to map my feedback back to values, either ones that I know that my manager holds or to the official values of the company, which we’ve both implicitly agreed to uphold. For example, my company has a value around operating efficiently, so if I’m confused about who’s doing what on a project, I might explain how the confusion is leading to duplicated work that violates that value.

I’ve also found it important to keep my feedback in this area balanced by making sure to call out things that are both working and not working well (not necessarily in each meeting, but overall over time.) When I feel that something isn’t working well on my team, I try to convey that to my manager in the form of curiosity rather than skepticism, such as by pointing out examples of things that confused or surprised me, to give my manager and teammates the benefit of the doubt and acknowledge that I may have incomplete information. I also try to respect my manager’s time by bringing to them not only problems but also several potential solutions that I may just need their help implementing.

Self-promotion and career development

Particularly when I have a manger who’s not closely involved with my day-to-day work, I use 1:1s as an opportunity to point out my achievements and ask for opportunities that might further my career development. Some sample topics in this area include:

  • I’m really happy with how that last project turned out! We delivered it on time and the experiment results showed a big impact on our KPIs, and I think it was a great opportunity for me to showcase my leadership and problem solving skills.
  • I’ve been working hard on my written communication after the recent feedback you gave me, and I think it really showed in that last project proposal I wrote. What do you think?
  • I think the team could really benefit from having an in-house domain expert in Area X, and it’s something I’d love to learn more about. Can you help me find resources around the org or externally to learn more about it?

One tactic that I’ve found helpful for keeping my manager and me aligned on my development progress is to frequently call back to areas that we’ve identified as having room for improvement. When I reference that particular skill as part of a recent accomplishment, my manager knows that I’ve been taking their feedback seriously and can more easily articulate my progress come review time.

When I make requests of my manager for opportunities or resources to aid in my career development, I also try to point out how that opportunity will benefit the team rather than just myself. I recognize that my manager has limited resources available to them and priorities beyond my individual growth, so where possible I try to frame the impact of granting my request in a way that’s more aligned with their broader goals.

Asking for advice/feedback

I also use 1:1 time to leverage my manager’s skills and expertise for the benefit of myself and the team. Over time as I build a relationship with a manager, I come to learn what their strengths and passions are and where I might best be able to learn from their expertise. If the manager comes from a strong technical background, I may ask for advice on architecture for a new system I’m designing. If they are adept at team building, I may instead ask for help navigating tricky team dynamics.

Aside from generally viewing my manager as someone with a set of experiences and skills that I can learn from, I also want their feedback on areas I could be improving in, both for my own growth and to minimize surprises in performance reviews.

For example:

  • Would you mind taking a look at my recent project proposal and helping point out any edge cases or side effects I may have missed?
  • I had a tense interaction with a teammate on the project we’re working on. Do you have any advice on how I might be able to better communicate with them?
  • Do you have any feedback for me on my testing strategy for releasing that upcoming feature?

I’ve found that it’s often better to frame these types of questions for my manager in terms of “advice” or “thoughts.” The word “feedback” has official performance review connotations that may catch them off guard and avoiding it can often lead to a more casual and frank conversation. I’ve also found that asking my manager for advice signals trust in them and strengthens our relationship.

When I’m asking for feedback, I try to make my requests specific rather than broadly asking “Do you have any feedback for me?” Specific requests lead to more substantive conversation. Also, by focusing my requests on specific areas of growth that I’m focusing on, it makes it easier to build a cohesive narrative around my development over time.

While these three areas are how I generally spend my 1:1 time with my manager, the amount of time I dedicate to each one and the specifics within them are often subject to change based on what I’m working on at the moment and the unique characteristics of my manager. As I build a relationship with a new manager, I’m always trying to hone a better understanding of what they value and where their strengths lie to adjust how I communicate with them. There’s no one size fits all answer, but I’ve found this to be a useful framework to start from.

What is this blog?

It occurred to me recently that while I’ve seen a ton of material intended for managers on how to lead, that audience represents only a small portion of the engineering workforce. The majority of us working in engineering fields are in non-management roles, striving for mastery, autonomy, and purpose in a technical capacity. While most of us work in organizations designed to support us in our growth, ultimately we each bear the responsibility for our own development and happiness, and knowing how to make use of (or work around) the organizational structure we operate within can be a challenge. Just as leadership in a technical organization is a skill, being managed is also a skill. As @mipsytipsy asked in her excellent “Management for Anarchists” thread: “Where are all the books on followership?” (Julia Evans’ “Help I Have a Manager” zine is a fantastic resource in this space, but I think we need more!)

Though the “I” in IC stands for “individual,” software engineering isn’t performed in isolation. We rely on our more experienced peers to learn from, our more junior peers to question our assumptions, our direct managers to provide us opportunities and resources to grow, our upper management to set a vision and resource our teams, and our cross-functional partners to help shape our roadmap based on business and customer needs. Each of these groups also has their own set of goals which sometimes conflict with ours, making our lives more difficult.

As an academic-turned-engineer with now several years of experience across companies at various stages of growth, learning how to operate successfully inside an organization presented a steep learning curve for me. This blog is meant to be a collection of strategies that I have found personally helpful for operating as part of an organization. While I hope for the content to be relevant to a wide range of engineers, it’s informed by my own unique set of experiences and as such may be inherently biased towards those at a middle level of seniority in a medium to large organization. I also recognize that the strategies I offer might not work for everyone, nor are they the only way to be successful.

Finally, one point of clarification: while this blog is intended as a resource that’s specifically for non-managers, that doesn’t mean that it’s for non-leaders. Leadership is a broad term and usually is a key part of a senior engineer’s role in some form, such as setting technical direction for the team, mentoring more junior teammates, or having autonomy to tackle larger and riskier problems. My hope is to make it easier for ICs to focus on whatever part of their role they value most.