What Your Clients See
This week, I had two very similar discussions with other software consultants. In both cases, we were lamenting how our clients often focus on the superficial. In terms of code, they care if the requested feature is up and running—not if it added a significant amount of technical debt to the codebase. In terms of design, the clients care if the thing looks pretty—not if it's tested out or validated with end-users.
When I say that my clients focus on the superficial, I'm actually making a very biased argument. In reality, clients see what they are able to see. Firstly, while it's easy to see what's bad work and what's good work, it does take a trained eye to see what's good work and what's great work. Secondly and more importantly, only you and your team are able to see the actual work in its entirety. Clients see only what's presented or communicated to them.
This is a problem I first encountered as a university student.
During my studies, me and my friends participated in a business case competition. The competition had two rounds: qualifications and finals. Teams like ours that made it through the qualifications were given training and mentoring by the organizers. We read a lot about case competitions and we did a lot of practice cases. In the finals we came in third. But that's not the important part. The important part is what I learned about the bottleneck problem of business case presentations.
In case you're not familiar with business case competitions, let me give you a brief introduction to them.
In a business case competition, each team is given the same business case to solve by themselves and then present their solution to a group of judges. The business case is a document of 10 to 20 pages telling a story of a company facing a need for strategic action. The company can be real or fake, a multinational corporation or a family business. Sometimes the company is experiencing stagnating or decreasing sales, sometimes there's a PR crisis, sometimes you as the team have to identify what's the actual problem or future threat.
Once your team receives the business case, the clock starts ticking. You are given 2 to 4 hours to identify key issues, do the analysis, write out synthesis, and construct a presentation for the judges. The presentation will take around 15 minutes and it's followed by a Q&A from the judges. After all the presentations are done, the judges will convene to discuss the presentations and decide on the winner.
The 15 minutes you are given to present is never enough. This is the bottleneck. In order to meet the time limit you have to leave a lot of stuff out. You can't go in front of the judges and act out in detail what happened during the last four hours. There are discussions and analysis that never leave your team room. Not because they aren't important. But because there's not enough time.
The truly great business case teams are able to empathize with the judges. They are able to understand that the judges were not present with your team when you were solving the case. They are able to understand that when your presentation starts, there is zero shared understanding between you and the judges.
In practice, this means that you need to separate the appealing work from the important work. Part of the important work is work that the judges don't care about or which is difficult to communicate, but something that is still required for your team to perform on a high level.
This applies to all of our doings. The fact that we do work which is hard to make visible or appreciated, doesn't make the work itself unimportant. Focus too much on the superficial, and you lose the mastery and meaning behind your work and products. Feel professionally hurt when everyone isn't able to appreciate your mastery, and you are on a path of misery.
In addition, I do believe that more experienced leaders and clients are able to look beneath the surface. They don't direct their focus only on the shiny parts of the delivered work or on the short-term. I judge a lot of books by their covers especially when I have very little knowledge or experience about the subject. It is my immaturity, not maturity, that allows me to be fooled by work that lacks substance.
Even though some of the important work can be hard to make visible, it doesn't mean you should stop trying. As a software developer you know that continuous delivery tools make you faster, clean code makes you more reliable, and validated designs make the software itself more engaging. All of these things contribute to competitive advantages, help you retain more users, and build up your brand. Your clients (internal or not) won't disagree with you that these are important goals.