Hi! I’m Jason, the Director of Consulting at ZEAL. Zeal is a principle driven company which means everything we do is guided by our values and the way we approach the work, and our clients. In this series, I’ll be exploring these principles and how you can apply them as a consultant, engineer, manager, and beyond. So, let’s get into it...

‍Let’s start with humility:

What do I mean by that? What is your first reaction when a client tells you something is too hard? Your answer may depend on where you are in the journey of growth in your industry. 

If you’re like a lot of software developers, you have a little bit of an ego(!) because you know how powerful the code you write can be. That power can go to your head in moments. Case in point: my first reaction when told something is difficult in the past? Apathy and disbelief. Hard? Yeah, we’ll see.

I’ll admit it, I’ve had my moments on the egomobile.

Back in the day (BZ - Before ZEAL), I had a client project creating an e-commerce website. I had built many e-commerce sites, so I thought I had it pretty well figured out. The client manufactured components for cleaning and maintaining firearms. No problem, right? 

I got an early version of the system to my contact and she started to test a few things. She went in to see what it was like to manage their products with the software. I had made a few adjustments to form fields, labels, and so forth, to customize it to their business. I had a lot of confidence that she would be just fine.

Early in her testing we had a conversation that went like this:

Client: “Does it have a way for me to upload and download products in bulk?”

Me:  “No. Why would you want to do that?”

Client: “Because we have over 10,000 SKUs”

Me (in my head): “WHAT?! Why didn’t I ask about that earlier?! Ugh. I’m an idiot.”

If I had been more curious about the problem I was solving for, I could have asked useful questions to help me better understand their business and unique problem sets. I had made a bunch of assumptions because, you know, I’m a professional 😎. There’s a good chance you’ve felt this pain at one point or another, and this certainly isn’t unique to software development.

The takeaway: slow down to speed up. Ask questions. Get curious about what you *don’t* know. Bring more humility and less ego. 

The experience, of course, was a great learning opportunity. Failing forward as it were. I’m still not perfect, but I’m definitely better than those earlier development days.  

Also, standardizing what kind of things make software projects “hard” can help the process overall.

Ask clients about their: 

• Number of expected users (especially simultaneously)
• Number of widgets to manage
• Budget for servers and infrastructure
• File sizes (particularly if your project involves processing them)
• User expectations of speed
• Technical platform constraints

The list goes on but you don’t need an exhaustive list to do the best thing for the client. Remember that your clients know their business. Trust them. They know the challenges they’ve had, and they may have already tried solving this problem before. When they say it’s hard, believe them, and start asking questions. Those questions will help you start developing…

The Shared Vocabulary
‍What does “hard” even mean? The answer will vary depending on who you’re talking to and what their role is.

Hard could mean the user experience has been challenging and inefficient. Hard could mean the process eats RAM, CPU, disk space, or network bandwidth in ways that are unsustainable.

Hard could mean there aren’t enough available people to work on the problem. It could mean a lot of things.

As a consultant, you often have the opportunity to start new work, with new clients. You won’t have built up a relationship yet. You won’t know who all the players are. You don’t have an established, shared vocabulary yet. This is important to the success of the project. Why? You establish your baseline of what hard means and build from there. 

How do you get a shared vocabulary? 

Ask questions. Humility makes another appearance here because you have to be comfortable saying, “I don’t know what that word means. Can you explain it?”

Specifically regarding things expressed as “hard”, you can ask:

• Who is it hard for?
• What is the workflow of the process?
• How long does it usually take?
• What has the experience been like?

Take good notes. You’ll start hearing vocabulary that means something to them and you’ll start to understand how it shapes the work. You’ll probably also want to ask some more questions to dig in deeper to specific areas that you’re unclear about.

It’s really easy, as software developers, to use the terminology and vocabulary that we’re used to to describe the work we’re doing. This will be fine for some folks, the more technical members of the client team, but it’s off-putting and isolating to the ones who aren’t technical. They’ll feel less involved and less engaged. You need their insight too! Using their vocabulary to describe the work, and focusing on solving problems in terms they use, will lead to further development of the shared vocabulary. 

Taking an interest in the client’s vocabulary, and then using it, builds trust as well. It tells them that you care, that you’re paying attention to what’s important to them. Trust builds repeat business for consultants, and job security for business analysts. 

Believe the client, whether internal team members or external companies. Recognize that they likely know more about their business than you do. Ask questions. Get definitions for words that are new. Create a shared vocabulary and create trust. 

Apply this principle to guarantee that you’re delivering the outcome that they want, and need.

Photo by Patrick Federi on Unsplash