editione1.0.1
Updated August 7, 2023Your professional relationship with your manager is one of the most significant factors affecting your career growth. You are ultimately responsible for your own career, but your manager has more influence over your career trajectory than anyone else in your company, so itโs critical that the two of you work well together. They sit above you in the organizational hierarchy, which gives them power to make decisions that can affect your career, both positively and negatively. This relationship has far-reaching consequences, such as which projects you work on and the opportunities youโre given. Many say that your relationship with your manager is the single biggest factor that affects your job satisfaction.
Some managers are great to work with, but others may prove more difficult. No matter how good or bad your manager is, itโs your job to make the relationship work. Every professional relationship between a manager and a programmer is unique, and youโll have to work hard to figure out what works best between the two of you. Your relationship with your manager will evolve over time, and youโll have to continue to adjust and make changes to how the two of you work together.
Trust is an important foundation for working well with your manager. If you canโt trust each other, your relationship with your manager will break down and your job will be more difficult than it needs to be.
If your manager canโt trust you can do the job they ask you to do, youโll miss out on projects and opportunities to grow and be promoted. If they canโt trust youโll communicate openly and honestly about the status of a project, theyโll have no choice but to micromanage you to get the information they need.
So, how do you build trust with your boss?
The first step may be obvious, but it needs to be saidโdo your job. Thereโs no way around this. Itโs table stakes for everything else discussed in this section. If you donโt do your job, youโre going to have a very difficult time building trust with your manager, so that should be your number one priority. Itโs literally just doing what is asked of you according to your job description.
The next step is to do your job reliably. Your manager needs to know you are reliable and that they can count on you to complete the tasks you are assigned. Doing your job reliably does not mean you wonโt make mistakes, your estimates will always spot on, or your projects will always be completed ahead of time. Nobody is perfect and timelines will slip, bugs will happen, and estimates will be wrong. Thatโs just a part of building software that you need to learn to live with. Being reliable means that your boss can count on you to take on a task and see it through to the finish line. The more often you do this, the more your boss will know that you can take on whatever they throw your way.
Thereโs more to being reliable than just completing your tasks. Here are some other examples of what it means to be someone your manager can rely on:
โdoโFollow through on your commitments. If you tell your boss youโll do something, do it. (And if you canโt, tell them as soon as you know itโs likely to slip so you both can decide how to mitigate the issue.)
โdoโAsk for help early if youโre blocked on a project or if you think youโll miss an important deadline.
โdonโtโSidestep your manager and leave them out of decisions with upper management.
โdonโtโRefuse or avoid boring but important tasks or projects.
A reliable software engineer is someone who is predictable (that is, does what they say they will do) and who is able to complete their tasks from start to finish. Doing just these two things will help develop a good foundation of trust between you and your manager.
While your manager expects you to deliver results each quarter, they have their own goals, milestones, objectives, and key results that they need to deliver as well. They are responsible for all the work your team delivers. Understanding this point will help you better understand some of the decisions your manager makes.
As a software engineer, your job is to do everything you can to support your manager so they achieve their desired outcomes. Therefore, your managerโs goals are your own goals.
โimportantโ This is an important concept that not many engineers understand early in their careers, because most of them are primarily concerned with proving their technical abilities.
Your work is just one piece of the puzzle that your manager needs to solve. When you understand how your work fits into the bigger picture, youโll be able to identify which tasks will help your manager reach their goals and prioritize those first. If you can manage to do this, youโll almost certainly gain your managerโs trust. Conversely, if you hinder your managerโs ability to meet their objectives, you may lose the trust of your boss.
โexampleโYour boss has a goal this quarter to upgrade the programming language for your legacy codebase to the next version. They need to do this because the version youโre on is no longer receiving security updates and there are new features in the next version that your team can take advantage of during development.
โdoโYou focus your tasks on identifying parts of your codebase that contain backwards incompatible changes, resolving issues with dependencies, ensuring the critical parts of the system have sufficient code coverage, and spinning up a new environment to test your code on the newer version. All of these tasks move your team closer to achieving the desired objective.
โdonโtโYou focus your tasks on building new features, refactoring old code to use a new design pattern you learned, and adding a new dependency to the codebase because thereโs a new library thatโs gaining popularity. None of these tasks help get your team closer to being able to upgrade the programming language version. In fact, things like adding additional dependencies may even make it more difficult to upgrade if the library isnโt compatible yet with the new language version.
In the bad example above, you may think that youโre demonstrating your growing technical skills and showing your manager that youโre a good engineer who can solve difficult problems. The issue is that the tasks you worked on were not aligned with your managerโs priorities for the quarter, whereas in the good example, you helped your boss get closer to their goal of upgrading the programming language version. If you want to build trust with your boss, you need to figure out how to align your own goals with your managerโs goals.
How to Earn Your Managerโs Respect (hbr.org)
How to Effectively Talk to Your Boss: 25 Dos and Donโts (careeraddict.com)
Things your manager might not know (jvns.ca)
Everyone works differently. Thereโs no single way to maximize your productivity that works for everyone, and everyone has their own way that works for them when they need to get things done. This is especially true when it comes to managing people and projects.
Different managers have different management styles, so when it comes to working well with your manager, youโll need to figure out what style they prefer. Youโll need to consider the following questions when determining how your boss prefers to work:
How do they prefer to communicate?
Asynchronous chat
Voice or video chat
Face-to-face conversations
How often do they expect updates from you?
Once a day
Once a week
As needed
What time of day are they usually available?
Mornings
Midday
Evening
Do they prefer if you provide them with objective analysis for each option, or do they prefer to hear your personal judgment when making difficult decisions?
Although these arenโt things you need to think about often, knowing the answers to these questions can make your life easier during high-stress situations like production incidents or tight deadlines. When you understand your managerโs preferred way to work, youโre less likely to make costly errors due to miscommunication.
Similar to how trust is a two-way street, a healthy relationship with your manager takes two people to make work. Treat your relationship with your boss as a partnershipโyou both share a responsibility to make it work. Unfortunately, part of that working relationship is out of your control; you canโt control your boss, after all, but at least you can do your part to uphold your end of the deal. As long as youโre making an honest effort to adapt to your managerโs work style, they canโt hold that against you when it comes time to conduct your performance review. However, if you donโt make any effort to work well with your boss, they may use that against you.
So, what do you do if youโre not sure what your managerโs management style is?
Ask them.
It may be awkward, especially if youโve been working with them for a while now, but itโs an important conversation to have, and being both aligned on what you should be doing will help you in the long run.
During your next one-on-one, ask them how you two can work better together. Itโs important to be open and honest here, even though it may be a bit embarrassing because itโs such a trivial question to ask. If possible, try to communicate your preferred style so they get an idea of how they can work better with you.
Honesty will always contribute to a better working relationship with your boss. The conversations may be uncomfortable or difficult, but they are worth it to build trust and respect. Your ultimate goal is to find the right balance when it comes to communicating with your manager.
Think of communication as a spectrumโone where you want to avoid the two extremes:
Under-communication: Solving problems completely by yourself and not even telling your boss.
Over-communication: Asking for help, guidance, or approval on every detail.
Neither extreme is right, and they will hinder your ability to build trust with your manager. The goal is to balance how much time and attention you demand from your manager when giving visibility or getting help, direction, or input.
Itโs a balancing act, and as a junior or mid-level software engineer, itโs your job to figure out how to make it work. At the very least, try to build a habit of asking your manager for help only after you have at least one potential solution. This shows that youโre not just dumping the problem in their lap, but instead asking for their help in refining the potential solution you already have. If you ask for their assistance empty-handed, it signals to your manager that youโre not putting in the work before coming to them for help.
Having a healthy relationship with your boss makes your job easier, but there will be times when the two of you arenโt on the same page. If your boss is overcommitted, overwhelmed, or even if theyโre not the best in a certain area of expertise, you need to learn how to manage up in order to make the relationship work.
To start, you need to recognize the situation youโre dealing with. Perhaps youโre dealing with:
A boss that has been at the company for years while youโre just starting.
A boss that has just started while youโve been with the company for a while.
A manager who is a know-it-all.
A manager that is new to the industry and may not know a lot.
An indecisive manager.
A manager that goes with their gut feeling instead of relying on data or the opinions of their team.
A first-time manager that is still learning.
โcautionโ Before we dig deeper into how you can manage up, you first need to understand what managing up does not mean:
Manipulating or deceiving your boss.
Covering up a mistake you made.
Hiding information from your manager that makes you look bad.
Inserting yourself into office politics.
When applied correctly in the right situation, managing up can help you achieve the outcomes youโre looking for, but if used incorrectly, aggressively, or in the wrong situation, it can backfire and hurt your image. It may take some time to learn how to effectively manage up, but when done correctly, you can get the results youโre looking for.
As you pick up tickets, you may be able to complete some on time without any outside help, but other times you may run into issues that require you to seek help from your team members. This may be as simple as mentioning what youโre stuck on during your teamโs stand-up and asking for help from someone familiar with the part of the codebase youโre working on. Occasionally though, you may find yourself stuck due to external factors such as a dependency on another team or a technical reason why you canโt continue.
As an engineer working towards a senior role, you should first try to figure out the issue on your own. Part of being a senior engineer is that you are able to complete small- to medium-sized tasks without any supervision from your manager. But sometimes youโll get stuck and need to bring in some help. Your boss may be able to help unblock you, and if not, they should be able to point you to someone who can.
In cases where youโre stuck because of a dependency on another team within your company, your boss may have more leverage to ask the other team to do whatever you need them to do. Letโs look at an example where you could leverage your managerโs position in order to get what you need.
โexampleโSuppose youโre implementing a new feature for the sales team in order to simplify their workflow. If you donโt have enough information to move forward on a feature request, reach out to the appropriate person on the other team to get your questions answered. If youโve been blocked because youโre waiting for a response, ask your boss if they can help get the answers you need. Sometimes, all it takes is getting your manager to contact the manager on another team to get your questions answered. Just be careful not to use this lever too much. You can earn a bad reputation with your manager if you escalate too often. It shows that youโre not able to handle roadblocks on your own. Only use this as a last resort after youโve done all that you can.
Sometimes, you may need to inform your manager about something they may not be aware of. Your boss has to make many decisions each day, and sometimes, they may not have all the information they need. Speaking up in these cases is part of managing up.
Your boss needs to know that you have their back, and sometimes that means telling them things that they need to hear, even though they may not want to hear it.
Perhaps your company is planning a new feature to bring in some new business. Your manager may agree to take on a new project with a tight deadline without realizing there are technical limitations that will make that deadline impossible without taking on a lot of technical debt. You should let them know as soon as possible so the team can adjust the timeline as needed.
You may have a boss that is new and isnโt aware of a risk factor that could cause you to miss one of your quarterly goals, such as integrating with a third-party system. If the other party is dragging their feet and thereโs a risk of not hitting your deadline, let your boss know as soon as possible so they can manage expectations and modify the plan for the quarter.
Itโs better to have difficult conversations with your boss about something than to let it simmer and boil over. By then, itโs already too late, and youโll have a high-stress situation on your hands. If possible, itโs better to be open and honest with your manager so they can pivot or change directions if needed. In the end, they will appreciate the fact you gave them honest feedback.
As individual contributors, weโre deep in the codebase each week. Weโre naturally familiar not only with the inner workings and how different parts of the system fit together, but also with which parts of the system need work. Itโs easy for us to understand why a seemingly small bug is especially hard to fix, but it may not be apparent to someone who isnโt writing code every day. You may deliver a feature that seems trivial but was actually a really challenging technical problem that needed to be solved.
Your managerโs day will be filled with meetings, so theyโll always be further away from the day-to-day technical challenges than theyโd like to be. Your boss may not know all the details about the problems youโre solving, so donโt just assume your boss is aware of the exciting accomplishments youโve made recently, or the technical challenges youโve overcome.
Part of managing up is learning how to inform your boss about your accomplishments. This is especially important if youโre close to or working towards a promotion. Ideally, your company will have a self-review process through which you can describe what major objectives you accomplished during each review period, but you donโt have to wait until the performance review process to let your manager know how youโre doing. Keep in mind your manager regularly gives progress updates to his boss, and heโll want to communicate about his teamโs wins and the progress theyโve made. To do that, your boss first has to know about what youโve done. Try to find moments to let your manager know about your accomplishments, whether itโs in private or public.
โexampleโWork with your manager to establish expectations on the types of outcomes and behaviors an engineer at the next level demonstrates, then find ways to let your boss know when you think youโve demonstrated them.
The Dos And Donโts Of Managing Up (idealist.org)
How to Manage Up at Work (wsj.com)
5 Tips To Manage Up At Work (forbes.com)
You and your boss are both adults. Youโll each have your own way of doing things, and youโll have your own opinions on how something should be done. Hopefully, youโll be able to figure out a way to work well together, but sometimes the two of you will have different opinions on how to accomplish a task.
If you have to disagree with your boss, do so politely and in private.
โcautionโ Do not surprise your manager with news in public. Doing so may catch them off guard and make them look unprepared in front of their colleagues, or even worse, their manager. Itโs possible your manager may interpret your actions as being disloyal to them.
When you and your boss have a disagreement, they may get defensive because they may think youโre challenging their goals. Oftentimes, they may focus on the intent of your actions, rather than the content of what youโre discussing, which is why itโs always good to clarify the context for why youโre disagreeing with them. If you can manage to help your boss understand your perspective, they may be less defensive and more willing to see the argument from a new point of view.
If possible, try to frame your opinion in the context of a bigger goal or objective. Doing so will allow you to be more candid and honest when discussing your opinion, in addition to helping focus your managerโs thoughts on the shared goal. It will also demonstrate that your difference of opinions is due to an external factor, rather than a personal attack on your bossโs views. If you fail to provide context for your point of view, your manager may perceive your disagreement as a lack of commitment to their own interests.
You wonโt always be able to achieve the outcome you want, and in the end, your boss has the final say when it comes to important decisions that affect you and your team. If your manager considers your point of view only to decide against it, donโt take it personally and donโt hold it against them. Itโs better to respect their decision, be professional, and move on than to continue disagreeing with them. If itโs not clear to you why they made the decision, consider bringing it up during a one-on-one. Perhaps thereโs another aspect to the problem that youโre not seeing, and it will help to talk to your boss about the decision they had to make.
Part of becoming a senior software engineer means accepting that not every decision will go your way. Sometimes you need to let go of an opinion you are passionate about and move on. Itโs better to work together with your boss as a team and trust that theyโre making the right calls, rather than pushing back on every decision they make.
Recurring one-on-one meetings are your opportunity to receive direct feedback from your manager about how you can be better as a software engineer. A common misconception among junior software engineers is that one-on-ones are meant to give status updates on their current workload. The conversations with your manager during your one-on-ones should be about career growth, not your day-to-day work. Donโt waste your opportunity by giving a status update about what youโre currently working on. You should be talking about higher level things than individual tasks.
These meetings are just between you and your boss, no one else. Itโs precious time for you to be honest and talk about personal things. Try to avoid talking about things that can be discussed in the open with the rest of your team, because thatโs not a good use of your time during these meetings. Your one-on-one is a chance to talk about the difficult things that you wouldnโt want to discuss in front of your teammates.
โimportantโ This can be awkward and uncomfortable at first, but the more open and honest you are about your feelings, the easier it gets.
Just be honest. This is your opportunity to get things off your chest. You have a direct and uninterrupted line of communication with your boss for a short period of time, so make the most of it.
While itโs your managerโs job to complete their teamโs long-term goals, they also need to fix processes and protocols that are broken or are not working for their team and their direct reports. They canโt fix what they donโt know is broken, however, so itโs your job to be honest with them when something isnโt working.
Let them know what challenges or frustrations youโve had recently.
Let them know if youโre having trouble working with a difficult teammate.
Let them know if a process isnโt working and why.
Let them know if youโre feeling overwhelmed or burned out.
So, how do you make the most of your time during your one-on-one?
Set a meeting agenda ahead of time and make a point to discuss everything on the agenda. Add any topics youโd like to discuss or questions you may have for your manager. Setting an agenda ahead of time gives your manager time to prepare and get you the answers youโre looking for. They may not always have an answer themself and may need to reach out to someone else for it.
Additionally, if you know ahead of time that they are going to ask you about a specific topic or task, make sure you have all the information you need in order to give them a sufficient answer. Your boss may set their own items on the agenda, so be sure to check it to see if thereโs anything that you need to prepare for.
You should be looking for both positive and constructive feedback during these meetings, which means you should leave the meeting with concrete things you should be working on. Be sure to write these down during the meeting so youโre able to reference them in the future. You have hundreds of decisions to make daily and multiple projects youโre responsible for, so itโs easy to forget specific things your manager asked you to do during your one-on-one conversations.
Plus, when you can look back on your notes, you can remind yourself of the things you need to work on. When your boss provides feedback, they expect you to listen and apply the feedback to your day-to-day work. Remember what you talked about, since they may bring up these areas of improvement during the next one-on-one. You want to be able to demonstrate you heard and reflected on the feedback.
This is your opportunity to ask for answers to specific questions you may have. โSpecificโ is the key word here. The goal here is to look for ways in which you can receive constructive feedback from your manager. This will help identify key areas you should focus on that will help you become a better software engineer, or things your boss is looking for in order to help you grow as an engineer.
โexampleโSo what are specific questions you can ask?
What are your top priorities right now and how can I help?
What am I doing well that I should continue to do?
What are some things I can improve?
Youโre looking for constructive feedback here. Your manager may give you specific things you can do to become a better engineer.
Itโs important that you make an honest effort to improve these things each week. You want to go into your next one-on-one and be able to show progress in these areas. When you can demonstrate to your boss that you are improving in the areas they are asking you to, youโre showing that you listen to their feedback and are making a meaningful effort to improve yourself.
Ask for advice on specific topics.
Your manager has been around much longer than you have. Theyโve navigated difficult situations and have a wealth of knowledge and experience. Use that to your advantage and ask them how to deal with specific scenarios.
โHow do I get better at saying no to requests that come in from other teams?โ
โIn your experience, whatโs the best way to deal with a difficult teammate who doesnโt listen to my suggestions?โ
Just doing these few things will help you get more out of your one-on-one meetings with your manager and provide you with plenty of concrete things for you to work on in order to grow as a software engineer. As long as you remember that your one-on-one time is meant to discuss personal and career growth opportunities and not status updates, youโll be able to make the most of the personal time you have with your manager.
The more you can demonstrate to them that you listen to their feedback and apply it in your day-to-day work, the more you will show them that they can trust you and that you deserve their respect.
The Simple Secret to Effective One-on-Ones (effectiveengineer.com)
Why All Engineers Must Understand Management: The View from Both Ladders (hackernoon.com)
At some point in every programmerโs career, theyโll go through the inevitable โoh crapโ moment when some code they wrote suddenly breaks in production. It happens to the best software engineers, and itโll happen to you. No matter how many steps you take to mitigate risks, sometimes bad code will slip through the cracks and cause a catastrophic failure in production.
In some ways, this is a rite of passage on your journey to becoming an experienced software engineer, because youโll gain valuable experience identifying, triaging, fixing, and recovering from an incident in a high-pressure situation.
Software engineers work on complex systems. Itโs impossible to fully understand how each new code change you deploy will behave in a production environment. We can take measures to mitigate risks, but itโs impossible to avoid them. So, what can you do if youโre not able to completely steer clear of breaking code?