Attention Developers: The Problem Isn’t Technical

How many times have we heard it? Our bosses, colleagues, everyone, it seems, reminds us time and time again that we’re actually customer service professionals, as well as developers. Seems we’d get it, right?

The subject may have been flogged to death, but I’m going to bring it up one more time. Why? Two reasons: first, because we all need the reminder from time to time. And second, because I need the reminder on a daily basis.

It’s easy to believe as developers that the focus of our jobs ought to be on writing applications and reading through spec documents. It’s not. All of us are customer-focused, and customer facing. Even those of us who develop internal applications or who develop for client services teams (like I do), we have customers: the people who commission the things we build.

With that in mind, there are a few things that we (I) should remember when dealing with customers:

• Our customers are often less technical than we are. It’s nice when we have a customer who understands code or is hiring us because they’re overloaded and need some work done; but that’s rare. This brings me to the next point…
• Our customers trust us. They’ve placed an enormous amount of trust in the developer that they’ve selected. We need to show that we’ve earned that trust, and that we deserve it. A great developer should always exude confidence, show the client that they understand, ask intelligent questions, and demonstrate that they have a full, professional-level understanding of the issues at hand.
• Our customers want us to help them make decisions. There’s an old saying that the customer is always right. Not in development. Often times a customer doesn’t know what they want, so how can they be right about their choices? It seems developers have the hardest time with this: their client will say “we don’t know how we want this to work, can you show us some ideas?” The developer, who is much more comfortable demonstrating his solutions in code than in words, will fumble around and sometimes even make a bad recommendation. Don’t do this. Even if it means taking time and saying “let me get back to you,” a great developer will be able to give a client options, and then help the client pick the best one.
• Customers don’t understand what we do, or how we do it. A client will rarely say “I think this will take five hours” and be right. It’s not that the client has high expectations, or is stupid. They just don’t do what we do. We have to help them understand. When we say “well this will actually take 25 hours” we better be able to show them why. Here’s where the architecture goes, here’s database optimization, etc. We should never bloat our estimates to enrich ourselves; that’s not the point here. But we should always be sure that the client understands specifics, and that we show them why, not just tell them.

These tips are not just for the world, but for me too. I need to remember every day that I’m first and foremost a customer service professional. The client is my client, and I work for them.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Mishkin Berteig (@mberteig) wrote at 3/26/2009 12:13 am:

Your second bullet starts “Our customers trust us”.

—RANT—
What planet are you from?! Our customers are terrified that we’re going to deliver crap, that we’re going to over-charge for it, and that it’s going to be so late and so wrong as to be useless! Our customers hate the fact that they depend on us! Our customers think we’re lazy, that we need to be rigidly contracted, and that only threats (sometimes implied, sometimes outright) will get us to do something that is even close to what they want!
—RANT OFF—

Okay. I admit that it isn’t _always_ that bad. But as a consultant this is what I see over and over and over. Big companies or small, product development or IT, regardless of industry. I like the sentiment, but if that is truly your experience of software development, then you are an extremely lucky person!

Copyright © 2023 by Brandon Savage. All rights reserved.