Man vs. Machine: A Developer’s Take on Making the Technical Relatable

There comes a time in the software development process that as a developer I need to explain my technical work to a non-technical fellow man. I’m purposefully using the term “fellow man” because at times, the exchange can truly feel like a dichotomy of man vs. machine. To illustrate, as a developer I need to communicate with my computer through programming languages, while also translating the expected behaviors of my strings of code into features and fixes that my colleagues and our customers can understand. Although the communication involved requires a very different approach depending on the audience, the cohabitation of man and machine doesn’t need to be as apocalyptic as Terminator 2 might have you believe. Here’s my take on making the two thrive by communicating the technical in a relatable way with colleagues and customers.

The first step to learning how to make the technical relatable to others is to understand yourself as a communicator. How does your role at the company affect how you communicate?

For example, explaining something that seems simple to me as a developer, like API access tokens, might be rather complex to understand for a Support agent. I have to be aware of the things I accept as common sense, so not to exclude fundamental details that are important for others to understand. Staying in the context of API access tokens, foregoing my developer vocabulary and adopting a door and key analogy might help get my explanation across.

Next, learning to understand your colleagues allows you to communicate with them more effectively. Start by finding out their role at the company and then tailor your conversation accordingly. What information is important to them? How tech savvy are they? Do I understand the question being asked? Is my answer being understood? And, most importantly, what do they need my information for: What will they need to do with it? How can I make that easier?

For example, when we were working on the new sidebar, we first compiled all communications from the merchants on our forum and NPS feedback tool. We’d crunched those and found that merchants would prefer it if our system was easier to use, especially in regards to our sidebar. So we set out to make it easier to use, but we soon found out that different departments have vastly varying ideas of what ‘easy to use’ means.

For design, it means that the design was easy on the eye and flowed well. However, for our front-end team, this could mean that our application load time is as low as possible.

Ultimately these multiple definitions converged and gave us the new sidebar, which brings more readability and clarity to the application – and also loads quicker than before because of newly implemented frontend technology. Our open communication has lead us to having two optimal definitions of the term melting together to give our merchants a three dimensional solution.

Lastly, as a developer, open communication with our customers is imperative to successfully code a product that they can easily understand and enjoy using. By giving our customers the opportunity to share their feedback in our forum and NPS tool, we can identify pain points and assess priorities in our product’s roadmap. Once we involve all necessary colleagues to scope and code the new features and fixes (making sure we keep the technical relatable along the way), we are able to announce their deployment to our customers in our in-app changelog, thus completing our man vs. machine feedback loop and improving the product experience of our customers. The customer communicates their pain points with a Support agent, the Support agent communicates their underlying need with a Product Manager, the Product Manager communicates the requirements with me, I communicate a plan with my team, then we communicate the result back to the customer. And so on. We are only as strong as our communication.

We are only as strong as our communication.

Making the technical relatable as a developer, like most things in software, is a continuous work in progress. Not only do you need to translate customer feature requests into code, you also need to understand yourself as a communicator and the middle ground you occupy in conversations with other colleagues. By learning to communicate effectively throughout the software development process, man and machine can feel like complementary forces rather than opposing ones.