Chapter 5. Getting Buy-In
By my second to last year of high school, I decided I needed a cellphone. Not only did nearly every single one of my friends have one, they were no longer interested in having me use theirs to call my parents every time I needed to inform them of my whereabouts. With each text costing roughly 10 cents, and each call costing them precious minutes, I was dishing out dimes and quarters to nearly a half-dozen friends for months. Carrying a pocketful of change wherever I went, hoping I could borrow someone’s phone was no longer my cup of tea.
Because my parents weren’t proponents of their daughter having a cellphone, convincing them to get one was going to be an uphill battle. “Everyone else has one” was not going to cut it. My parents would need to be presented with a strong set of evidence-backed arguments. So, I put some together. I formulated an argument around owning a cell phone for safety reasons. Having recently obtained my driver’s license, I needed to be able to call someone in case of an emergency. I calculated a rough estimate of the number of hours per week I spent driving to give the argument a bit more weight. Next, I compared device and plan costs, comparing these to the amount of money I’d distributed to friends over the last six months. I’d recently started building websites to make a bit of money on the side and knew I could afford to buy a basic flip phone and pay the monthly bill.
In response to my arguments, my parents said they didn’t think it was a necessity. I could borrow my mother’s phone when leaving the house. After pointing out that I was spending three to four hours per week driving both myself and my little brother around, they decided that maybe it wasn’t a luxury after all. They were sufficiently convinced that the convenience of having a cellphone outweighed its cost. I got a hand-me-down flip phone with a number of my own a few days later.
Today, this experience serves me well when I have to convince others about the benefits of beginning a refactoring project. One of the complaints I hear most often from fellow engineers is that they have a strong desire to refactor something but they simply don’t know how to convince anyone to let them do it. They’ve spent the time identifying the circumstances under which the problem arose, found evidence and metrics to characterize the problem so that they might better understand it, and carefully crafted a plan for how to solve it. They’re certain that the problem needs to be solved and are ecstatic about their solution, but are met with skepticism when presenting their ideas to either their manager or tech lead.
This chapter will kick things off by explaining why your manager might not be on board, and help you understand their perspective so that you can craft a compelling argument. Next, we’ll cover a few different approaches you can take for garnering the support of your management team, with some specific strategies you can use to get them rallying behind you. Finally, we’ll look at some of the forms buy-in can take, and how these can impact both your execution plan and the team you end up putting together.
Why Your Manager Is Not on Board
Your manager might be hesitant (or outright opposed) to a large refactor for a few distinct reasons. First, they are typically well-removed from the code and unlikely to intimately understand its pain points. Second, they are evaluated on their team’s ability to ship impactful product features on time. Third, the worst-case outcomes associated with a large refactor are generally much more serious than the worst-case outcomes associated with a new product feature. Finally, large-scale refactors typically require much more coordination with stakeholders outside of your immediate team.
Managers Aren’t Coding
Most engineering managers are rarely coding, and hardly partaking in code reviews. In fact, someone hired directly into a management position at a new company might never even see the code their team works on. Because your manager isn’t intimately familiar with the problems you and your team are frequently encountering during development, it shouldn’t be a surprise that they are skeptical of your proposal. Imagine trying to explain to a dinner guest why you want to replace all of the rickety doorknobs in your home; they might be able to understand the frustration logically, but they don’t know the extent to which they are irritating on a daily basis.
Maybe your manager understands the difficulties your refactor aims to improve, but they fail to see why these should be fixed now. After all, if these problems are not new, the company must have been handling them (and is continuing to handle them) just fine. Your manager is weighing the potential upside of building something new against fixing a set of lingering problems.
Managers Are Evaluated Differently
Managers tend to be evaluated on their team’s ability to hit deadlines and help achieve business objectives. These tend to include things like building features which help retain and acquire more users, or unlocking new revenue streams. Because managers have these incentives, they’re more likely to prioritize work that has a high impact to effort ration; that is, work that is relatively low-effort but offers a high impact. Managers are also more likely to set more aggressive deadlines in hopes of getting these changes out to customers sooner.
These goals are sometimes at odds with with those of the engineers on the team. Engineers tend to seek out projects that solve interesting problems and often prioritize building a more robust solution over one that’s quick to ship. (Not all engineers fit into this mold, but in my experience, this sums up quite a few of them.) A large refactor, while perhaps a meaningful, worthwhile endeavor to your and your teammates is at the bottom of your manager’s potential projects list. At-scale refactors are usually lengthy, and because they are deliberately invisible to users, result in little to no immediate positive impact to the business. If your manager is looking to move up the ladder (or if they’re concerned about their upcoming review), they will probably be less than eager to support your plan.
Tip
Even if your manager is convinced that the refactor is worthwhile, they might be risking good standing by giving you the go-ahead. Just as your manager is evaluated on your team’s ability to build and deliver on time, their own manager is equally evaluated on the impact that their organization is able to have on the business. It can be difficult for your manager to convince their own manager that a refactor is a valuable investment of engineering time and resources.
Managers See the Risk
There are a handful of ways feature development can go awry. Your team might run into a handful of roadblocks and ship a bit later than initially anticipated, or maybe the feature makes it into the hands of users, only to reveal an abundance of pesky bugs. However, the likelihood of a catastrophic outage during the development of a new feature is relatively low because new features tend to be relatively well-scoped, with relatively well-defined boundaries.
The stakes are much greater when executing on a large-scale refactor. The team risks introducing regressions across a large surface area, and the likelihood of a disastrous outage is not nearly as negligible. When untangling old, crufty code, there’s a much greater chance your team will unearth unexpected bugs; the risk of being pulled head-first into a rabbit hole in an attempt to fix them can significantly delay your deadlines. Each and every one of the risks we highlighted in Chapter 1 are alarmingly obvious to your manager.
Managers Need to Coordinate
Most companies organize engineering teams around individual portions of their product (or products). Say you work for a music streaming application called RadTunes. RadTunes might have a team responsible for playlist creation, and another for managing search. When a team sets out to build a new feature, typically they are operating within an area of the codebase that they own. It’d be surprising to see the Search team build a new feature allowing users to create collaborative playlists; the more obvious choice would be the Playlist team.
Now imagine that you are on the Playlist team and the team is struggling with the song object model. You’ve come up with a plan for improving it, but it involves modifying code nearly every one of the teams at the company works with regularly. You and your manager will need to coordinate with every single one of these teams at the onset to solicit support, and continue to coordinate throughout the refactor to make sure everyone is properly aligned. When you pitch your refactor to your manager, they are seeing the colossal amount of work required to keep everyone organized for the complete duration of the project. It’s only normal that they might be hesitant to support it.
Strategies for Making a Compelling Argument
Now that we understand why our manager might not be on board, we can focus on a few helpful strategies for assuaging their fears and constructing a robust case to convince them that the refactor is worthwhile. This section assumes you’ve already had an initial investigatory conversation with your manager about your project. If you haven’t had that conversation yet, “Initial Conversation” is a good starting point. This conversation is important for two reasons. First, it helps you understand which factors are weighing most heavily on your manager. Second, it gives you a sense of whether your manager might be more readily convinced by an emotional or logical argument. This conversation will give you the preliminary context you need in order to choose the most effective strategies to convince your manager.
Once you’ve had that initial conversation with your manager, you can zero-in on the persuasion techniques you might want to use. We’ll outline four simple, distinct techniques here, but know that this is not an exhaustive list. Different strategies will work best with different managers, depending on what motivates them the most (e.g. their growth trajectory at the company), or the degree to which they are opposed to the refactor (e.g. they are generally in agreement that the problem exists but are unconvinced it should be fixed imminently). Ultimately, the most effective way to nudge your manager into giving the go-ahead is to use a combination of techniques: opting for those you believe will have the most impact, and are most comfortable using. If you are confident and well-prepared, you might just get the “yes” you’ve been seeking.
Using Conversational Devices
Some of our colleagues are able to walk into a meeting full of stubborn engineers and within a half hour have everyone persuaded of their opinion. Unfortunately, I am not one of those people. If this isn’t you, either, not to worry! There are a few easy (and honest) conversational tricks we can use to express ourselves in a more convincing manner.
Compliment their thought process
Very few of us are immune to flattery, your manager included. If at any point during your conversation, you and your manager agree on something, highlight it with a compliment. For example, you and your manager agree that the refactor would be beneficial, but your manager would prefer reevaluating in six months. You can shift the focus back to the benefits of the refactor by saying, “You’ve made some really great points about the potential benefits of a refactor. It’s pretty clear you have a nuanced understanding of the problems we’ve been experiencing.” Your manager will be reminded of the benefits they identified and inclined to weigh them more heavily against the potential downsides.
Present the counter-argument
Not only should you be prepared for any counter-arguments from your manager, you might even consider bringing up the counter-arguments for them. It may sound a bit odd, but a number of psychological studies have shown that two-sided arguments are more convincing than one-sided arguments. There are a few benefits to presenting counter-arguments directly:
-
By demonstrating to your manager that you’ve seriously considered the downsides of a large-scale refactor, you’re further demonstrating your thoughtfulness and thoroughness around the effort.
-
You’re reaffirming your manager’s concerns; while you might not be outright complimenting them on their ability to reason about the drawbacks of a large-scale refactor, you are confirming that their apprehension is legitimate. Your manager will be more open to hearing about your ideas if they feel that their own ideas are well understood.
Now the trick to using counter-arguments in your favor is to carefully refute them. Let’s refer back to our RadTunes example “Managers Need to Coordinate”. Your manager is planning for the Playlist team to spend most of the upcoming quarter building collaborative playlists. You’re proposing the team spend crucial time rewriting the application’s representation of a song before kicking off development on a new feature.
You could tell your manager, “if we began refactoring songs next quarter, we’d have to put off work on collaborative playlists for a few months. That would certainly be disappointing to our customers who have been requesting this feature for the last few years.” You can immediately address the issue by following-up with a rebuttal: “However, I’m confident that if we rewrite our songs implementation, we’ll be able to shave several weeks off of collaborative playlist development and unblock the Search team on surfacing better results by genre.”
You can even introduce a counter-argument your manager hasn’t brought up yet or one you doubt they’ll bring up at all. This sounds counter-productive, but it will boost your trustworthiness and strengthen your stance, assuming you successfully knock down the counter-argument.
Tip
While this is not a book you’d typically find on a programmer’s shelf, I highly recommend grabbing a copy of Dale Carnegie’s How to Win Friends and Influence People. It was published over 80 years ago, but most of its lessons continue to hold true today. The skills it teaches will be helpful to you no only when trying to secure buy-in for your projects, but in all aspects of your life!
Building an Alignment Sandwich
If you are uninterested in playing office politics to your advantage, that’s perfectly alright and you are welcome to skip ahead to “Metrics”. On the other hand, if you are interested in leveraging the organizational landscape to your benefit, there are a number of levers we can pull to effectively compel your manager into giving the go-ahead on a large-scale refactor. We can build an “alignment sandwich”, securing the support of your teammates along with the support of upper management, sandwiching your manager between the two.
This approach only works if you have ample support from both sides of the of the sandwich. If your manager only feels pressure from your team, then they’ll still be on solid footing to turn down the refactor knowing there’ll be little flak (if any) from their superiors. If your manager only feels pressure from above, and your team is not vocally supportive (or worse, your team is vocally opposed), they’re unlikely to move forward with the project knowing they risk harming team morale.
Be mindful that this strategy can backfire. Given your previous conversation, your manager is aware that you’re interested in pursuing this refactor. If they are approached by upper management or other influential individuals at your company about moving forward with the refactor, there’s a chance they’ll put two and two together and deduce that you’ve been seeking external influence. If you have a tenuous relationship with your manager, this could lead to some backlash. Regardless of the strength of your relationship with your manager, try being upfront with them about having sought out external opinions; then, instead of having these allies reach out to your manager directly, consider setting up a meeting with the three of you to discuss your perspectives.
Rallying your teammates
Before reaching out to upper management about your refactor, you should take the time get your teammates on the same page. Chances are, you’ve probably discussed aspects of the refactor with some of your teammates throughout prior investigatory stages (collecting metrics to characterize the problem, drafting an execution plan) to gather their feedback. For the teammates who haven’t yet gotten a glimpse of your thought process, take some time to fill them in. This doesn’t have to be anything formal: shoot them a message or ask to grab a coffee.
Your ultimate goal is to get them to vouch for the refactor either in a public setting where your manager is present (in a meeting, in a public chat, in an email), or in their own 1:1 with your manager. You may want to coordinate with your teammates so that not all of them bring it up in their 1:1s the same week; the trick is to make everyone’s interest appear organic, not prepared. Once you’ve secured sufficient backing from your teammates, you’ll have built up the bottom slice of your sandwich.
Skip-level
If your manager isn’t interested in pursuing a large-scale refactor, perhaps your manager’s manager (referred to as skip-level) will be. Upper-level management tends to have an expansive view of the organization’s objectives, as well as its current and future projects. Given this broader perspective, your skip-level might be more sympathetic than your manager to a refactor spanning a large surface area because they are better able to visualize the scope of its benefits.
Note
Some companies have strict hierarchies where going directly to your skip-level is seen as a huge faux-pas. Be mindful of how a conversation with your manager’s manager might be perceived before booking time with them. At the very least, be careful not to put down your manager during your meeting; focus on building interest and alignment in your refactor, instead.
If you have a preexisting relationship with your skip-level, and you have reason to believe that they would be supportive of your effort, schedule a meeting with them. Your initial conversation should be similar to the one you had with your manager (see “Initial Conversation”). This exchange should help you discern whether your skip-level is likely to advocate for your proposed refactor. If you determine that they aren’t a strong supporter, then you’ll want to seek the support of other influential individuals at your company to act as the top slice of bread in your alignment sandwich. If they appear supportive, however, schedule a second meeting. You can discuss the details of your execution plan, align on the resources you’ll need, and determine how they can help you get the approval of your manager.
Tip
Having a strong relationship with your skip-level can be really beneficial regardless of refactoring aspirations. In fact, I highly recommend holding quarterly (or even monthly) 1:1s with your skip-level if at all possible. Upper management can be a valuable resource if you’re looking to expand your reach as an engineer: if need to grow your skills by leading an impactful project within your part of the organization, they’ll be able to identify the right project for you; if you’re seeking mentorship, they can connect you with other senior engineers at the company. Having an established relationship with your skip-level can also help you navigate difficulties in your relationship with your direct manager, should they ever arise.
Departments
Within every company, there are typically a handful of departments that have considerable authority over the business. When their input is required, their decision is the final say, whether that’s a decision on how a new feature should be designed, a new process should operate, or a bug be resolved. In many industries, (e.g. the financial services industry, healthcare, human resources), this is the legal and compliance department. If you’ve been at your current company for several months, you likely have an inkling of which department that might be. If you’re not quite certain, ask your peers; they might have a story or two about the security department’s involvement with an incident or the sales team’s input on a new feature.
In some cases (not all), these departments might have a vested interest in your refactor. Take, for instance, the compliance team at Smart DNA, our biotechnology company from “At Work”. Above all else, the team is responsible for ensuring that the sequenced DNA of its customers remains safe at all times. Having most of the company’s systems using an outdated version of Python would likely be an area of concern for them, given that security patches can no longer be applied. If the research team at Smart DNA had not been in support of updating their Python dependencies, the software team could have reached out to the company’s compliance team and enumerated the many ways running an unsupported version of Python is a vulnerability. The compliance team would then put pressure on the necessary engineering managers to prioritize the migration, giving the software team its top slice of bread for a completed sandwich.
Tapping into influential engineers
Every company has a handful (or two) of highly-influential engineers; these engineers are a combination of extremely senior members of your technical staff (think principal and distinguished engineers), have been at the company for a significant length of time, or, in some cases, both. Many of them, if not most, are still knee-deep in the code. If they’re familiar with the surface area you want to improve, not only will they immediately understand the problems your refactor addresses, but they’ll also have valuable insights to contribute to your plan to date. Securing their support can be crucial in legitimizing your effort to manager. At some companies, there is no greater stamp of approval than that of a senior engineer. If you can garner their thumbs-up, your alignment sandwich will have a sturdy top slice.
If you’re able to rally the support of multiple upper-level influences (your skip-level, critical business departments, highly-influential engineers), then that’s even better! Your alignment sandwich doesn’t need to be perfectly balanced, leaning a little bit top-heavy only makes the approach more powerful.
Relying on Evidence
If your manager is partial to logical arguments, then you should use the evidence you gathered in Chapter 3 to bolster your position. Set up some time with your manager to continue your initial conversation. Tell them that you’ve given the refactor more thought, and that you’ve spent time characterizing the problem so they might better appreciate its value (and, hopefully, its urgency).
Ahead of your meeting, prepare your evidence. If you’ve gathered an abundance of evidence, focus on the two or three most startling pieces. Some metrics are better communicated in visual form, so consider putting together a graph or two to better illustrate the points you want to emphasize. Taking the time to synthesize this information into a medium that’s easy for your manager to consume is beneficial for a few reasons. First, it’ll give you a comprehensive document you can circulate to other interested individuals at the company. This can be useful when garnering support cross-functionally or recruiting teammates, which we’ll cover in Chapter 6. Second, you’ll have something you can reference during your meeting. For those of us who aren’t confident in their ability to persuade others, having a clear set of topic points you can reference throughout your discussion can make all the difference.
Tip
For engineers who are bit more timid and haven’t yet built the social capital necessary to lean on influential colleagues or play hardball with their manager, I recommend relying heavily on the metrics argument. Facts are easy to prepare, easy to memorize, and usually difficult to refute.
Playing Hardball
If you are exceedingly confident that your refactor is critical to the business and your manager is unwilling to budge, there are a few more severe options you can consider. Presenting these severe options is often referred to as “playing hardball.” A word of caution: either of these approaches can seriously jeopardize your relationship with your manager and fellow colleagues. When successful, however, they can be really effective, and, if your refactor proves successful (which it most definitely will be given you are reading this book), can catapult your career forward.
It’s important to note that not everyone is in a strong enough position (either in their role at their current company, or financially) to opt for play hardball with their manager and that’s ok! You need to have built up quite a bit of clout and established a long history of good performance in your current role to be able to pull this off.
One final note before we dive in: with both of these tactics, you must be willing to follow through. If your manager calls your bluff and remains unconvinced, not only does it risk eroding your relationship, it diminished your ability to successfully take a similar approach when another important project comes along.
Stop doing unrewarded maintenance work
When there is a serious need to refactor something at a large scale, it usually indicates that there is an amount of nontrivial work going on behind the scenes to keep things operational. Management is typically unaware of this work, or, if they are, they do not recognize its importance. If you are actively, regularly finding ways to mitigate the problem your refactor aims to solve, you can warn your manager that you no longer plan to do this work. The idea is to stop doing any invisible work that is preventing management at your company from seeing on the problem your refactor aims to solve.
Take our Python migration at SmartDNA, for instance. Before Python 2.7 was rolled out to all environments, whenever a security patch was was made available, your team needed to spend valuable time porting the patch to the outdated Python 2.6 systems. Given that security patches cannot be anticipated, anytime a new vulnerability was discovered, your team had to pause all feature work and divert their energy to porting the patch. This kind of maintenance work was extremely time consuming, and high-risk, but necessary given the circumstances. Unfortunately, management was unwilling to recognize this operational cost of running outdated software.
In this scenario, you could put pressure on your manager to prioritize the Python upgrade by suggesting that the team no longer port any new security patches as they become available. Tell your manager that you are trying to set appropriate boundaries for the team; given that your team is primarily focused on feature development, you can assert that supporting legacy software run by the research team is strictly not a responsibility. If during your quarterly or year planning process, your manager does not properly account for the work involved with porting a new patch on a regular basis, make a point to highlight that.
Yes, you are drawing a hard line. You might even feel guilty for no longer doing important maintenance work (which most developers believe is a critical part of their job). That’s completely normal. I’ve made this argument before and worried about being irresponsible, letting the company down. What I came to realize was that by holding my ground, I was doing just the opposite; I was showing the business where it had an important blind spot, and the significance of that blind spot. By redefining expectations with your manager, you are shedding light on the pervasiveness of the work involved to keep your systems operational without a substantial refactor.
Giving an ultimatum
If all else fails, you can suggest to your manager that if they continue to oppose the refactor, you’ll either transfer to another team or outright quit the company. If you want to stay at the same company and are able to switch teams, identify a team you are interested in joining before bringing it up with your manager; better yet, try to find a manager who is supportive of the refactor elsewhere at the company and is interested in having you join their team. If switching teams isn’t on the table, you might threaten to quit. You should thoughtfully consider this decision, and seriously examine whether you have the necessary financial stability to do so before speaking to your manager.
This is not an easy conversation to have with your manager. First, bring up that you’re concerned that the company isn’t taking the problems you’ve identified more seriously. If your manager is eager to keep you on their team, they might reassess and allow the refactor to move forward.
Buy-In Shapes the Refactor
Even though securing buy-in happens well before a single line of code is written, it can be one of the most difficult aspects of refactoring at scale. Managers can be apprehensive to kick-off a lengthy, engineering-focused endeavor with good reason; they have their own set of constraints and incentives within an engineering organization. That said, each of us has the ability to learn and master techniques to convince them that the effort is worthwhile despite any misgivings. We can discover how to effectively lean on our teammates and colleagues in the broader organization to give us the additional support we need.
After the dust has settled, depending on the degree of buy-in you’ve obtained, you may or may not be able to execute on your refactor. If your manager remains skeptical, consider shelving the project for now. You can continue to accrue supporting evidence, waiting for a more opportune moment to reintroduce the subject. For instance, if your company suffers from an incident caused by a problem your refactor seeks to solve, this might be a good time to revive your the conversation with your manager. The next time your team enters its long-term planning phase, consider proposing the refactor once more. Keep a watchful eye and an ear to the ground for any opportunities to shed new light on your refactor.
If you’ve acquired buy-in, whether that’s an enthusiastic yes or a lukewarm nod, you’ll need to leverage that support to garner resources for your project. You’ll need to determine which engineers are required to give the refactor its greatest chance of success, and at which stages their expertise will be needed. We’ll discuss everything you need to know to make these decisions in Chapter 6.