How to Influence Software Engineers
“Are there good rules of communication I should be aware of when I'm communicating with engineers?” I recently got this question from a designer, a new subscriber to my newsletter. It is a question I keep asking myself as well.
As a software engineer myself, working with other engineers every day for over a decade now, I have had much time to think about this. In a work context, I am mostly wondering how to appeal to my fellow engineers with my ideas. It is a question that is relevant for anyone who works with software engineers, whether they are engineers themselves or not.
Influencing should not be a dirty word for us
Influencing is a crucial part of collaborating with others effectively. Without it, we would rarely arrive at the same page and head in the same direction. We cannot not influence, we can just do it more or less effectively. So I’d much rather see more effective influencing behavior towards software engineers than resorting to shouting matches, power plays or passive-aggressive behavior.
Influencing builds alignment amongst colleagues. It is not about forcing others to do your bidding, but figuring out what is most important to the team and communicating those points effectively.
In my last blog post I argued that (amongst other things) our ability to work together effectively with others depends on our ability to understand how they see the world. I found that lens is useful for organizing some of my learnings on how to influence software engineers.
There are a few things I have noticed that the software engineers I know often value and believe. Of course, these are my personal generalizations and will not apply to every software developer you’ll ever meet.
I am using the following points more as starting points to explore in conversations with software engineers, rather than boxes to tick! (I have gathered feedback from several developers on this post, and while all of them agreed with the article as a whole, some disagreed with one of the following points, each with a different one.)
How software engineers often see the world
Belief in “objective truths” about the world: Computer Science is considered a STEM (Science, Technology, Engineering, Mathematics) field. Even if they are not CS graduates, many software engineers have a STEM background. In these fields, you often find the belief that an objective truth about the external world can be discovered. And that therefore you can be objectively right or wrong about questions concerning things that exist outside our minds. (On the contrary, many social science and humanities theories favor more subjective beliefs about reality and truth.)
This belief has some direct consequences for influencing software engineers effectively
Providing rational justifications of ideas and requests is crucial. If you can back them up with “hard facts” such as statistics, proof of concepts, or technical documentation, even better
Appeals to emotions and personal preferences might not carry much weight. Appeals to political or diplomatic rationales could be even less effective
State your case as clearly as possible so that each piece of evidence can be evaluated. Visualizations of systems, processes, flows etc. will be helpful.
Structure the discussion in a rational way. Whether it is a verbal argument, a meeting agenda or a written document, being organized about it will carry much weight
When it comes to decision-making, systems and (rational) processes are often trusted over charismatic leadership. Conflict resolution will often involve group discussions and ritualized group decision processes such as votes or formalized decision-making roles. Engineers also often appreciate following proper processes. E.g. an on-call communication channel should not be used for general questions, but only for alerts on systems being down.
Controversies about technical decisions can easily degenerate into hardened arguments about what is “THE (objectively) right thing to do”. Handling these will require de-escalation techniques
What software engineers often value
But despite all of our concerns about objectivity and rationality, software engineers aren’t exactly decision-making machines. We often hold three more subjective values dearly.
Building “high quality” technology: Many Software developers consider their work to be a craft and have a strong passion for building high quality software. Appeals to this passion are often very effective. Illustrating why a certain decision will improve the quality of the software under development will persuade them. On the other hand, decisions that appear to reduce software quality (e.g. by cutting corners or accumulating “technical debt”) will be met with a lot of resistance.
Continuous learning: Due to the constant change in the programming languages, frameworks and infrastructure we build with, developers are used to learning new things all the time. Many of us consider this to be a perk of the job. Emphasizing the learning opportunities that come with your proposal can be another very effective tool in your persuasive toolbox.
Staying on the technological “cutting edge”: Different rationales have been provided for this common preference, from “engineers love playing with new toys” to “new technology enables us to innovate” to “career optimization” (“CV-driven development”).
For the sake of influencing, the rationale doesn’t really matter. It is enough to know that the opportunity to work with what’s on the technological “cutting edge” will often sell itself. Opportunities that involve working with “legacy technology”, on the other hand, are often a really difficult sell.
How can this help us work together better?
Here, I have shared my experiences about which communication style and values I have often observed in software engineers. The communication style gives us some ideas on how to present our arguments. The values point to what kind of arguments are more likely to be met with agreement. We can use the values to build our arguments, and the communication style preferences to present them more effectively.