The art of persuasion: addressing technical debt with non-technical managers

We’ve all been there – pressure, project constraints, fast approaching deadlines, whatever the reason – the quickest, easiest implementation was chosen rather than the best overall solution. This results in extra development work in the future, also known as:

Technical Debt – extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution – technopedia.com

refusing-to-tackle-technical-debt

The value or benefit of the extra work is often quite clear to the developers working on the project. Chances are, they were the ones that wanted to build the best solution in the first place – project resources and timelines aren’t their concern, right? However, the benefits aren’t always clear to non-technical stakeholders or managers. Today we’ll be discussing tips for persuading non-technical managers to allow you or your team to address technical debt.

I recently attended ConFoo 2017 in Montreal where I sat in on Adam Juda’s session titled “Making the case for Refactoring to Non-Technical Managers”. I will be attempting to summarize what I learned from Adam’s session, while offering my own opinion on the subject. We’ll take a look at some less effective ways of asking, and then follow up with Adam Juda’s 4 step technique.

Asking or convincing a manager or stakeholder (especially a non-technical one) to allow you to spend time/resources addressing technical debt can be quite a daunting task. Often from their point of view, the work is already done – why would they want to spend even more money “re-doing” it. Let’s start by taking a comical look at some ways not to ask.


How not to ask

Complaining & Whining – making a mountain out of a mole hill

mountain-molehill

No one likes someone who is a chronic complainer or someone who makes a much bigger issue out of something that is in fact a much smaller issue than they perceive. Making your case for addressing technical debt by simply complaining about the status quo is bound to get you nowhere. Presenting a sound, professional argument with real metrics is a much better way to get what you want. We’ll talk more about this later in the post.

Begging – the Godfather mentality

godfather

If you haven’t watched the Godfather yet, stop what you are doing now. Go watch it. Seriously.

On a more serious note, I love this analogy. You really want to re-write that code or improve that process that’s been bugging you forever, so you get desperate and beg your project manager to let you. They might let you, but in some cases you may end up with strings attached. Now you owe them for letting you spend time on what you wanted to, even though it was most likely a benefit to the company in the first place. Why should you owe them a favor for improving a part of the business?

Hypotheticals – what ifs?

hypotheticals

So you shouldn’t complain and you shouldn’t beg, well what if you give them a hypothetical?

You: “If we don’t improve this code, production might go down!” 

Them: “If we don’t improve this code, production might stay up…”

Hypotheticals are usually ineffective in arguments, because the person on the other side of the argument can throw a contradicting hypothetical at you, and now you’re back at square one.

Being a Cowboy

mccree

Ever worked on a development team where someone thinks they are the greatest thing since sliced bread and goes ahead and pushes a bunch of work live without having anyone review it? Don’t be that person.

So your PM (or whoever) isn’t letting you address that technical debt. You think to yourself “I know, I’ll just do it secretly without them knowing”. Bad idea. When it comes time for a performance review or when it’s time to showcase what you’ve worked on, what are you going to show them? Worse – what if you push the changes live without approval and there’s a major bug. Now you’re the bad guy instead of a hero.


How to ask

So now that we’ve covered some ways not to ask let’s take a look at Adam Juda’s 4 step process that I believe to a very effective one.

1. Gather Information

Start by gathering information and metrics that you can use to build a solid case for addressing technical debt. For example: let’s say that you have a slow build process that you would like to speed up. Start pulling together some metrics such as:

  • Average cost of developer per hour
  • Time per build
  • Builds per day/Builds per year
  • Total hours spent running build process in a year
  • Estimated hours of addressing technical debt

2. Calculate the Cost

Next take some of those metrics and calculate costs for addressing the technical debt. For example, say the current build process takes 20 minutes, and you wish to improve that process so that it will run in 1 minute:

  • Hours to re-write build process = 40 hours
  • Avg Cost of Developer per Hour = $40 
  • Cost of re-writing build process: 40 hours x $40 = $1,600

3. Calculate the Benefits

Next calculate what the benefits to the organization (continuing the example from above):

  • 20 mins/build * 5 builds/day * 365 days/year = 608 hours/year
  • 1 min/build * 5 builds/day * 365 days/year = 30 hours/year
  • Yearly hours saved : 608-30 = 578 hours/year 

4. Dollarize!

Next dollarize! Everyone loves money, so represent your findings in a way that will really sell your case:

  • Old build process: 608 hours/year * $40/hour = $24,320
  • New build process: 30 hours/year * $40/hour = $1,200
  • Total cost saved per year =  $23,120 (after $1,600 investment)

I bet if you tell your PM/boss/whoever that you can save them $23,000 a year by only spending $1,600, you’ll have their attention. This is a much more effective way to make your case for refactoring or addressing technical debt than the ones discussed earlier in this post.


Wrapping Up

Next time you want to address technical debt and have to persuade a non-technical stakeholder, remember to not:

  • Complain/Whine
  • Beg
  • Use Hypotheticals
  • Be a Cowboy

Instead follow the 4 steps to building a sound, persuasive and enticing argument:

  1. Gather Information
  2. Calculate the Cost
  3. Calculate the Benefits
  4. Dollarize

Thanks for reading!

Image Sources:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s