What Every Developer Ought To Know About Treating Clients Right

Early in my career, I partnered up with a fine gentleman named Sean who ran a web design agency. We worked together and made a top-notch team. He made incredible designs, I coded them, and we delivered amazing results to our clients and got paid.

One time, I took a flight from Dallas down to Atlanta to visit Sean and to meet with a client of ours. Up to this point, Sean had been mentoring me about how to run an agency and a business, and his advice had been pure gold. I learned so much about how to quit my job and run my own business from him, and I'm convinced he's a genius to this day.

To that point, I had been learning the ins and outs of running a business itself, but I hadn't really thought too much about clients. Kinda missing the point, right? It's a good thing I visited Sean in person, because I got a firsthand masterclass in how to treat clients.

See, Sean is incredible at dealing with clients. He talks and listens to them appropriately, never freaks out, and always provides excellent advice. Nobody walks away from a meeting with him thinking "gee that guy's an idiot".

He and I walked into a meeting that in hindsight I realize now I was totally unprepared for. It was a big meeting, with a big client, and it was magical. They talked to us about what they wanted to do, and we showed them what was possible, provided guidance, and ultimately came to an agreement about what we were going to build.

This meeting was different from all my other meetings I'd had. Before that meeting, I thought of client meetings like this:

Somehow convince the client that I have skill
Make the client tell me exactly what they want
I code it
They pay me

Easy! Unfortunately, that's a very low-skill way of handling clients, and nobody really comes out of that with the best possible result. That day in Atlanta, Sean showed me a better way.

Leveling Up

There's a progression of ability in anything, right?

As novices, we start out barely capable of doing anything while we try to learn our tools.

Then we get a little better and become intermediates, and are comfortable with our environment and tools, and we start to look for patterns.

As experts, we become advanced at not just the tools, but also adept at recognizing and bending patterns to our will.

That's the progression, especially as a tech developer or software engineer. And as engineers, we often think of our tools and patterns as programming languages, or IDEs, or which framework we are going to use. We argue about all of these things incessantly. But what about clients? Clients also operate in predictable patterns, and our interactions with clients are also predictable.

Pattern Recognition

So how do we take advantage of these patterns and ensure that we reach our goals?

Well, first let's define the goal:

Build great software...
...for great clients...
...who respect our work.

If this is our goal, then we need to learn how to approach and interact with our clients. This is beyond basics like treating clients with kindness and respect. Those are a given. This is about our interaction styles and the results.

As a beginner, you are trepidatious about your interactions. Everything is new to you, and you really have no idea what's normal.

Can I tell a client they are wrong?
Can I really say I'm an expert in this thing?
I think the client actually knows more about it than I do!

As an intermediate, you are probably confident in your tools. Maybe overconfident, to the point where you think that the tool is the most important part. You're just starting to recognize patterns and give thought to far future planning, and the interactions between software and business, but to you, software is still probably the point all by itself. However, the client doesn't really care about the software, so you have a mismatch.

At a senior level, you will be working together with your client to deliver a result. You're not a code monkey, and that's the biggest difference. Hopefully you aren't so focused on the beginner-level things like which tool to use, or programming languages. It's also not about software patterns and designs anymore. Don't miss the forest for the trees.

Now I'm An Expert?

So what does it look like as an expert? What patterns are we working with while working with clients?

When you are at this point, then your interactions with your client become a dialogue. You'll notice that at a beginner level, the client is doing a monologue. At an intermediate level, the software engineer is doing a monologue. These are both unhealthy.

That's how I had approached all of my client meetings before I met Sean. They talk, I listen, then I go sit at a computer for a while to build them something.

When you do this, you miss crucial elements of the software development lifecycle.

The very best way to approach it is with a dialogue. The client needs to deeply share what the business needs. The engineer needs to investigate that and deeply understand it. Then, the engineer needs to show what is possible technically, and share possibly roadblocks and limitations. The client then needs to push back and suggest alternative approaches.

Ultimately, the client and the engineer need to agree on an overarching solution, that is eventually going to be come the product or feature that is being built. You don't have to know every detail, but being on the same page here at the start serves everyone well, everyone is heard, there aren't any assumptions about the product, and most importantly, it sets the standard for all communication going forward with the client.

Notice the important parts here: nobody is held up to some impossible god-like standard. The client needs the engineer, just like the engineer needs the client. There will be a humility and mutual respect for the knowledge and expertise that the other person has.

This is the pattern: mutually respectful conversation.

Relationships

What you might notice is that clients are relationships like any other. Healthy relationships are based on respect and dialogue, where you know and play to each other's strengths. Just like you don't want to be friends or partners with somebody who only talks about themselves, or the opposite—never provides any insight or opinion on anything—be good partners with your client and them with you.

That's the lesson Sean taught me that day, by showing me one simple thing: conversation.

I talk about software development best practices and running your own software company on Twitter, come talk with me there! @jordanambra