“The customer is always right” can lead to a disaster if followed too literally. Obviously, software developers shouldn’t try to override their client’s needs or ignore requests, but there’s always a reason for a business to hire outside IT assistance. It’s typically because the staff at that business have reached a problem that lies outside their scope of expertise, and they want someone with software development expertise to help them solve it.
A developer should trust that the client knows what they want on a high-level, but it’s unfair to assume that they know all the details or best-practices of how they need to get there. They wouldn’t have called for help if they did!
We recently spoke with a client about their experience with a large systems integrator company whose technicians made that exact assumption.
These technicians did the bare minimum work in order to achieve exactly what the client requested. So, for example, when the client asked for a form with fields for different entries, the developers did just that. They didn’t talk with the clients about the options of how to achieve that end result, or make any suggestions for slight variations that could mean a much more efficient system.
When these clients asked their former IT team why the fields didn’t autofill any repeat entries, the developers responded that since they weren’t asked specifically to do that, they didn’t do it. Their mission was to fulfill requirements at a minimum effort and nothing more, offering no innovation or suggestions.
Here’s why this is so problematic: IT is the expertise of the software development team, not their client’s expertise. Even when a client has a substantial background in new system development, their reasonable expectation is that they’ve hired experienced professionals to do the work. They shouldn’t have to explain user-interface best-practices to them!
Another way to look at it is thinking about a different type of work. If someone hires me to paint their room blue, there are some questions that I will ask them and some assumptions that I will make because of my experience. I’ll ask them what color blue and if they want anything special done, and then I will use my own best judgment on how to do that best.
If I painted a room with a toothbrush and didn’t use painter’s tape or a tarp on the floor, it would be silly of me to object that you didn’t tell me to use a roller and tape or protect your floor! Those things fall under the realm of expertise that can reasonably be expected.
The most striking part of our conversation with our clients about the team that they worked with in the past came out in a meeting. One of the staff members made a great point, saying “We didn’t know what they didn’t know!”
The bottom line is, no one can read minds. When you hire a developer, programmer, or an entire IT team, that starts a conversation between all parties. Everyone needs to be transparent about the decisions that are made, but also take ownership for those decisions.
When both parties put themselves in the shoes of the other party, good communication will occur and that’s how problems get solved.