Tips for Communicating with Software Engineers

Software engineering is like Sudoku - as challenging as it is to execute, anyone off the street can take one look at the final results and determine whether it’s a ringing success or a horrible failure.

In Sudoku if one of the numbers is wrong, the whole puzzle is affected or can’t be completed. We can use this same concept when working with engineering teams. Management and C-level executives working with developers may not understand the process, technology, or day-to-day tasks the engineers are completing. They must trust, to some extent, that the engineering team completes the project to meet the goal in the most effective way possible. Developers, meanwhile, are tasked with mastering communication techniques to explain to non-technical co-workers the complexity of their product.

We know communication is the cornerstone of a successful business. How, then, does one breach the divide between engineers and management? The technical barriers will remain, but there are simple, good-faith ways to speak with developers for success.

6 ways to communicate with a software engineer

Give the benefit of the doubt

When you go to a mechanic to fix problems with your car, you have an inherent problem: this mechanic knows so much more than you do about what the problem is, how much effort will go into fixing it, what parts are needed, and what the market is like for such a service. There is, what we refer to as, an asymmetry of information, which threatens the entire negotiation.

This same information imbalance can complicate a discourse between developers and non-technical managers. While it’s important to make sure you’re not being taken advantage of by someone with more technical knowledge than yourself, that doesn’t mean cynicism is the right approach. If you’ve hired the right person for the job, you must trust their input and expertise. A trustless work environment is uncomfortable and produces more problems than successes.

Be clear in your requests

The very literal process of coding often trips up new software engineers and the non-technical co-workers who communicate with them. Some programming languages are more forgiving than others but, in general, it’s a no-BS practice. One missing or misplaced semicolon can mean the difference between a beautiful product and an uninterpretable mess of error codes.

Those who make it into professional software engineers are, therefore, highly detailed-oriented people. So know your audience. Be clear, precise, and direct in your language, especially when making requests that will eventually manifest in clear, precise code. If you are a non-technical manager working with a developer, don’t be afraid to over communicate and ask questions to be sure you and the team understand each other.

Stick to your lane

A manager or executive is assumed to be knowledgeable and effective at leadership. A person whose job is to manage other people must, by virtue of that position, be able to make decisions that affect their subordinates. That doesn’t necessarily mean that an individual in a higher position will know what’s best for employees below them.

Assert yourself on matters that fall under your domain, defer to your trusted team members on matters that fall under them. Rather than try to make decisions for them, or allow them to supplant your role in the organization, work in concert toward your greater goal.

Demonstrate empathy

To avoid being an authoritarian leader, practice empathy. Understand that you and your developers possess different skill sets, knowledge bases, and life experience than you do. Their perspective is just as valid as yours.

Everyone wants to work for a boss who understands their mountains and valleys. It would go a long way if, even if you don’t know the first thing about programming, you make a small effort to learn. Do 30 minutes of research before bed on what your engineers do, then ask them questions about it the next day. Show you care.

Embrace your differences

We often hear that “diversity is strength,” and the reason why is that uniform groups--as a rule--tend to be limited by their homogeneity. A team of five people sourced from all over the world will be able to do things that a group of five friends would not. Different perspectives inform, expand and build upon one another, creating a collective greater than the sum of its parts.

Thus far we’ve been treating the barrier between developers and non-developers as an issue, but could it actually be a solution? You come to the table with a set of experiences and skills foreign to them, and they have experience and skills foreign to you. You don’t have to work so hard at bridging that gap if you can, instead, leverage it. Rather than cross that river between you and them, build a dam in it.

Practice the Golden Rule

Learning how to talk to developers, in the end, is only going to take you part of the way towards successful working relationships.

Treat your colleagues like you would like to be treated yourself and no technical or cultural barrier will be too difficult to bridge.

---