Article summary
At Atomic, we pride ourselves on not just engineering the right code for a client, but on actively helping them shape their software to be the best possible solution for whatever problem they want to solve.
There’s a huge feeling of satisfaction that comes with the ability to own a product like that, but also a large amount of responsibility. Caring about whether or not a piece of software is solving the right problems (on top of being engineered the right way) introduces a whole new set of potential issues—the kind of issues that you can’t bash out at a command line.
Every now and then, I get linked to this comedy sketch on what it’s like to be “The Expert” engineer tasked with creating a solution for an unreasonable spec*. Luckily, I’ve never been in a situation that dire, but there have been times when a client has asked or pushed for a course of action that I don’t believe is the best path to take in developing the product. If my job were limited to coding to a spec, I would quietly let these instances pass, but caring about the quality of the product itself requires more action on my part.
Whenever I find myself in a situation where I need to confront a client, I lean on a few basic steps.
0: Remember that non-verbal communication counts.
Human psychology is easily biased, unfortunately. What I say is important, but what I look like and how I’m acting nonverbally can have a huge impact on the way my words are interpreted. I always try to present myself cleanly, if plainly—luckily, software engineers are well known for their hoodies, so I don’t lose professional respect by wearing jeans. Posture matters, as does voice. The most brilliant treatise won’t matter if I mumble it into the collar of my shirt. It’s to my benefit to stand and speak confidently and openly.
1: Ask clarifying questions to understand the client’s reasoning.
If a client is asking us to add a questionable feature to a product, what are they hoping to achieve? Why do they think that it’s important? Is their proposed technical solution inspired by the Hot New Thing they read about on Medium a few days ago, and now they want to emulate it to make sure their software is up to date? Are they asking for a solution in Framework X because their entire I.T. department is already fluent in it and they don’t want to risk a new technology?
Most of the time, an earnest attempt to empathize with why they’re asking for X will solve the entire “problem” right there. Client decisions that initially seem like bad calls are often proven to be entirely understandable and even optimal when given some additional context. At that point, I’m usually happy to get on board with whatever was originally suggested by the client and start working.
And even if I still conclude that their idea is a non-starter, at least I can understand the problem they’re trying to solve.
2: Brainstorm a reasonable alternative.
Suppose that I still disagree with the client’s suggestion. Now that I know why they want what they want, I’m in a position to figure out an alternative course of action that achieves the same goal. The details can vary widely depending on the situation, but if the request is a bizarre form of yak shaving, there’s usually a more direct, if non-obvious, approach to tackle the same root problem. If the request is for a cool but extremely expensive feature, there’s generally a way we can scale it back to make it cheaper to implement.
3. Explain why you disagree with their plan, and what you advise to help them succeed.
This is where things are most precarious. Here’s how I tend to go about it:
- Support and empathize with them. Restate their motivations for this request in your own words. If necessary, restate how you’re committed to the success of their product.
- Concisely explain your concerns with their proposed course of action. Chances are, if it’s a difficult technical problem, they have no idea how expensive their request really is to implement. “In my professional opinion” is a useful phrase to use here.
- Suggest an alternative, show how it solves the same problem, and point out that it doesn’t have the issues of solution A.
- Listen.
Usually, clients are happy to go with my alternative at this point—it’s very rare that they’re dead-set on a particular way of solving a problem vs. the act of solving the problem itself.
There have been times when the client picks up on problems with my alternative solution. Sometimes, my suggestion can be tweaked to handle their concerns, and sometimes, there really is no feasible alternative to what they’re asking for. Occasionally, my concerns with their suggested plan turn out to be invalid. That’s why it’s so important to listen to them and make sure that I understand the situation entirely.
4. If they still want to go with Plan A, commit to it.
In the end, it’s their software and their decision to make. The best I can do is offer my professional advice and clearly lay out concerns before agreeing to do the work. Once they’ve made a final decision, there’s not much I can do but do my best to make it work.
* This brilliant rejoinder actually demonstrates a solution to the absurd technical requirements of the original sketch, proving once again that both human ingenuity and snarkiness are without limit.