Sooner or later someone will ask you to do something you disagree with. Maybe it will lead to horrible performance, require excessive effort, or simply not solve the problem at hand. Sometimes we need to say no, but we need to say it well. It’s not easy, but you can turn an adversarial situation into a collaborative one.

Story Time

Early in my career as a not very good developer, I had an embarrassing, but formative project. I was told we needed to query data out of a database run by an organization we were working with. I lept through a dozen flaming hoops to work with this department. It took nearly a year to get official authorization, VPN access, a special rule in the firewall, and a custom access role. Almost a year of meetings and Visio diagrams with literal walls on fire protecting their data from a cloud representing the internet. It never occurred to me or anyone I worked with to question our approach.

A year later or so, I was presented with another project in collaboration with this same organization. I was not hopeful. It was a slightly different department, but in the same general division, and I was prepared for the worst. If I wanted to get the project done by the end of the year, I would have to start the whole process over again.

I navigated the organizational hierarchy until I reached this department’s “Technical Person”. He asked me one question: What was I going to use the data for? In the previous project nobody ever asked this. Nobody had questioned our approach before, nobody pushed back with alternatives.

I told him what we were researching, and he told me there was a better option. He would set up a nightly job to upload the data I needed to an FTP server. The next morning I had my data. We finished the project in days instead of months because someone listened to my request, asked questions, and then presented alternatives. That man is one of my personal tech heros, and sadly I don’t even know his name.

In this exchange, I was the villain. I was the idiot with the horrible plan. I wasn’t a terrible person, I just didn’t know better. We should strive to prevent these accidental atrocities by constructively saying no.

Clarify

Before all else, get some perspective. This holds true for seemingly good and bad ideas alike. Before considering the technical problems, determine what problem this is meant to solve. Understand the deeper issue, and you’ll be able to help the person asking get the solution they need, which may not be the solution they are asking for. I needed data, not a database, but I missed the bigger picture.

Probe the requirements. They are not all equally important. Offhand statements or suggestions may appear to be strictures engraved in stone. I should have questioned why we needed a direct connection to the database. Luckily someone else questioned me. Connecting to port 1433 was a possible implementation detail, not a requirement.

Present Concerns

I already knew the issues involved with my request because I’d been down that road before. Most of the time though, people asking us to do horrible things don’t see the flaws. We need to help them build a better mental model of the issues with their request. Remember that most people outside your team don’t know your database schema, asset pipeline, or server capacity. That’s OK, we all need to specialize to some extent, and their specialty is in another domain.

Enumerate problems that the person may not be aware of. What factors make the request infeasible. For instance, many seemingly simple changes require more work to implement than one would expect. If the person asking isn’t aware of the cost, they will likely be disappointed later. There is a difference though between raising issues and complaining. Raising issues is about illuminating problems the other person is unlikely to see, complaining is just telling them how much it’s going to suck. Complaining can feel pretty good, but it isn’t particularly productive.

Present Alternatives

If you’re going to say no, have options where you can say yes. This is how you make no constructive. If the “Technical Guy” I called with had just said no to me and ended it there, I would have called someone else. Instead he gave me an alternative that was both easier and more expedient for both of us.

When giving alternatives, be clear about the tradeoffs. Running a nightly script got me results more quickly, but if I didn’t download the data in time, it would get deleted. In the end, I was more than willing to accept that tradeoff. By presenting options with tradeoffs you elevate the discussion, and no longer look like a lazy developer, but collaborator.

Providing alternatives with tradeoffs also helps the other person brainstorm new ideas as well. The best solution often won’t be any of the alternatives you provide, but a compromise between many alternatives.

Get to Work

Things won’t always go your way. Even when presented a vastly better solution, sometimes the other person won’t budge. A stalemate is never a good outcome. Agree to disagree. It’s tough, but sometimes it’s the only way forward. There will be other opportunities, and being gracious can buy a lot of good will.