the lessons learned — 6 months in being a software consultant

I have been a professional software developer for a bit over 3 and 1/2 years. Since June of last year, I have been working at Def Method, a software development consultancy in New York City. This has been my first professional experience as a consultant, and six months in I wrote down what had been the 3 most (of the many) valuable things I had learned.

(While there have been many learnings during this time about technology specifics, I’m choosing here to focus on things interpersonal, i.e. the workings of co-workers trying to achieve a common goal or the client/consultant relationship.)

Lesson 1: Listening is more important than talking

Yeah, we all know this. Right? Try not to have your eyes glaze over, because I think this lesson is not only the easiest to forget but also, probably, the most important.

Let’s start from a hypothetical. You are called to a meeting to find a solution for a problem your organization is facing. During the meeting, others are given the chance to speak, and you are not making yourself heard quite as much. Trepidation and anxiety creep in that if you do not make your voice heard well enough, the process will veer off in a direction that “may not be the best”. Like, if their thoughts do not make great sense to you, you have to speak up to correct course.

Speaking from my own personal experience, I’ve seen how it is the times I am having the most trouble understanding another’s viewpoint or idea that I feel the greater compulsion to “talk louder” at them. I get nervous and afraid, thinking that that if their idea doesn’t make clear sense to me then it must be wrong. And therefore I feel a need to assert or re-assert the way I am seeing it.

A person’s need to be heard tends to far outweigh their need of getting their way

Advice: be more like a sponge in a factory process

Keep in mind that while your opinion matters, by itself it is not the goal. Your opinion is likely one valuable one of many, with the goal sitting on the side. So first step, be more like a sponge. Listen and soak up all the information that is being passed around.

Second, validate what you’ve soaked up, what you’ve internalized. In my experience, a person’s need to be heard tends to far outweigh their need of getting their way. So be mindful of this when allowing others to be heard. Hear them and assure them of their being heard, but fear not that you must go in any one direction posited by any other.

Finally after validating, let the information work through you, allowing yourself to process it like a factory into something more refined. By focusing on listening and soaking up, rather than convincing others of your line of thinking, you put yourself in a better position to “synergize” your opinions with those of everyone’s around you, and you equip yourself far better to offer the best solution possible.

Listen and soak, then validate, then process — and then after all that, communicate.

Lesson 2: Really work to understand your client’s need

As consultants and especially software development consultants we have gotten into the position we are in large part because we believe we are good at what we do. We sort of need to have this belief, because otherwise how do we ever market ourselves as being worth anyone else’s time and money. Furthermore, our clients look to us to be experts in our domain (if they could do it themselves, they probably would, right?). So we believe highly in our abilities, and we are viewed as “experts” from clients who often know little to nothing about the process we use.

All of this creates a situation where it becomes very difficult not to tell our clients everything they do not know. This is not to say explaining process to a client is a bad thing. I’m, in general, very much in favor of this, if done well and judiciously. This is just to say, that this is another impulse to be wary of. Just because you are looked at as an expert and have a bevy of details at your disposal to throw at your client’s brain doesn’t mean you should. And just because your client knows basically nothing about your process certainly does not mean you should tell them all the ways they are wrong.

Advice: be the good doctor

Have you ever been to the doctor and been kind of freaked out about something and your doctor did more talking at you than they you felt right? Like, you may have got the feeling that they couldn’t really know what was going on with you since they never gave you ample opportunity to tell them what you had been experiencing? I’ve felt this way before. It sucks. And it is a scary feeling.

Well, your clients are in a pretty similar position. They need treatment, and they’re desperate for it. So be wary of this imbalance of power in your relationship since it may lead you to think you are the only one with anything really important to say and your clients do not have anything worth hearing. Even if your client says something that at first seems patently wrong or ridiculous, you’ll do yourself and them a favor by not dismissing it and trying to understand the pain or fear or need that is behind what they are saying.

So, hear them out. They need your help, and though it may be difficult to decipher what it is that they truly need, your first step needs to come from your best understanding of what that need is .

Lesson 3: know who all the stake holders are and what is at stake for each

Every project has an owner. And a project’s owners clearly have something at stake in that project’s success or failure. But it does not stop there.

Sometimes the owner of a project consists of not just one person or entity but several different people or groups. Additionally, there can often be a mismatch between an organization and the representative for that organization. Meaning, one who represents a particular stake holder, likely has somewhat different things at stake than those of the entity they are representing.

More crucially to recognize here though is that who has something at stake in a project is never isolated to just the project’s owners. Consultants, different types of users, and advisors will all have something at stake in the project.

When many different people (or entities) bring a variety of different motivations to a project, the project is bound to feel pulled in a variety of directions, with consensus harder to attain, and direction being less clear and more muddled.

Advice: be a basset hound

Think of a basset hound using their amazing nose to sniff out the deeply hidden or obscure. Like a basset hound, try to identify all the stakeholders and understand their true and deeper motivations hiding below the surface. This will allow you to relate to and empathize with them. This gives you a deeper understanding of their needs.

As a consultant, it may be tempting to confine your duty as satisfying the needs of your client — whoever that is — as best you can. But understanding the needs of all the players involved will help you alleviate friction, craft a greater sense of consensus, and bring an overall greater feeling of happiness between all the parties involved.

Conclusion

So, in doing most things, I have found the most challenging problems to be the human ones. I had been trying to avoid the use of the term empathy throughout this post, because the term gets thrown around so often that I think it can lack some meaning. But looking back over this post, the one thing that cohesively binds each of these topics together is that each, at its core, is an exercise in empathy. But I it does not work to say “just be more empathetic”. The key is to recognize the times when we are overlooking the need for it and then to bring some awareness to when a deeper understanding of those around you could be really helpful.