How Developers Can Improve Our Craft By Listening To Non-Technical People
Developers are notoriously stubborn. Why do we struggle to take advice from non-technical people? Can listening prod us to sharpen our skills and deliver superior experience? I think so.
Frequently, we technical people field requests or suggestions that seem impractical, hugely complicated or even impossible. I’m sure you’ve had conversations like the following:
Developer: “No. Their API doesn’t support that.”
Client: “Well our competitor is doing it. It must be possible.”
Developer: “No. The framework won’t support that.”
Colleague: “But couldn’t those choices be saved along with the other user settings?”
Developer: “No. You don’t know what you are suggesting. We have to run those tests.”
Project Manager: “Could we audit our tests to see if they are all really necessary?”
Developer: “No. The uploaded data conforms to the spec that we require.”
Project Manager: “Could we somehow map the 3rd party data to the spec?”
In situations like these, we know what to do. We simply tell the other side that it can’t be done. It won’t work. They have no idea what they are asking for.
After all, the people on the other side have never written a line of code in their lives! They have never configured a server. They have never designed a network. They don’t know the first thing about this stuff. How naive! Honestly, how rude.
I’m being facetious, of course.
The eye-rolling, the sighs and the disdain that follow receiving technical advice from non-technical people usually result in self-fulfilling prophecies. Those ideas are never considered, never tried, and so are validated as inappropriate and out of place.
Six reasons developers struggle to take technical advice from non-technical people.
1. We prefer fast. It’s not that we’re afraid of work. It’s that we prefer to complete the project in an efficient timeframe. Considering new ideas requires research and time—luxuries we prefer to spend on other areas of the build we deem more appropriate to achieving the site’s goals.
2. We’re insecure. Our egos can feel especially threatened when we feel put on the spot in our area of expertise. Often times, the real answer to the technical advice from a non-technical person is, “I’m not sure how to do that.” That’s a hard pill to swallow if we are trying to maintain an air of infallibility.
3. We don’t know how to communicate it. Strange as it is, if you have an intuitive personality, it’s often hard to articulate exactly why you think something will or will not work. Your intuition usually leads you to the correct solution, but that doesn’t mean you can explain it!
Once, my boss asked me to explain how a system I was planning would accomplish a difficult task. I was sure it would work. I could sense all those pieces would fit together perfectly! But what I said (in a tone that I’m pretty sure sounded condescending) was, “uuuhhh.. because technology.” I’m still trying to live that one down.
4. We’re protecting our turf. If we let non-technical people get involved this time, what’s to stop them from nosing around in our work whenever they feel like it? We can feel especially threatened if that non-tech person is above us on the org chart. We have worked so hard on these systems! It’s horrifying to think of someone overruling us and messing up our work just because they can. Better to keep them off our lawn than risk future meddling.
5. We definitely like machines. We’re less sure about people. Frankly, for many of us, we’re just not interested in team work. Unless that team is a cluster Docker containers.
6. Some of their tech advice has been really, really bad in the past. Oh yeah. There’s that. They really don’t know much about building tech and sometimes it shows.
We improve by listening. We stagnate by saying “no.”
Why think that these non-tech have nothing to offer us? You know, many of them are quite smart. Some of those people above you on the org chart are really smart. Often, that’s exactly how they got there. It’s a good thing when a smart person tries to help you with your job, not a bad thing!
But what you should really appreciate about non-technical people is that they solve different classes of problems than we do. All day, every (work) day, these people are coming up with creative solutions to problems very different than ours. And often, that’s exactly what we need.
The history of science is replete with examples of outsiders and non-specialists creating breakthroughs that would have remained otherwise unknown. Watson and Crick relied on their own complementary training to discover the double helix, but never could have made crucial breakthroughs without the help of outsiders. The microwave was invented by a World War II radar engineer. The Wright Brothers had no formal training when they invented flight.
Embrace the challenge to evolve.
Sure, non-technical people may make poor suggestions. They aren’t aware of the limitations, logic, or man-hours required for their request. Yes, not listening to their requests may result in a faster project timeline. And, sure, explaining our “no’s” to non-technical people is hard.
But, believe it not, some technical suggestions from your non-technical colleagues might be good. In fact, they might be exactly right. And if you aren’t listening, you’ll miss the chance to grow and improve your craft.
So the next time someone from the outside offers a suggestion or presents a challenge, refuse to write it off. Consider their point of view. Understand what they are trying to accomplish. And ask yourself the question, “What if we could do this?”
You may just find your next big breakthrough happens when you listen to suggestions from someone well outside your paradigm.
