CODEX
How to Talk to Engineers
Communicate with Software Engineers Even if You Can’t!
Software engineers can be a tough bunch to communicate with. We can be nerdy, we can be cocky, we can have no social skills whatsoever…
I’m going to give you 4 solid tips that you, as a business-oriented individual or perhaps a creative entrepreneur, can use to effectively communicate what you need so you get the results that you want.
Imagine you need a developer to set up a web store for you, an artist, to sell prints of your work. You can’t just walk up to one and say, “I need a website to sell my art. How much would that cost?”
They’re going to look at you and utter something like, “Um…”
If, however, this engineer runs their own development shop or has experience running projects, they’re doing to know how to dig into that extremely vague ask. They’ll start with probing questions to try and figure out the scope of your request. Like do you want something fully custom or do you need help setting up a Shopify store?
This imaginary conversation will eventually get you where you need to be, but there will likely be some speed bumps along the way.
How to avoid as many speed bumps as possible?
Whether you’re approaching an engineer you’ve never met before, cold-calling dev shops, or walking up to someone who has worked in your company for the past 12 years, these 4 tips can help speed things along.
- Specificity. How often do you work with KPIs, analytics, or other types of hard metrics? Think about how you work on those types of projects or in that data-driven framework. That’s how software engineers think about pretty much everything. Specificity. Precision. Exactly correct functionality. Data-driven results. This is the perspective you need to frame your project-oriented communication. Make a very targeted request supported by facts and data that will lead everyone to a very specific objective.
- Large blocks of time. So many people on the business-oriented side of the modern workplace focus on chopping their day up into hour or half-hour chunks and go to meeting after meeting. Maybe you go to a meeting for an hour, then work on a spreadsheet or PowerPoint deck for a presentation, then another meeting, then lunch, then some afternoon work time, then a status update meeting…you get the point. Developers don’t work like that, and if they’re pulled into too many of those short blocks of non-development time, their productivity just drops through the floor. To create software, we need large blocks of time to research, develop algorithms, code, test, and just build what you want us to build. Context switching is expensive, and too much of that in any given week will result in not much getting done. When you talk to an engineer about a project or are setting up meetings, keep this large time chunk framework in mind.
- Quiet doesn’t mean they don’t understand you. Many engineers don’t think out loud. Without practice, it can be awkward. And this in turn may lead to awkward silences in a meeting. While it’s possible they just aren’t paying attention, they may be running through systems, methodologies, and their current workload in their head so they can answer your questions about your problem. Can they do it at all, and if so, how? When can they do it? How do they get a real project plan going? These thoughts might be running through their head for 20 agonizing seconds. Don’t be afraid to ask if they understand what you’re asking, and if so, ask them to think out loud. It might make them uncomfortable at first, but so what? You’ve got a job to do, so you need clear and open communication even if it’s just brainstorming. And they’ve got to learn to be a better communicator anyway.
- Feed them. Food just makes everything better, and even works as a workplace-friendly social lubricant. I mean…I guess you can drink on the job, but I figure most places frown upon that. But food can go a long way. Sure, you may get a slob or two in the bunch, talking with their mouth full and spewing crumbs on their shirt and laptop, but you can live with that. Food and knowledge work actually goes together really well. Just do a little bit of recon first to make sure nobody has a fatal cashew allergy. And if you have a vegan in the bunch, get a vegan option. Not vegetarian. Vegan.
With a little practice, YOU TOO can learn how to communicate with software engineers. With even more practice, you might even be able to train them to communicate effectively back to you.
Feel free to subscribe to my YouTube channel for more content like this.
