How Can I Convince ...

The City of Arts and Sciences in Valencia - Santiago Calatrava

From time to time, a developer asks me "How can I convince my team/manager/organization to ..." - and after a brief discussion with followup questions, I often answer "you can't convince them".

Let's let that sink in.

There are many reasons why convincing someone that your awesome idea is worth pusuing is harder that you might think. It often has less to do with your idea, or your presentation, and more to do with how the folks around you are motivated and measured.

Let's let that sink in too.

There are a few basic truths about why it's hard to implement change that have almost nothing to do with the quality or substance of the idea - so let's dive in.

We Don't Have the Budget - Finance 101

Everything, I mean everything in most companies has to pass through the finance department one way or another. Whether it's the building where your desk and computer live, or the process for getting prototypes made, or how manufacturing partners are selected - finance has a huge influence on how or even whether something gets done.

One of the most important metrics as to how well a company is doing is the Earnings Before Interest and Taxes (EBIT). In very basic terms it represents the difference between sales and the direct cost of producing whatever it is you are selling - not including other costs of doing business such as interest on debt and taxes owed to the government.

If you really want to dive in - here is a Wikipedia article on EBIT.

How does this affect your big idea? First, if it costs money to implement your idea, then it has to come from someone's budget. This increases cost of goods sold, and therefore decreases EBIT. Any money spent on your idea is money they don't have for anyone else's idea. Most likely the person who owns the budget for your idea is measured on how much money they saved (or didn't spend) over the fiscal year. So nobody's great idea is going to get funded, unless it's from someone higher up the food chain.

On the other hand, if they don't spend all the money they asked for at the beginning of the budget cycle, they probably won't get as much for the next budget cycle. That explains why the end of the fiscal year is a mad scramble to buy equipment and consulting contracts to burn up the budget.

You aren't going to get in front of a finance person to pitch your idea, and your manager or their boss is probably not going to ask for it either. Especially if it's in the middle of the year.

Long story short, if your company has an annual budget cycle, wait until that starts before pitching your idea to your manager. And don't do that until you have the next sections covered.

We Need To Standardize Ways of Working

If you are doing complex work in a medium to large company, then there will be a development process - usually some variant of a stage-gate model that is essentially a big waterfall.

If your company is following their internal development process, and it strikes a nice balance that allows for rapid deployment with just enough oversight, and engineers are given some freedom to experiment and learn, then you are in a thriving developer culture.

You are probably not reading this article.

Most of you will be working in orgs that have spent a LOT of time selecting tools, creating artifacts, and locking down the technology development process to the point where making changes requires so much buy-in that it's almost impossible to change anything.

No matter how awesome your idea is, or how much money it will save, or how many escapes it can prevent - your biggest impediment is your organization's (in)ability to take in process change. In fact, even experimenting with process change can be difficult - not because the idea is bad, but because of the work required to effect a change if it's good!

If this sounds crazy, it can get even worse. Your small idea can't get traction but you know what will? A big, sweeping change brought in by a new executive eager to make their mark on the organization. They have the ear of finance, and they can fix whatever the reason was for the last late and over budget delivery. They will revamp the development process and bring in consultants to develop and deliver the get-well plan. The plan that will once and for all give them the ability to deliver on time, on budget, with no mistakes. This time we are going to do it right. Right?

Your little idea for an experiment can't possibly have the impact of a a much bigger change of process, or the cost savings if we all use the same process and tools. Well, at least not on paper. Building a culture of small experiments and implementing what makes sense based on lessons learned is much more likely to work and be sustained.

We Tried That Before - It Didn't Work

This one is a little harder to break down, partly because it's true - your team may have tried something like your idea before and it didn't work. The usual suspects like Agile, Test Driven Development, Pair Programming, CI/CD, Rapid Prototyping, and many others are often part of The Big Sweeping Change from the previous section.

Big sweeping change often comes with a fire and forget mentality. We had consultants come in, we gave key people Scrum Master training, and we did Agile for a few sprints and nothing really changed. Or we implemented pair programming, required developers to sit together and share a keyboard and the personality conflicts became unmanageable after a month.

The "we tried that before" problem is one of the most difficult to overcome because your manager and coworkers will have a pretty bad taste in their mouth from the last time the idea was forced on them.

The fact is, real change is rarely a step change.

Sure, you can get a faster computer and cut your compile time. You can't magically change the quality of your code, or your ability to innovate, or the happiness of engineering teams with a one-shot training session.

Real change takes time - and it takes making mistakes, and learning from them.

What, So What, Now What?

You have an idea, and you believe it can help to change something for the better.

Great.

What's working against you is your organization's unwillingness to spend money, their inability to change baked-in processes, and their low tolerance of mistakes - even ones that provide valuable lessons.

Hopefully you are getting the picture that your idea is going to have to overcome some serious headwinds to be put forward by anyone but you. Acknowledge that someone has to stick their neck out for your idea, and why they might not be ready to spend their goodwill capital on you.

What I'm going to say next might be disappointing to some, but it has started to work for me. It is simply this:

  • Be Patient

  • Do Good Work

  • Respect the Past

  • Show Initiative

  • Be curious

Knowing that new ideas take time to really get a foothold can make it easier to handle the slow pace of change. Remember the Big Sweeping Change, and how the results didn't match expectations? Take a slow approach with your idea. Don't expect your team or your manager to have a light bulb go on in their head and embrace the change. It will take time for them to learn, to understand, and to accept that they might have been doing things the hard way for years.

Doing good work means just what it says - be as excellent as you can be even if the tools and processes you have to work with are holding you back from being awesome. Guess whose ideas for improvement aren't going to be taken seriously? The person who is careless with their output or doesn't follow the existing process. It's not pretty, but sometimes you have to build credibility by just getting stuff done.

Respecting the past is super important when advocating for change. Always have the mindset that your manager/team/organization did the best it could with the information at hand, under the operating conditions at the time. The means that when we ask for change, we also ask about history, and we have the grace to understand when change is too hard to do right now.

Im conflicted about the last one, which is showing initiative. I don't mean that you should show up early and leave late, and do the work of two people to get ahead. That's not a recipe for long term success. What I mean is that you might take some time during the week to pursue your idea further, or to make a demo, or to duplicate your assigned work using your idea for improvement. Just as change is a slow process, your idea needs time to mature and develop. Take the time to develop your idea as far as possible before expecting others to just take your word for it.

Become the person that is interested in how others approach their problems, learn new ways of doing something, and be generally curious and optimistic if you can. Your co-workers will most likely reach out for help if they need it. Try to model a positive approach to problem solving and ask others if they would like to spar when you have a problem you can't solve elegantly.

TL;DR

Before you ask yourself "How can I convince ..." - consider asking yourself "How can I find out why ...?", and be patient while accomplishing that goal.

Given the factors that make it hard to bring new ideas forward, it's more likely to be successful if the organization you are trying to change is at least curious and open to experimentation. Figure out that before trying to convince anyone that your idea is worth pursuing.

Break your idea into small chunks and smuggle it into the organization by using the pieces to do good work. Slowly but surely you will bring others on board and your efforts will bring about change. Slow, sustainable, positive change.