It’s hard to sponsor change in an engineering organization. Even if you’re lucky enough to work in an engineering environment where the culture, technical momentum, and company priorities allow for change, you still have to address the most difficult challenge of all: convincing people. The hard skills required to implement the change and the soft skills necessary to get buy-in are two entirely different skill sets with little overlap, often the latter being more difficult than the former.

Seldom will an engineer be in a position to make drastic technical changes to their organization’s existing tech stack. Migrating an existing datastore from SQL to NoSQL, for example, is not a change the typical engineer will find the need to sponsor. Or when they do feel the need to sponsor such a change, the amount of effort it would take to execute it would weigh so heavily on the engineer’s mind, that they would only come around to sponsorship when the benefits of such a change drastically outweigh the effort, making the sponsorship, if not easier, at least more straightforward.

More frequently we find ourselves sponsoring small, iterative improvements. Ironically, the smaller the difference between two solutions, the greater the debate between them typically is. The irony, of course, is that the more similar the solutions are, the less likely it is to matter which one you choose anyway. You can imagine the relationship looking something like this very scientific graph:

deciding_between_two_options

Such debate is to be expected. We are members of a minutiae-loving group. More than others, software engineers are prone to dissect and inspect before we select.

But we are also a proud bunch, and sometimes that plays a larger role in our decisions than technical merit alone. In other words, debating between two options whose differences are very slim provides an objector with an opportunity to showcase any niche knowledge they might have, which makes the objector feel and sound smart. (As a know-it-all in recovery, trust me.)

Combine this self-serving dynamic with any of the others that are bound to be involved when deciding in a group — imposter syndrome, people pleasing, mansplaining and other manifestations of sexism — and all of a sudden the small technical change on the table is overshadowed by all sorts of interpersonal friction, making the change seem more cumbersome or dangerous than it truly is.

I’m still learning the best way to sponsor such changes, but I’ve collected a few principles that I’ve found to be helpful when dealing with the soft skills of sponsoring small changes.

Consider Your Audience #

What’s the smallest group of people you need to discuss this with?

Overcome the temptation to discuss your proposed change with every developer who might ever come across it. This temptation is generally bourne of good intentions: you want to be considerate of other developers’s workflows and don’t want to catch anybody by surprise. Instead, find the smallest group of people — that might be as small as just the one other developer who works regularly and intimately with the affected code or technology — and talk with them instead. I’ve found that more often than not developers tangentially affected by changes don’t have strong opinions one way or the other.

Take a Pulse #

Remove ulterior motives by bluntly asking how much people care.

When you do find your audience, ask bluntly: do you care at all if I do this? Sometimes the answer is yes, and then you can go into whatever arguments in favor you have prepared. Often enough, for small changes, if you’ve found the right audience, their answer will be: let’s give it a shot. At the very least this gives you an opportunity to frame your audience’s concerns: do they feel strongly or are they just playing devil’s advocate?

Consider Reversibility #

The more easily undone a change can be, the more likely you should just implement it.

The above two principles should hinge heavily on how reversible the decision is. On the end of completely reversible, you can put your cowboy code hat on and generally get away with just shipping it with a little bit of heads up and a notice that it doesn’t have to stick around if people hate it. On the end of permanent or nearly-permanent, you’ll probably have to broaden your audience and assume there will be more discussion.

If your change is highly reversible, tout that over and over to your audience. You can debate endlessly but nothing compares to giving the change a low-risk test drive.

Read the Room #

During and after the discussion, assess the sentiment towards your change.

In any debate, you reach the “what’s next?” lull in the discussion. At this point, you should ask yourself the following questions:

  • How many people are passionate about this? Is one person passionate but nobody else cares?
  • Does everybody feel strongly one way or the other, or is the whole group lukewarm?
  • Is the person who feels passionately against your change the CTO or the intern?
  • Do more people feel one way over the other?
  • Who spoke the most during the meeting? Who was the loudest? Sometimes what feels like a big opposition could just be one or two passionate individuals.
  • Are there stakeholders who might have strong opinions or deep insights who didn’t speak in the meeting for one reason or another?
  • Were any objections raised that exposed flaws in your technical reasoning for sponsoring the change that would make you want to take a second look at the mechanical details before making a decision?
  • Does the passion behind any objections stem from sound logic or is it more anecdotal? eg “This gem is prone to memory leaks” vs “I used this gem at my last place and I hated it”. (note: anecdotal objections have their value too)

Own It #

Don’t wait for somebody else to make the decision.

Generally after considering all these things, you should be left with an overall feel of how the change is being received. This leaves you with a few options:

  • Move on. Maybe the tech isn’t the right fit, the opposition was too strong, or the right people opposed it. Record why you decided against the change and move on. This is a sign of emotional and social intelligence, and kudos to you for trying to make something better.

  • Move forward. If you’re able to resolve objections in the meeting and the mood is generally positive, thank everybody for the discussion and move forward. If there was some moderate opposition, but you still feel strongly that the change is positive, communicate that you are going to move forward with the change but will circle back in a month with those who were opposed to see how things are going. (This is easier if the change is more reversible).

  • Go Offline. Is there one person who feels strongly who you could have a 1:1 chat with? Are there others in the group who you think would have insights who might feel more comfortable sharing in private? Or maybe you need to double down on your technical research or create a Proof of Concept. In any of these cases, communicate clearly what your next intentions are, where you hope they will lead you, and, importantly, by when. An example:

    OK Tim, I can tell you have a lot of reservations about this and others don’t seem to feel strongly. I’ll schedule some time to learn about your thoughts and then report back in #developers on slack by Thursday what I’ve decided to do.

 

As you end the meeting with one of these options, there are a few antipatterns that you should try to avoid:

  • Using “we” instead of “I”. This generally comes from a place of wanting to sound like a team player, but it waters down the initiative and comes across as refusing to accept accountability for the results of the change. If you’re worried about sounding domineering or self-important, pair the two together: “We had a great discussion, and after working through some reservations with Tim, I’ve decided to move forward.”
  • Waiting for somebody to give you the green light. It can be tempting to wait for somebody else, typically a technical leader or super-staff engineer to clearly say: “ship it!”. Don’t do that. This is your sponsorship, and you are responsible for the change as well as the results.
  • Making everybody happy. Similarly, sometimes you want everybody — literally every single person — to give a thumbs-up before moving forward. This is unlikely. Hopefully, you work in a professional environment of mutual trust, and so even if somebody disagrees with you, they shouldn’t take it personally if you decide to move forward. Don’t become too paralyzed by overcoming every last objection that you don’t move forward with a change that most people (or the right people) will benefit from.
  • Not giving a clear path or timeframe. If the mood was lukewarm or there was enough objection to obscure a clear path forward, avoid the unsatisfying meeting-ender of declaring you’ll “circle back.” Instead, give a specific date, or at least a timeframe of when the next actions will be taken and follow-up.

Adeptly sponsoring a technical change — even if you decide not to implement it! — can have big implications for your personal brand and clout at work. Handling, and more importantly, ending, a technical discussion well gives you an air of ownership, intelligence, and trust.

But of course, be patient with yourself. This is more of an art than a science, and there aren’t compiler errors to guide you along the way. Have fun with it! Enjoy the opportunity of interacting with your co-workers with their varied life experiences and backgrounds. Good luck!