How to Pick Your Battles on a Software Team

As with picking any battle, you need to decide if the effort is worth the reward. If there are only marginal gains to be made from making a substantial effort, then is it worth proceeding? Of course, determining the effort and the reward may be subjective.

What I mean by battles is where you become embroiled in a war of words or a bitter feud with your manager and / or a customer. This may escalate to the point where one or both of you you decide to part company. This can often lead to ill feeling if either party feel their voice has not been heard.

For example, suppose you are asked to make a change on behalf of a customer, and after careful consideration you conclude that making the change may lead (directly or indirectly) to a negative impact on the product. This then upsets or angers the customer who tells your manager that they are a paying customer and you should make the change. You reply back that they are not the only paying customer, and you have to consider the many other customers who are also using the product and who are not affected by the issue.

This leads to a battle between yourself (the technical authority with the most intimate knowledge of the impact of the problem), the customer (who wants their issue fixed as they are a paying customer who can go elsewhere if you don't comply) and your manager (who is trying to find some compromise that will please everyone).

I think every developer has been pitched into such a battle at some point or other. Possibly several times. I remember working for one particular IT Director (who shall remain nameless) who overrode the entire development team, including the IT Manager, and sided squarely with the customer. This created an Us vs Them situation that created much hostility, and led to several of the team leaving as it was clear that the upper management didn't have the backs of any of the team.

Treading the fine line between making adjustments to the code to keep a customer happy, and trying not to introduce any bugs for all your other customers, is never easy.

Performance gains that could be made following a code review may be important to only some of your bigger customers, but then again it's precisely

those bigger customers that keep the business afloat. This is where experience and good common business sense come into play. These are not trivial decisions to be taken lightly, and careful consideration and appreciation of both the technical and business trade-offs is important.

There are no rules of thumb for these situations. You certainly can't keep everyone happy, but at the very least you need to be transparent in your actions and communication to all those involved. You don't want a mutiny from the development team any more than you want a disgruntled customer.