We should all realize that making software is a human endeavour (for the most part). This is not necessarily obvious, especially to those of us with an engineering background. There’s a tendency to think of what we do as being technical work. It’s not.
The thing is, once it’s clear what to do, the technical parts may be challenging, but they’re pretty much achievable. What’s really complicated is everything that happens before that. Before there’s a working piece of software, a bunch of people need to communicate through different languages, since there are only humans in between the customer and the machine. It’s humans all the way down.
Thus, building software is actually a series of translation steps, where each describes to another person “what needs to be done” in different ways. I’ll use a simplified example to try to make this clear. We have:
- A customer language, in which he ideally expresses a need, “pain”, or worse: “what he wants”;
- A product language, in which a vision of the outcome is explained to the design and engineering team;
- A design language, in which said vision gets translated into visual and interaction expressions;
- An engineering language, in which the product and design language get combined to produce the machine language needed to turn all of this into working software;
- Test specifications created by a QA team from all of the above, for them to follow and ensure that everything is as expected.
That’s a lot of translations of conversations in which the participants don’t fully understand each other’s languages, leaving the door open for interpretation. But hopefully after this process, we might just have something close to what the customer needs. We all know how this turns out.
All these translations are necessary because we lack a common language to describe the work to be done at different levels*.* In other industries, like construction, it’s actually possible to draw what is going to be built and even those unfamiliar with it are able to visualize and understand what’s going to come out. We don’t have that for software.
There’s been progress towards that, through techniques like wireframing and prototyping, which help immensely. But it’s not enough, though. If it were, we wouldn’t need to actually build software in “sprints” and then show it to the client for guidance and approval.
When it’s not as expected we follow the Agile / Lean Holy Grail of “iteration”. It’s the equivalent of trying to build a house wall by wall and then asking the future owner: “Is it good? Are we doing OK? Should we perhaps tear a piece of this wall down and create a window?”.
Don’t get me wrong, it’s one of the best tools we have right now and as far we know, the best way to ship software. But building stuff to validate and then “iterate” is way more expensive than if we somehow had magical powers and were able to go into our customers brains and determine exactly what they need and then go and build that. It is a way too expensive artifact to be considered a “communication language”. Expression and understanding should be easier (and cheaper).
So, what can we do?
To overcome the lack of languages that would allow us to properly communicate about what should be built with our customers and within our teams, I believe that the entire development process should be infused with empathy, thoughtfulness and clarity.
Empathy
We keep forgetting that we are building stuff for other people to use. In many instances, we get so enthused by our technical fields that we do stuff just because we feel like it, or perhaps think that it will be cool, engaging, delightful or some other vanity reason. Appropriate consideration if it is actually any of those things or creates value for the customer is often lacking. Then, when usage/sales/feedback data comes in and it doesn’t match what we expected, we feel antagonized: “those damn users, they don’t understand our awesomeness!”
Every team member, through all functional areas of expertise needs to feel true empathy towards the customers’ problems and needs. Otherwise, it’ll show in the end.
Through empathy we are able to better understand the reasons, purpose and goals of the product we are aiming for.
Thoughtfulness
Every team member needs to know why we’re doing whatever it is that we’re doing, and everything should lead to creating more value for the customer, because that is what ultimately aligns with a successful business.
On a first level, it’s critical to ensure that anyone attempting to “extract” the customer’s problem actually tries to get to the bottom of it (be it a consultant, customer support agent, product manager, sales & marketing rep, or any other role). It is definitely not enough to do “what people ask us to do”. Whatever is expressed by the customer in the form of a solution is also biased by their own ideas. It’s the problem and need that we’re aiming at. There are techniques that I’ll go into further details in other posts, but the gist of them all is this: just be relentless in asking “Why?”.
On a second level, this sort of analysis should further emphasized throughout the team, not just “upstream”. Absolutely everyone, at every step of the development process, should be doing their best to question what is being built and the reasons behind it. You might be thinking: “well, that’s not practical, that’s why we have different roles & skill-sets”. To which I say: “how can we build anything if we don’t really understand what we are doing?”.
The further apart we are from the customer’s problem, the bigger the potential for shipping the wrong thing.
Clarity
We need to be mindful of the person we are talking to and make the utmost effort to communicate in such a way that what we’re trying to convey is actually understood.
I’ve seen oh-so-many instances of miscommunication between managers, clients, designers, marketing, engineers, support, operations and essentially anyone involved in making software. It is easy to see that we are, at the very least, being inefficient. But in reality it’s worse, because it also makes us ineffective.
The more there is a clear and common understanding of the work to be done, the more buy-in there will be from everyone, and the likelier it is that we build what the customer actually needs.
Building better tree swings
If we are to overcome the communication gaps that cost us so much time and effort, we need to be able to do it by bringing the problem closer to ourselves, thinking it through and being clear about what to do. It’s the only way for us to build a better tree swing.