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 horrible failure.
The Sudoku nature of the practice can be a basis for larger, structural issues within a team or organization. Management and C-level executives may not understand the full extent of what their engineers are doing while they’re doing it and therefore must trust, to some extent, that everything will be okay when it’s all finished. Developers, meanwhile, are cursed with the endless grind of explaining themselves to co-workers in a way that will convey the complexity of their product, but remain simplistic enough for normal folk to understand.
At the same time, ask anybody, and they’ll tell you how important communication is to the successful running of a business. How, then, does one breach the divide between engineers and management? The technical barriers may always be there, but there are simple, good-faith ways of speaking with developers that will help any project run just a little bit smoother.
When you go to a mechanic to fix a problem 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 asymmetry can complicate a discourse between developers and non-developers, if not tread carefully. 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 people you think are right for the job, you should trust that instinct and assume good intent on their part. A trustless work environment is enjoyable for nobody. Your colleagues are probably being honest and forthright with you.
The thing that trips up all software engineers, when they’re just learning the ropes, is how literal the process of coding is. 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 website or software program, and an uninterpretable mess of error codes.
Those who make it into professional software development are, therefore, highly detail-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.
A manager or executive is assumed to be knowledgeable and effective at leadership. A person whose job it 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.
Bosses who buy into their own superiority create toxic work environments. They make unilateral decisions for developers who, frankly, probably know better than their boss does. Like a President who, by virtue of being President, thinks they can ignore the advice of their advisors who are much more knowledgeable in their specific fields.
Assert yourself on matters that fall under your domain, defer on matters that fall under theirs. Rather than try to make decisions for them, or allow them to supplant your role in the organization, work in concert towards your greater goal.
To avoid being an authoritarian leader, practice empathy. Understand that you and your developers possess different skill sets, knowledge bases and life experiences than you do, and where they’re coming from is just as valid as where you are.
Everyone wants to work for a boss who understands them. 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 programmers do, then ask them questions about it the next day. Show that you care.
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. Diversity is hardly necessary to success, but it’s certainly helpful.
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.
This article has focused on how to work with developers. But developers are just people, so really, we’re talking about how to work with people. Sure, we might generalize and say that engineers tend to have certain quirks and tendencies seen less often in certain other fields. But calling developers detail-oriented--as we’ve done here--is only as useful as calling artists tasteful or hoteliers warm and welcoming: there’s truth there, but it’s hardly universal and wholly incomplete.
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.