How To Communicate With Software Engineers
In my adventures leading engineering teams and acting as their advocate, I’ve learned the importance of being a capable translator. Even in the world of tech startups, it’s not uncommon to find people that don’t really understand “this software stuff.” It’s not surprising. As our world advances, we keep adding layers of abstraction between the biological and the technological, to the point where the technology we interact with is only noticed when it fails.
People really notice when it fails! We rely on software in many aspects of life, and when it doesn’t work as expected, it’s painful. When Alexa doesn’t play the song you ask for, you may just shrug it off. However, when the developer a few desks away from you makes a decision–or mistake–that costs the company time or money, it’s hard to stay cool.
For the technically uninitiated, understanding how to work effectively with engineers can be a challenge, and bumps in the road are inevitable. I’m going to share some insights that will help you avoid the rough patches, and collaborate with engineering teams effectively.
Learn The Ropes
Collaboration starts with empathy. You’re going to need to equip yourself with an understanding of the fundamentals to empathize with your technical colleagues. That’s not to suggest you need to take a class and start coding (although that’s an option, if you’re interested). The important thing is to be open to learning and to stay curious.
People love to talk about things they’re good at, and that includes developers. Ask questions and show an interest when you can. Doing so will help you become informed progressively and build rapport.
Being a Luddite isn’t a badge of honor. The original movement ended no more than a year after it started, and any remaining members of this technophobic movement were shipped off to Australia. Being ‘old school’ may be a source of comfort at home, but embracing progress is vital to success in business.
Don’t Build Walls
Developing software is still a relatively new field, and the technical lingo is only where it starts. The way projects are organized, the KPI’s, and team hierarchy are also different than other functions. People sometimes treat engineers differently than their other colleagues, and there is no shortage of bad stereotypes. Fight the tendency to treat or see the technical team as a separate team.
While the business of software development is a team-oriented, collaborative process, engineers often spend a large portion of their time heads-down and headphones-in. Don’t confuse quiet for a lack of enthusiasm. Most developers are more than happy to help out, brainstorm, or listen. So much so, in fact, that we need strategies to make sure developers can stay on task while quickly identifying incoming requests that merit immediate attention. Help desk software can be instrumental in load balancing, prioritizing, and tracking the response to issues that arise.
I’ve received many eye rolls and groans when I’ve instituted ticketing systems for requesting developer support. I sympathize–doing so feels like too much process, and it runs the risk of creating yet more communication barriers. On the other hand, having no system for prioritizing tasks and their assignment isn’t viable at scale. Tech leaders must use process as a tool to protect from waste (of time and effort), but that should be complemented by constant advocacy for open lines of communication.
Assume Good Intent
Even when the lines of communication are strong, stressful situations can arise. People make mistakes, forget things, and say hurtful things thoughtlessly. It can be confusing and frustrating when the same person that stayed up all night to build your feature then forgets to deploy it in the morning.
I cannot overstate the power of positivity. When someone fails to deliver, misses a timeline, or something breaks, try this: Imagine an explanation (within the realm of reality) where the person had the best intentions and meant no harm. Can you think of a realistic explanation? In lieu of knowing all of the details, assume the best. Once you’re on the other side of the situation, there will be time to figure out the real source of the breakdown.
Poor or unreliable behavior should not be tolerated, but negativity while in crisis is only going to work against you. Keep Captain Hindsight at bay until the post-mortem meeting. Always make time for the post-mortem meeting. Radical candor will be a valuable tool once you’re there.
It’s also important to acknowledge that there are areas of expertise where you may not have the full picture or experience to back up your opinions. In addition to assuming good intent, build a foundation of trust with your team mates, and ask questions to prove or disprove your assumptions.
Avoid Icebergs
Every developer has heard it: “That change should only take five minutes!” Sometimes the assessment is correct, and sometimes it’s wrong. A broken clock is right twice a day. Pro-tip: If you find yourself tempted to say those words, consider rephrasing it as a question.
I’m not suggesting that software engineers need to have their egos stroked at all times. In reality, even our estimates are very often wrong. Here’s one reason why.
People are good at estimating based on known quantities. You want a feature, so you’ll need to tell the developer. They will write some code, probably, and once it’s finished, they ship the feature. Simple!
Here’s the reality in a team-based environment. The developer was doing something else, so they have to snap out of it and field your request. Assuming no planning is required and no dependencies exist, they write some code. It’s the team’s policy to peer review changes in order to eliminate “bus factor” and uphold code style and design guidelines. It’s also team policy to have QA test the feature before shipping it. Next, it has to be deployed. Depending on the platform, this process can vary a great deal–from painless/instantaneous to a multi-day review process courtesy of Apple. Now the feature is out in the wild. The developer: “What was I doing, again?”
You might be thinking, “That seems like overkill. I just wanted the text to be a different color.” That’s true. Dropping everything to change the color of text is outrageously expensive, time-wise. That’s why we’ve created systems to queue and prioritize tasks. Scrum does this by packaging work into time-boxed iterations, or sprints. Kanban solves the problem by controlling the number of tasks in progress. Both use a queue, or backlog, to allow work to be sorted by priority.
Interrupting scheduled work to inject another task is essentially a very abrupt change in priority. If you find yourself shifting priorities a lot–particularly interrupting other work–it will be worthwhile to determine why.
Don’t Hack Habitually
There are good hacks and bad hacks. When Zappos started, the founder took pictures of shoes on sale at the local mall and listed them online. When a purchase came in, he would go back, pick them up, and ship them out. That was a good hack, because it proved the concept. It was also a bad hack because they lost money on each transaction.
This is the definition of hack that I’m talking about here: To make a quick code change to patch a computer program, often one that, while being effective, is inelegant or makes the program harder to maintain (from: wiktionary).
Use hacks to prove the concept. If it works, resist the urge to make it a habit, and instead get the hack built into a permanent, repeatable solution.
Why? This isn’t just another formality; hacks come at a cost. They often require developers to support them, which means you’ll be waiting on us. It interrupts otherwise scheduled work (see previous section), and corners may have been cut on process, which can be risky.
It’s really hard to stop doing something that works. If the hacked solution produces sales or saves time, giving it up will be a challenge. If you need help breaking the habit, consider getting together to brainstorm better solutions as a group, and don’t forget to include engineering and product stakeholders.
Strategies
When it comes to internal communication, choose the right medium. What kind of response is desired, synchronous or asynchronous? If your request needs an answer right away, then go speak in person or make a phone call. On the other hand, if it’s either non-urgent or informational only, consider email. If you have no qualms with your message getting overlooked accidentally, Slack or GChat are probably the way to go.
Consider who you need to contact. Don’t “spray and pray” by emailing a dozen engineers. If you don’t know who to talk to, check with an engineering manager or product manager. If a system is in place for reaching the on-call developer, use it. If you hesitate to do so because it’s been ineffective, take the time to talk to the person that instituted it, and work with them to find ways to improve the solution.
You shouldn’t have to walk on eggshells around developers. Ask for what you want. If it’s urgent, ask if it can be done sooner. Just be careful not to minimize others’ effort in the process. Remember the “it’s just a text change” example. Bad phrasing like that is an easy mistake to make–I get called on it from time to time.
Software engineers are humans (for now), and there’s a good chance that you are, too. I hope that some of these tips will help you to work alongside them more effectively. End of line.
