How to Communicate with Developers — and Get Understood
4 Tips for Businesspeople
Every now and then one hears about how business and technology professionals have difficulties understanding each other. After a few years of acting in both roles, it has become clear to me that there is some truth in this.
The two groups often tend to look at issues from different angles. Perhaps a bit like the optical illusion below. Does the picture represent a vase or two faces? The answer is both, but some people see the vase first and some the faces.
Businesspeople tend to focus on how the new solution will make their, or the customer’s lives easier, while tech people tend to focus on how to write the code so the solution will work. Both perspectives are required but clear communication — sometimes even to a level that might feel ridiculous — is needed for the two groups to see how these two perspectives are connected.
Below are four communication tips for people representing the business perspective.
1. Explain Why Something Should be done
Developers/Product Owners usually get a lot of requests, and they need to understand how critical your need is in comparison to all the other needs. To make sure your project is prioritized correctly, try to be as concrete as possible and if possible, give the project monetary value. If there is a deadline, or the solution is not relevant anymore after a specific amount of time, make that clear too. For example:
If the customer gets the option to pay with Apple Pay in addition to credit cards, we expect to see 5% less abandoned shopping bags, which translates to approx. 150 000 € more in sales per year. We regularly get complaints about this, so this would also have a positive impact on customer satisfaction.
Another benefit of clarifying the value of a solution is that it enables developers to make better design decisions, as they can now separate attributes critical to value creation from those that are not.
2. Continuously Confirm That You Are on the Same page
No matter how clear you think that your expectations and the timetables are, pretty often, there is still room for misunderstandings. Especially if your team mostly meets online or if you have long meetings that makes it challenging for people to stay focused.
What “let’s do a test” means isn’t as clear as if you would go through the test design and what the expected outcomes are. When handling complex matters where several developers are involved, it is also a good idea to go through what each person must do to create the desired output. This way, there is a greater chance that somebody in the team spots tasks that need to be done but have fallen through the cracks. Or previously unnoticed dependencies.
When testing a new chatbot, you could say that the production test is to be done for customer using the Swedish interface on Wednesday 11–15pm. Swedish interaction options marked as “ok” in the database table ChatbotAnswersSwedish are included. Our aim is to have the user interaction logs analysed by Thursday this week. Kevin, what will this require on your part? Is the timetable doable? …
When you think everybody is on the same page, confirm it by repeating what you just agreed on, using different words to minimize linguistic misunderstandings.
3. Be Concrete in Your Requirements
If you need a new feature or solution, be as specific as possible with the requirements. The developer does usually not have your business acumen and cannot be expected to know about things that in your mind might seem self-evident.
Let’s say you have commissioned a sales dashboard. Don’t let your specification be limited to this information. Think about what you want the finished product to look like:
- For how long back in time do you need the data?
- Do you want sales separated by region, client, or product?
- What granularity is needed? Year, Month, Day?
- Does the data need to be in real-time, or can it be a day old or more?
- How would you like the data presented? If possible, supply a simple sketch of what you have in mind
The more specifications you make, the better the first version of the feature will be. The job also gets done faster, as the developer has a better understanding of the scope of the project and can get started immediately, without having to get back to you and confirm major details.
4. Don’t Report Bugs without a Why and a How
Even though some bugs might be very straightforward, the majority are not. When reporting a bug, it is a good idea to take on the same mindset as a lawyer in court. Just stating that, for example, “sales in the CRM system are wrong” will not help the developer find and fix the bug. You need to provide proof of your observation.
Why Is This a Crime / a Bug and What Are the Consequences?¹
Crime: According to law abc paragraph 1, it is forbidden to steal. Therefore, suspect B committed a crime when stealing 1 000€ from his employer. The penalty for petty theft is a fine. Suspect B will likely also lose his employment, if convicted.
Bug: According to our sales master data program, the 2021 sales for client B is 10 000€. Therefore, there is a bug in our crm program when the 2021 sales for this client is reported to be 5 000€. Sales Reps have been instructed to use the sales program until the problem has been solved. Hence, the bug is not urgent.
How Can We Be Sure the Crime Has Been Committed / the Bug Exists?
Crime: Witness A saw B steal money from the company office on Thursday 1 May 2022. The event was also caught on surveillance camera 3. Let us have a look at the footage…
Bug: Sales Rep A noticed the incorrect sales figures on 1 May. She also checked the numbers for clients C and D, but they were in line with the sales program data. The incorrect numbers are found in the main graph at www.crm-system.com/company/stats/124. Let us have a look at the screenshots provided…
When using screenshots or recordings, remember to mark the relevant parts properly. A screenshot including ten different sales figures does not help much if the incorrect one is not clearly marked.
Communication Is Key but Keep It simple!
Business might not come from Mars and Tech from Venus, but they still have different perspectives and taking this into account makes cooperation much easier. It might feel tempting to take shortcuts when it comes to communication, but five minutes saved writing sloppy specifications or not summarizing an action plan can easily create misunderstandings that, with bad luck, transform into hours or days of delays. In addition to causing delays, bad communication decreases motivation and causes breeding grounds for conflicts.
However, specific and clear communication is not to be confused with overcommunication. Unnecessary information is noise that prevents people from getting your message. Keep it simple! In speech, this could mean skipping filling words and deviations from the topic. In writing, preferring short sentences and avoiding storytelling.
Overall, efforts to improve and clarify communication are well worth the time invested and the outcome is a happier and more efficient team.
[1] With this comparison, I don’t mean to say that a bug is an offense, the way a crime is. Bugs happen, that is just life. However, they will not get solved without proof, the same way as a crime in court will (hopefully!) not be solved and a judgment made without proof.
