Talking tech to the business guy

Every development project has a business guy attached, who holds the project money and makes the decisions what the team should implement. That guy can be your customer, sales manager, product manager, the product owner in a scrum project or simply your boss. In this article we will conveniently call him “manager”. Constant small refactoring, test coverage and other technical things that you do while developing features don’t really concern him. But from time to time you have a big, technical issue, that does not have apparent business value and does not add any features. You see it as absolutely necessary but you need the time and approval from your manager to do it. Watch this conversation between a developer and the well known “pointy haired boss”, that I stole from a stackexchange.com post and that seems awkwardly familiar to every developer:

Developer: We need time to do this technical redesign.
PHB: Why?
Developer: It’ll make things easier to fix
PHB: So what?
Developer: It’ll increase throughput – we’ll get new builds out the door quicker?
PHB: So what?
Developer: Err…Happier customers?
PHB: WTF?
Developer: I mean increased recommendations, greater satisfaction, more profit sooner due to low turnaround.
PHB: Oh! Sounds nice. But it only “sounds” nice can I see it?
Developer: WTF?
PHB: Show me some numbers!

…. and so on…

The problem is that the manager often can not see the benefits of technical necessities like refactorings, redesign, establishing test coverage. How could he? He probably never learned their importance and the consequences when you omit them. The guy who knows better and who’s job it is to convince the manager is you! Let’s talk about some aspects that will help you do this.

1. Trust

Some of you will be surprised but in my opinion the most important factor in this matter is that your manager trusts you! If he knows you well and has the feeling that you want the best for him and the project then there is a chance that the conversation takes this path:

Developer: We need time to do this technical redesign.
PHB: Well, it is not particularly cheap but you are the expert and your advice has always been valuable, let’s do it!

It doesn’t get any easier than that! The way to achieve this trust is to always be honest and straightforward and talk openly. Don’t try to trick your manager into approving something by leaving out facts or by faking estimations. Transparency is key in the relationship between manager and developer. If you earn your trust, a good, non-sociopathic manager will reward you with more freedom. The less your manager trusts you the more trouble you will have convincing him of a technical necessity.

2. Technical affinity of the manager

Try to figure out the technical affinity and experience of your manager. This will decide what kind of arguments will help your case. If he has a lot of technical experience, maybe even is a former developer himself, then chances are high that you are able to convince him by technical reasoning. The conversation might go like this:

Developer: Before we implement any new functionality we need to write tests for this legacy code first.
PHB: Why is that? We never had any tests back in the nineties when developing software while listening to MC Hammer?
Developer: Yeah, but remember that it was difficult to change anything without breaking another thing? Nowadays you write automated unit tests so you can always make sure that changes to the code don’t introduce unwanted side effects into the software.
PHB: Oh yeah, that always bothered me. And unit tests sound like a good way to fix that problem. Let’s write some tests first!

Points like “only tested code is easy to change without side effects” or “refactoring and redesign are necessary in an agile process to adapt to the requirements” or even “no one writes code perfectly the first time” are likely to convince a tech-savvy manager. But they won’t help with a manager, who doesn’t have any technical knowledge at all. If you are unlucky they confuse him even more and drive him away from the decision you want him to make.

3. Find a leverage that the manager understands

If you sense that the manager won’t understand what you are talking about, don’t blame him. He probably has his qualities elsewhere. Maybe you still can find a way to make your point. Most business guys think in buzzwords like time, budget, quality. Get to know your manager’s favourite buzzword and try to tell him how your proposition helps this particular priority.

Developer: We need time to do this technical redesign.

Time-PHB: Why?
Developer: Because after that we can introduce new features into the software way faster!

Budget-PHB: I don’t see the real benefit.
Developer: Well, the code will be easier to handle so we will need less resources to make changes. Even new developers will be able to understand and expand the code without training.

Quality-PHB: Meh, I still don’t see it!
Developer: But the refactored code will also be more robust to side effects so we will be able to introduce changes without fear of bugs.

Time-PHB, Budget-PHB, Quality-PHB unisonous: THAT IS THE BEST THING EVER, WHY HAVEN’T WE ALREADY DONE THIS?

Also helpful are analogies to something that the manager knows. As an example one of the most famous analogies is to refer to undone technical necessities by the phrase “technical debt”. If you explain to the manager that like real debt it is growing all the time and has to be paid back with interest then maybe he will understand the consequences.

4. Business case

If the manager is too cautious and insists on numbers like in our first conversation with the PHB then it might be best to give them to him. Try to make an estimation on how much the development will be accelerated or on how much the quality will improve and put it into numbers to present to him as business case. You know quite well that the numbers will be highly imprecise and probably won’t come true exactly as estimated but the business case will help your manager to see the benefits. You just have to clarify that the numbers are what they are – rough estimations. That way the manager can make a more informed decision and no one can really blame you afterwards when the effects don’t meet the estimations.

5. Play the expert card

In a typical developer-manager-relationship you are not only the guy who codes but also a consultant. You are the technical expert and are entitled to advise your manager. Don’t be afraid to do that! Often it helps to say something in the lines of “as your technical expert I strongly recommend to…” because it reminds the manager that you are the one who knows how to develop software. But keep in mind that you always have to back your recommendation with valid points and reasons! Playing the expert card and then lacking the arguments to explain your reasons is just a cheap bluff.

6. PDD – Pain driven development

You really exerted yourself and tried everything to make your point. But everything fails. The manager ignores your advice and insists on doing it his way. At some point it is best not to stress the matter any further and just leave it. You know it will cause pain but sometimes pain is good. You will have the opportunity to use it for your argumentation next time.

“If we had any test coverage, half of the reported bugs would not have occured”.
“We have to make estimations that high, because it is difficult to implement new features in that part of the software without the big redesign we didn’t do three months ago”.

Just try not to make your manager look bad for his decisions. Blame improves nothing and your further cooperation will be much more comfortable if you maintain a good relationship.

7. Understand the other side

You should never forget that the manager might have good reason to reject your proposition. He has to make the project profitable and he gains nothing if you do technical changes just because you think they are cool. Always reflect on yourself and try to figure out if your proposition really helps the project or if it is just something that sounded cool in some blog post *cough*.

Wrapping up

That’s it, I hope this list will help you communicating your desires to your manager.

One last important piece of advice: To a certain degree technical issues are something your manager doesn’t have to know about at all and doesn’t even want to know about. You are the software craftsman and often you know best what is the right choice for your project. Things like constant refactoring and maintaining test coverage are natural parts of the software development process and you have to do them to deliver a good product, you don’t have to ask for permission to do them.

It’s the same as with every other craftsmanship. You also don’t ask your plumber how he installs your bathtub, you only care that he installs it at all and you know it takes the time it takes. And if it doesn’t start to leak at any time you will never question that he did a good job.

Some Links:
stackoverflow.com thread on explaining refactoring to non-tech guys
explaining refactoring to management