The Divide Between The Programmers And The Customer

How to avoid getting a completely different story at the end

Last time I wrote a post called The 3 Major Divides In Web Programming. It talked about 3 divides lurking around the Web Programming world:

• "Back-End" and "Front-End"
• "Operations" and "Product Development"
• "UX Design" and "Front-End Development"

However, we seem to have forgotten the person who matters the most, lost in our memories as a distant myth, yet core to explain the reason why we all exist: the user.

Yes, there is a mythical human being living among us; their names are known to many, but their purpose to only a few. They may be a god or a king; the difference is if they'll forgive or kill you when you make a mistake.

Although this creature is the one who ultimately pays your salary, we describe them with the same terminology the police uses for individuals who take illegal drugs.

Don't be scared. This post is not for the ones who work in the industry of exchanging money for illegal substances. This post is for you, the programmer, who is flooded with job ads looking more like a soup of buzzwords than an actual customer-facing job description.

Let's talk about the most fundamental divide of them all:

The divide between the programmers and the customer.

You don't see this problem on successful startups when they were at an early stage. A startup has to listen attentively to customer feedback; otherwise, they have zero chances to become profitable. The best outcome is when the customer gives the feedback directly to the programmers, not to a "business person" or someone else representing the programmers. Even better is when the programmers can understand the customer's point of view and the business domain.

As the startup becomes a profitable company, it starts losing sight of the essential customer feedback that got them there in the first place. It starts to create layers of management with Product Owner/Development Lead/Team Lead, then Product Manager/Development Manager, then Head of Product/Head of Development, Chief Product Officer/Chief Technical Officer, etc.

The company also tends to create a support department. However, it's very likely the support department doesn't have the ability to feedback customer usability issues regularly. They tend to hide those issues along with pages and pages of help content and forums, providing the customer a "workaround" for a problem instead of a "solution."

That's understandable. There's no way for a person with technical support skills to know how a piece of feedback can be valuable or not for a programmer. There are some customer experiences, such as "I use this page once a month" or "This screen is too slow for what I'm trying to achieve," that are very important to help programmers shape the direction for the architecture of a system. If the programmers do not receive that information earlier, they can't iterate on the code and make it more reliable for the customer.

As the company grows, roles are segregated along the lines of Business Analyst, Scrum Master, Product Owner, Designer, Programmers, and QAs at the team level. On the management level, roles are segregated along the lines of Product Management, Development Management, Architect, and Agile Coach. Only specific roles are allowed to speak to a customer, mostly designers and product managers. Programmers, the builders, stay on their corner, hidden from the most crucial person. The person who brings the paycheck at the end of the month.

The builders stay hidden from the most important person. The customer.

Some teachers know an exercise called "The Telephone Game," which I have written about in another post. It works like this: the teachers instruct students to position themselves in a circle at the center of the room. One of the students tells a story to a colleague. Later, the student retells the story to the next colleague. The story goes on in circles until it reaches the student who told the story for the first time.

In the end, the teacher would ask the kid:

Was your story accurate?

The kid would say:

The story was completely different

Here's the same answer, coming from a kid of the 2nd grade:

This is what happens as organizations grow and add more layers between customers and programmers. At some point, for a programmer to get into a phone call with a customer, they have to go through many layers of management. In the end, although the information on what to build and why to build it comes in a clear language, it contains little value.

The information becomes useless to the builder. A mere UFO myth.

It's easy to prove this: go to a kindergarten, find a group of students, and ask one of them to kick off the story.

The more distance you create from the programmers and the customer, the less likely it is for programmers to understand the customer problems. By consequence, programmers get blocked from reaching the ones who can answer the right questions. They end up creating the right technical solutions for the wrong problem.

The programmers, although very skilled in their craft, have all the incentives to model the system in the wrong direction. In this circumstance, you see the symptoms in the form of significant performance problems on the product, development slowdown due to architecture rework, user-facing misbehavior of the product, and misalignment between multiple development teams about the purpose of why they come to work every day.

As you put more layers between the customer and the programmers, information starts to get lost until it becomes useless to the one who receives it.

Here's what you can do:

As a programmer , assume it's your job to understand the business domain. Also, it's your job to understand how your work creates value to the customer before writing a single line of code. After all, what's the point of coding if you don't know why you are doing it?

There are no dumb questions.

Writing zero lines of code is better than writing one line of code for a problem you don't understand.

As a Product Manager , enable the programmers to talk directly to a customer. Allow them to receive feedback on how the customer feels, not how you believe the product should be. They may have questions where the answer can only be useful if taken directly, without multiple layers of communication. See the "Telephone Game" and the "Feedback Value Metric."

If you're a big company and can't give the programmers access to the final customers, build or buy one or more companies that use your product. Use those companies to create customers for them.

If you can't give the programmers access to the final customer, create one.

It's easy to believe programmers don't have enough knowledge of the domain to talk to a customer; that programmers are fundamentally unable to communicate. It's easy to think programmers can't understand how the customer perceives the product as a whole. Therefore, they need someone else to talk on their behalf.

However, none of that is evidence programmers are fundamentally unable to talk to a customer. That's evidence the organization hasn't given the opportunity for the programmers to learn enough of the domain so that they can be able to speak to the customers and appreciate the feedback directly; to hear the story from the one who tells, not the one who retells.

Direct feedback is fundamental. Even a child knows you have to receive feedback directly, not through layers of colleagues retelling the same story.

Remember, you may get a completely different story at the end.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook, or Github.

Thanks to Shane Singh for his insightful inputs to this post.

Wanna chat in person? You can find me in the Sydney Software Crafters meetup.