As developer consultants, we generally work with clients, majority of whom are not technical, to help deliver a software solution to their problems.
It's not always easy because technical skills alone would not result in a happy client, and I was curious what key skills you need to have to be a successful one. So I chatted with a couple of other local Madison devs and we discussed what we think these key skills are.
Below is a summary of our key points and our chat log behind each one.
1. Learning
Having the ability to learn and how fast you learn will impact your consulting relationship with your client. There are many things to learn like the client's business, their needs/problems, who knows which, even their codebase and tech stack. It's similar to adaptability, and certainly having a positive attitude and I can do it attitude will help you tackle all of the things that need to be learned and adapted to.
Steve: An employee is expected to have some ramp-up time to absorb the stack, the company, the culture, etc, but a consultant is expected to be productive as quickly as possible. That means the entire engagement depends on the consultant learning as much as possible as fast as possible -- understanding the client's business, their needs, their problems, how to get results from other people in the company, who to talk to for what, etc.
Cristina: Ah so can this also mean adaptability?
Steve: I think there's a lot of overlap there
Cristina: Yeah, I think a positive attitude is also key here
Cristina: There's a lot of things to tackle
Cristina: Having an "I can do it" attitude will keep you resilient in all the things that need to be done.
Steve: Definitely. It's also a great way to build exposure to a wide breadth of things. The "sure, I'll take that on" attitude keeps you relevant as technology and the business keep moving forward.
2. Ability to Listen
Listen to your client, ask further questions and read between the lines to determine if what they're asking for really would meet their needs. A lof ot clients come with assumed solutions already in mind and part of the consultant's work is to ensure that the client gets the appropriate solution that fits their needs.
But it's tricky. While doing this, you have to be careful on ensuring the client still feels heard and does not feel arrogance coming from your end.
Bo: You have to be able to listen very carefully hear to what your client is really asking for versus what he/she may be asking for at face value. "Listening" encompasses asking good questions.
Cristina: Oh, yeah, reading between the lines!
Steve: That's a good point. Clients usually assume you know all about their business and general things about their problem. Sometimes getting results means putting on the deerstalker hat.
Bo: Example: we've learned the hard way that clients don't always really know what platform (!) they should really be targeting. We've built web apps that the client later decided should be mobile, and vice versa. More careful inquiry, poking and prodding at the early stages, versus, simply taking the ask at face value would have saved both of us time & $.
Cristina: And also, the client needs to feel that they're actually heard right?
Cristina: It's a careful line to listen between the lines and making the customer not feel like they're heard and just sensing arrogance from the consultant.
Bo: def
3. Expectation Management
Setting expectations applies not only to customers/clients, but also team members, bosses and executives. It can also apply to your personal life, like with a significant other, a friend, a child, a parent, a relative or an acquaintance.
Ensure they know what to expect from you so that you can manage and build their trust in the relationship. This means a lot of proactive communication, and asking clarifying questions if you are not sure about something.
Cristina: So by Expectation Management, I mean that developers should be able to set expectations with customers and teammates, if applicable. This means, letting them know what's coming next, what to expect, what are the good things, what are the bad things.
Cristina: Wrong expectations would result in people getting upset because expectations weren't managed well enough.
Cristina: For example, I am working with a customer and they asked me to develop something.
Cristina: If I didn't manage expectations well, I would say I'll get this done within a week.
Cristina: If I did, I could say that I need more information, and some time to research, and I don't know the exact timeline yet.
Steve: I've found this to be crucial for building trust with the client
Bo: Managing client expectations is hugely important, and not always easy.
Bo: so — yeah, good one.
4. Negotiation
As mentioned, clients/customers can have specific solutions already in mind, and sometimes, that means asking for impossible things. This short youtube comedy sketch demonstrates how difficult that can be. Being able to counter and negotiate their asks while keeping that trust in the relationship will ensure the client gets what they really need.
Cristina: Customers can tend to ask for impossible things. Having the ability to counter their asks and explain things in a way that they can see the benefit to them, can mean $$$ saved for the customers and more efficient solutions.
Bo: good one also
Steve: This is a good one but also difficult to master. I have not 😟 but my go-to tactic is to find a win-win-win by understanding what's driving the client.
Cristina: I don't think anybody would ever master this. It's so hard!
Kendell: I've found while consulting for Horticulture, before switching to tech that self worth is a big part of negotiation. That way you don't feel guilty asking for a deal that respects your time & financial expectations.
Steve: Somewhere I read that negotiation should always be approached from a position of power - even if the only "power" is that you can walk away.
Cristina: Hmm.
Cristina: Doesn't sound quite right?
Cristina: In a consultant role, you don't have that position of power
Steve: I think it depends on the individual. I was sent to a client recently and found the manager to be an absolutely terrible person, and it was very bad for their dev team. I informed my boss I wouldn't be returning and felt the moral situation strong enough to say my employer could either keep me and not send me back or lose me. A couple of weeks later the manager was let go.
Cristina: Wow
Cristina: I'm glad to hear you have your employer support on this one
Steve: Everything's shades of intensity, but if the worst case happens, there's always another job
Cristina: I think that's easier for people with years of experience on their belt
Cristina: It's hard for someone who's just starting out. their bargaining power is pretty low
Steve: I think there's a bell curve. Having no experience definitely lessens that power. 3-6 years of experience is where the power maximizes because that's where the highest number of positions are. 7+ reduces in power again because the number of options becomes more limited.
Cristina: Wait. interesting. Why do you think 7+ reduces the power?
Steve: But in the end I see it as being about self-respect. Gotta eat Ramen for a few months to get out of a toxic job? Do it.
Cristina: Harder for people wtih families though. Especially if you don't have the backup savings to not really care about keeping your job
Cristina: Still curious why would 7 years of experience reduce the number of options
Steve: IMO it's a function of specialty and salary. 7+ years usually means you're in a niche or deep in a specific industry or set of technologies. Shifting to a job in a different area would require taking a pay cut because you're basically the equivalent of someone with 2-3 years of experience in that area. Not many people are willing to take that drastic of a measure (though we have seen several recently at my company).
Cristina: Oh, good point. didn't realize that.
Steve: Family/savings as a limiter is definitely true, but there are always other jobs. TekSystems will take anyone who hasn't been a zombie for more than four or five months.
Cristina: True, but the quality of the position would be questionable right?
Steve: Oh, undoubtedly, but if it's just a temp position while searching for a "real" job, it's a way to pay the bills/support the family until something better is available
Cristina: True enough, good point
5. Explain Technical Concepts
When going to the doctor and they bring up a medical term about what you have and does not explain what it is, do you find yourself getting frustrated?
In our technical software world, a lot of terms are jargon. We get so used using them every day that we forget which words are jargon. When working with clients, we need to be more aware of the terms we use, watch for confused facial expressions, and be able to explain them in a non-condescending way to ensure and keep that trust in the relationship.
Recently, our cat had to have a lot of tests because they felt her kidneys were larger than normal during her last physical exam. Throughout the process, the vet explained everything in layman's terms that I could understand and I was very appreciative of that.
Cristina: Having the ability to be able to explain technical concepts to people who don't understand them will set a consultant apart.
Cristina: Think explaining CORS to a customer, and being able to explain it more with relatable common objects where non-technical people can relate. Or explaining technical debt. Being able to do so will help convince customers of concepts you want them to do. 🙂
Steve: We see this often as many of our clients have a vague idea for their business but know nothing about tech, electronics, materials, or design. They get frustrated if we can't explain why building their thing has a line item for user account management or whatever.
Bo: Yep, doing so in a way that client doesn’t feel stupid . I have a hard time keeping up with concepts and esp their acronyms in parallel techs all the time. And things change so fast..
Cristina: Yeah, very key! If you explain it in a condescending way, then you're destroying that client relationship trust
Steve: Ooh, I'm going to run with that one
6. Agnosticism
As consultants, our role is to solve our client's problems in the best way that we can. We should then be careful to pick the technologies for our solution that best fit our clients, and try to avoid using the technologies just because we really like them or would like to play with them.
Bo: It’s easy to get married to a favorite tech or toolchain, but it may not always be the best fit for your client. One size doesn’t always fit all..
Cristina: OOOOH!!
Cristina: I love this one
Cristina: Choose the tech that's best for the business/client/users rather than your favorite ones.
Steve: Nice one! Some clients already have their stack embedded in stone, and being unwilling to conform can lose the business or make the project a lot harder.
7. Organization
Software is complicated. There are a lot of tasks, requirement clarifications, bugs, steps to implement, etc. The better your organization skills are, the better you'll be able to keep track of outstanding tasks, which ones need follow up, map out the big picture, and prioritize which tasks are critical to be done now. Being able to do these would result in efficiency and therefore cost less $$$ as the project progresses.
Cristina: Organization skills can help you keep track of all the things that need to be done TODAY vs LATER.
Cristina: It can help you keep notes of what was discussed with clients, past decisions and paths forward.
Cristina: Knowing what can be done TODAY vs LATER will also help keep you focused and know when to set expectations and communicate with your client;
Cristina: Being focused would mean efficiency in spending $$$ therefore reducing cost.
Bo: +1
Steve: Nice. It also contributes to building an organized project - setting appropriate priorities (e.g. critical path items) and focusing on what the client requires sooner rather than later.
8. Realism
We all would like things to go as best they could, but this is not always the case, especially in our software world where there is a lot of ambiguity. So being able to have a realistic lens on can help with expectation management and also help build that trust relationship with your client.
Bo: This maybe overlaps with several of the other ideas, inc. Expectation Management — but this also might be one of the areas I’m personally worst at. For instance, building out realistic timelines — I find I’m almost always way too optimistic, even after doing this kind of thing for a long time…
Cristina: Hmmm Yeah, it's related but different also. I think we all want to be optimistic but reality doesn't quite let us achieve that desired timeline
Cristina: Communicating the reality also to clients can be tough
Bo: yep & yep
Steve: re estimating, I triple my worst-case estimate and they're dead-on. Not joking - at the end the estimate is always within a relative handful of hours of the actual work.
Cristina: Estimating is hard. It also depends on how well you know the system if the system exists already.
Cristina: If it's a new system, then there's even more unknowns in terms of integrations with new/existing technologies.
Steve: It's definitely more art than science!
9. Empathy
Being able to understand your client and be able to see things from their perspective will help you better solve their problems and also help build trust. Empathy not only plays a role in your client relationship but in all aspects of your career like building trust with coworkers, or building trust/keeping morale with your team of developers.
Steve: Really just a facet of client relations - understanding the client's motivations, situation, desires, limitations, etc from their perspective provides not only an alignment of purpose but also builds trust
Cristina: oh yeah. And in larger projects, if you're a lead of other devs, empathy also plays a role in your team being efficient because your team's morale would be higher.
Bo: I think this also goes for your clients’ users too — kind of an extension of what I was trying to say about Listening
Cristina: Very nice point about the users. Too often, we end up forgetting about the end users
Steve: Agreed, part of satisfying the client is making them look good to their clients
Steve: Feed the Elephant theory extended a level
10. Business Understanding
We developers can get really technical and love to solve problems with code. But we have to remember that ultimately we are developing solutions for business reasons. Along with empathy, the more we understand the business, their priorities, their goals, their needs, the better we are able to solve their problems.
Cristina: We develop software for businesses!
Cristina: The more we understand that business, their processes, their customers, and their needs, the better the solution we will end up creating for them.
Steve: This one is high on my list. There are lots of projects that are just clean-up jobs because someone wanted to try some new technology or do something they hadn't done before. At the end of the day devs are responsible for making money for the business, not satisfying an itch.
Cristina: Too many a times I've seen devs develop solutions because it's a shiny new tech. The business $$$ should be the end goal, not to play with new tech.
Cristina: Can always play with new tech as part of a hackathon or something.
Steve: Or just because it's a Saturday! I ported my ping-pong scoring system to a Pi 1 the other day because my laptop died. Learned about changing expectations (the Pi 1 was amazing in its day, but no longer "fast")!
11. Out-of-the-Box Thinking
Sometimes, we get too stuck in our way of thinking because we're just too close to the problem. There is value in seeking perspective from outsiders outside of the box, listen and consider their points of view.
Bo: sometimes the inspiration for an innovative approach to a problem comes from a completely different discipline or field
Cristina: Good one! It's so easy to get into this. This is why I often seek out non-team devs on opinions because it's so easy to get too in the box.
12. Documentation
Documentation is not fun, but it does really help because we're building a product and documentation is the piece of booklet that we get when we buy something from the store that needs to tell us users how to operate it.
Similarly, the software we're building is a product, and we need to build a manual to tell other users how to support it. For software, other users = the client/business owner and other developers who have to either add to it, or fix some bugs.
No documentation also usually means bottlenecks because only 1 resource knows how it works, and bottlenecks significantly slows agility.
Bo: a no-brainer, but often a place where freelancer’s esp cut corners — after all, the client usually doesn’t care (at first!) if the code is well documented and organized
Cristina: Also, selling this as a key need to the customer
Cristina: Of course, need documentation to operationally support the software you've built
Cristina: How will YOU know how it works in the future, or even worse, some other dev who did not build it?
Steve: This bites me every time I revisit old personal projects
Cristina: Ha. Me too. Biting me already on a personal project of mine.
Steve: I...may have lost the source code for an executable I want to make updates to. That might ok because there weren't any comments in the code to start with.
Cristina: Organizationally, we have bottlenecks because of the lack of documentation
Cristina: only some specific people know how X works
Cristina: so, then, only those people can work on X
Steve: Ahh, yeah. We just dealt with a client who was all .Net except that one critical microservice that someone decided to try out Python on (and document nothing)...and then he left. So they keep hiring people to figure out how it works, saddling them with the microservice for a while, and repeating it when they quit.
Cristina: Whoa lol
13. Stewardship
As consultants, we need to keep the client's best interest. Steve says it best in the chat log below.
Bo: 👍 good one
Steve: Consultants are responsible for spending the client's money wisely. There are lots of ways that can manifest, but it comes down to acting in the best interest of the client at all times - even if your employer wants you to do otherwise. A trust relationship is paramount in consulting, especially in a small town like Madison.
14. Flexibility
As consultants, we also need to be flexible on what can or cannot be done. We can negotiate as much as we want, but too much negotiation can turn our client relationships sour. We need to choose our battles wisely, and to know which ones to let go.
Cristina: While it's important to negotiate with clients on what's right, it's still important to be flexible if the negotiation doesn't work out.
Cristina: Don't get too stuck on your opinions because ultimately, the customer being happy is what matters and if we remain stubborn, then customers will just get frustrated and we will NOT get anything done.
Bo: def
Wait, where are technical skills?
As consultants, we definitely need technical skills to be able to build technical solutions for our clients. We all agree they're required.
However, Steve brings up an interesting point on how some employers actually didn't care if the candidates could code, they just wanted someone they could train to code.
Cristina: I mean, I'm not surprised, but none of our list involves technical skills.
Cristina: It's of course a given that you need technical skills to be able to consult successfully.
Steve: Technical skills can be acquired through on-the-job training, but interpersonal/business skills are more artsy and nuanced
Steve: I've had employers who didn't care if candidates could code, they just wanted someone they could train to code
Bo: Right, maybe a discussion for another day — the skills / disciplines that one needs to code etc don’t completely overlap those that are needed to consult
Steve: I think a lot of valuable consulting skills are also valuable manager-ing skills
Summary
To be a successful developer consultant requires not only technical skills, but a myriad of soft skills (interpesronal/business), which are harder to master. But as long as we're aware of them and continuously try to improve, then we're already doing better than how we were before.
