When I first began to lead tech teams at the turn of the century, I attempted to unify them against the “suits”. I’d describe myself as going in to battle for them against unreasonable deadlines and silly demands coming from “upstairs”, where the business leaders who paid our salaries and consulting fees lived. I painted us as merry rebels fighting for “best practises” like pairing and unit-testing, opposed senselessly by bean-counters who couldn’t understand our special tech wizardry. It was us the techies and them the business.

As with most unilateral actions, this “worked” in the short term. It created cameraderie and common purpose and reinforced the norms I wanted to see in my engineers—pride in their work and a willingness to experiment and improve. But I fell foul of the usual consequence of aiming to win: I missed out on valuable information that I could have used to deliver better and build relationships with the very “suits” I was railing against.

The experience of an early client of mine illustrates the pitfalls and opportunities well. Like my own tech team, this CTO’s engineers had dismissed a demand from marketing as “absurd” and were ignoring the seemingly arbitrary 4th March deadline. “There’s no way the API will be ready by then,” they said. “We have to do load testing, authentication, rate limiting, and much more. Marketing will just have to wait.”

The CTO was ready to tell “the business” where to stick it, but I read him the riot act. “Go see marketing and understand their point of view first,” I said. Quoting Chesterton, I told him that before dismissing the target, he had to find out why they needed the API so soon.

When I saw him again, the CTO had learned a lot. First, that the deadline wasn’t arbitrary; the company was holding a conference on 4 March with 200 guests from current and prospective clients. The room was booked and the balloons were ordered, so it couldn’t be moved back due to a tech delay. But even more importantly, “delivery” meant something very different to the conference organisers than it did to the engineers. Yes, they had to have something done for the conference—but it only had to be a demonstration on stage of the new features. Robustness, validation, error handling, and all the other bits needed for a production-ready system could wait. “We can deliver that tomorrow,” he said, smiling, and they did.

So the next time you’re tempted to dismiss some group of “them”, try asking for their point of view first. It costs nothing and just may open up new possibilities.