Software developers face a constant challenge: the communication gap between them and customers. TLDR: customers will never speak the developers’ language. While both parties strive for the same goal—creating valuable, functional software—their perspectives, priorities, and vocabularies often differ. In this post, we’ll dive into the reasons for this difference, explore the implications, and discuss strategies for bridging the gap.
Customers Don’t Know the Jargon
Consider this scenario: a customer approaches a development team requesting website enhancements. However, their language lacks the technical jargon familiar to developers. The customer’s focus is on outcomes rather than implementation details. For example:
Customer (Business Owner): “We need the website to be more engaging and interactive. Can you add some dynamic elements to the homepage?”
Developer: “Sure, we can implement interactive features using JavaScript libraries like React or Vue.js. Would you like to include sliders, animations, or interactive forms?”
Customer: “Um, I’m not familiar with those technologies. I want the homepage to grab visitors’ attention and make them stay longer on our site.”
While people understand technology to some extent today, we can’t expect everyone to be proficient. That’s the reason why we have different professions. For example, we could quickly flip the table. When we go to a doctor, do we understand everything they say? If not, is it our responsibility to learn the medical language or the doctor’s to simplify their message?
They Bring a Problem to Us to Solve
Customers often challenge developers, seeking solutions without delving into technical intricacies. They already have enough to manage various aspects of their business or project. For them, it’s about achieving desired outcomes rather than understanding the underlying technology. For instance:
Customer (Project Manager): “We’re anticipating a massive surge in traffic for Black Friday. Can we handle it?”
Developer: “We’ve optimized the website for performance but might need to scale our servers. Do you have an estimate of how many visitors we’re expecting?”
Customer: “Our marketing team predicts a 200% increase in traffic compared to last year. We need to ensure the website stays up and running smoothly.”
Developer: “Understood. Let’s run some stress tests to see how the current infrastructure handles the load. We can then scale up if needed.”
Customer: “Sounds good. Let’s prioritize stability over new features for the next few days.”
In this example, the project manager brings up a problem: the anticipated visitor surge on Black Friday. They don’t delve into technical details but express their concerns about website performance. The developer proposes a solution-oriented approach, focusing on stress testing and server scalability. By understanding the problem and proposing a practical solution, the developer ensures alignment with the customer’s needs and priorities.
It’s Not Their Job
Just as a car mechanic doesn’t expect customers to understand the intricacies of vehicle mechanics, customers don’t necessarily grasp the technical nuances of software development. They rely on developers to translate their requirements into actionable solutions.
One of my professors at the university contributed to the development of the first defibrillator. The electrical engineering team met the doctors to understand the requirements. They had the following conversation:
Doctor: “Our task is easy. We need to drive some electrical current through the patient’s heart to restart it.”
Engineer: “Understood. How much current are we talking about?”
Doctor: “Big.”
Engineer: “But if we drive a big current through a human body, it will burn.”
Doctor: “Not that big.”
From this discussion, we can see that every party has different areas of expertise. Therefore, other jobs. To understand each other, they need to close the communication gap.
Multiple Customer Personas
In software development, various customer personas interact with developers, each with unique perspectives and priorities. These personas include end-users, clients who order development, product owners, business analysts, and project managers. Each persona brings different perspectives and requirements to the table.
Different personas have different levels of technical understanding. But at the end of the day, their role doesn’t matter. Because developers are the technical people. Developers need to solve the problems. And as we saw above, we can’t expect any of the customer personas to describe their problems with accurate technicality.
The Importance of Speaking the Same Language
Despite the inherent challenges, developers and customers must speak the same language to ensure successful collaboration and project outcomes. This concept aligns with Domain-Driven Design (DDD) principles, emphasizing the importance of a ubiquitous language—a shared vocabulary that fosters clear communication and understanding within a domain.
To understand why it is crucial, let’s think about what happened to the Mars Climate Orbiter:
Mars Climate Orbiter began the planned orbital insertion maneuver on September 23, 1999, at 09:00:46 UTC. Mars Climate Orbiter went out of radio contact when the spacecraft passed behind Mars at 09:04:52 UTC, 49 seconds earlier than expected, and communication was never reestablished. Due to complications arising from human error, the spacecraft encountered Mars at a lower-than-anticipated altitude and it was either destroyed in the atmosphere or re-entered heliocentric space after leaving Mars’ atmosphere.
The orbiter had two measurement units: one developed by NASA and the other by Lockheed Martin. The problem was a measurement mismatch between these two units. NASA’s solution used SI (metric) units, while the other US customary units. In other words, one system measured altitude in feet, and the other measured altitude in meters. No wonder that it didn’t work as expected.
The “beauty” of this situation is that both teams consisted of engineers. Yet, they didn’t speak the same language. Differences become more significant if a technical and non-technical party needs to align. In specific industries, lives can be in danger if things go south. Think of aviation, chemical plants, or automotive.
So we must speak the same language. And we already saw that customers won’t speak ours. This leaves us with only one possibility.
Solution: Developers Need to Learn the Customer’s Language
To bridge the communication gap, developers must actively engage with customers and adopt their language. Developers can effectively tailor solutions that meet their needs by understanding the customer’s domain, priorities, and challenges.
There are effective techniques developers can use:
- Empathy: Developers should empathize with customers’ challenges and strive to understand their perspective. Putting ourselves in someone else’s shoes is a powerful way to improve communication.
- Active Listening: Actively listening to the concerns and requirements of customers can help developers gain insights into their needs. The most potent way of active listening is by repeating our interpretation by rephrasing what the other party told us. Customers can reflect on that and confirm or correct our understanding.
- Don’t Invent New Words and Phrases: Instead of introducing new domain terms, developers should use the language familiar to customers. For example, if the client talks about “buyers” in a webshop, don’t call them “users”.
- Event Storming: This collaborative workshop technique allows developers and customers to explore complex business domains together, fostering a shared understanding and language. It may not seem easy initially, but it’s worth using. Experience shows every participant—including domain experts—learn new things about their business during an event storming session.
The Impact of AI
In the post “How To Use AI Developer Tools In 2024”, there is a section on how AI may transform developers’ jobs. We’ll have to deal with less technical nuances and focus more on problem-solving.
Will it mean that customers won’t need software engineers anymore? Not so fast:
Software engineering is much more than coding. We’ll still need to split large, complicated problems into small, simple ones. We’ll have to understand the infrastructure. We’ll have to be able to modify existing systems.
So AI can shrink the gap, but it won’t disappear.
Conclusion
Bridging the communication gap between developers and customers is crucial for successful collaboration in software development. While customers may not fully speak the language of developers, techniques like empathy, active listening, and event-storming can facilitate clear communication and alignment.
As AI continues to evolve, it offers new tools to streamline communication and enhance collaboration. However, human expertise and understanding remain essential.
By embracing collaboration and a shared commitment to communication, developers and customers can navigate the complexities of software development and build a brighter future together.