« All Episodes

Building and Maintaining Client Relationships: Active Listening

Published 2/12/2016

In today's episode, we're talking about a fundamental skill for building client relationships: active listening.

Mentioned or relevant to today's episode

Developer Tea is proudly supported by Dev Bootcamp, the original immersive coding program that transforms beginners into full-stack web developers. Head over to devbootcamp.com/developertea to learn more.

And lastly...

Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.

Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to be talking about how to understand client relationships and how to build on them. Today's episode is sponsored by Dev Boot Camp. A short term immersive software development program we will discuss more about what Dev Boot Camp does later in today's episode. But first I want to jump straight into today's topic, client relationships. This will be the first episode in what I hope to be a series of episodes that will deal with client relationships specifically as it relates to the developer and the work a developer does. We all have a client to please. For some of us that client is your boss and for others it's your user. But for most Developer That client is typically a more traditional example of what you would think a client is. Someone who has a product or an idea and is coming to you to build some kind of software for them. In this series we're going to be talking mostly about client interaction and how you can capitalize on client relationships through interaction and how you can grow those relationships in the strong healthy lasting relationships that are beneficial not only for the client but also for you. Of course those are the best kinds of relationships. As we get into the subject we need to set some base level understanding of how I'm going to approach this discussion. This is going to have a lot of my opinion in it and a lot of my values are going to be cast in these client relationship discussions. I want to make sure that I kind of explain some of the assumptions that I'm going to make. The first one is something that we've already hinted at. We're going to be talking a little bit more about the traditional client, the traditional product owner role, the one with the idea and the one who has the decision-making power whether that's the leader of a company or maybe the entrepreneur behind an idea. That's typically who we're talking about when we say a client. It could also be a team of people that have decision-making power. We're going to make a few more assumptions about the client. The first one is they are not asking for free work. Someone who asks for free work without any kind of compensation isn't a client. They are a free loader. This is a bad working relationship in my opinion. It's not really good for either side. If you are being asked to work for free, it's bad for the client because you won't be incentivized to do good work. It's bad for you because on top of the fact that you don't really have an incentive, this is also largely a waste of your time. Be wary of anyone who asks you to work for free or for so-called exposure. This is a tactic often used to get young developers or inexperienced developers or designers to do work for lower than a fair market value. Of course, it's certainly a different scenario. If you're donating that work, the important factor here is that the client values the work you do and sees it attached to a specific trade value. In other words, whatever they are offering you should be specific. If you are donating the services, you should be specific about the value of what you are donating. This is incredibly important for establishing your authority of your trade. If the client doesn't value the work you are doing appropriately for your authority level, then you shouldn't work for them. It's not a good relationship to pursue. The next assumption is that you actually want to help the client succeed. Of course, this is one of my personal values that I'm putting into this particular assumption, but I believe the best client relationships are those where each side is an advocate for the other side. If your goal is to get as much money as possible out of a client, even if you do that in a dishonest way, well, maybe this isn't the podcast for you. But if you believe that your work can help both you and the client and you're seeking to help them achieve their goals, then we're on the right track together. So assumption number three is that you want to help the client succeed. The last assumption, at least for today, is that the client is represented by one key person, one decision maker. This means you interact with that one person or with one team of people who act as a unit. In later episodes, we might get into a discussion of how to deal with clients who have differing opinions and are both trying to control the project. But for now, we'll keep it as simple as possible, one client with one voice working on one project at a time. Even the simplest client relationships can be very difficult to manage. From stressful timelines and unrealistic requests to difficult or awkward conversations about budget and scope to differences in opinion, there's so many things to overcome when it comes to client relationships. So we're going to start with the basics, the basics of any relationship, communication. We instinctively may think, and rightfully so, that communication automatically means knowing the right things to say. Communication, for example, is what we think of when we think of public speaking. But more often than not, communication first means learning how to listen. And that's exactly what we're going to discuss today. How to be an active listener, specifically how to be an active listener as a developer working with a client relationship. And we're going to take a quick sponsor break and then I'm going to come back and give you four tips for ways you can be a better active listener as a developer in your client relationships. Today's episode is sponsored by Dev Bootcamp. If you're thinking about becoming a software developer, check out Dev Bootcamp. Dev Bootcamp is a short term immersive software development program that transforms those who are new to coding into job ready, full stack web developers. Learning front and back in web development, teamwork and leadership skills in a rigorous and inclusive environment. In just 19 weeks, you can join over 1900 graduates and counting. Dev Bootcamp has several locations around the country and is accepting applications now. So visit devbootcamp.com slash Developer Teato learn more and make sure to let the folks at Dev Bootcamp know that you are a Developer Tealistener. Thanks so much to Dev Bootcamp for sponsoring today's episode of Developer Tea. Now let's jump straight into the ways that you can be a better active listener as a developer. Tip number one, listen for the user needs as most clients won't be focused primarily on technological needs. Listen for user needs. When your client is talking to you, listen for the things that they are saying that describe the user needs rather than technological needs. For example, you wouldn't ask which platform they want to use, but instead ask them what kind of people will be using the platform. This is an example for early on in the process, but there are many other situations where you can avoid a technological discussion and instead opt for a user experience discussion. Of course, this isn't universally applicable. For example, if they do have specific technological requirements, then you need to listen through those things as well. But when you start talking about technology rather than the user experience, a lot of clients don't necessarily need to know about the technological side, all of the different languages or frameworks that you're planning on using as much as they need to know how it affects the people who will be using that particular software that you're building for them. So focus on these things. When you do this, it helps the client understand why you choose to use particular technologies. A client will recognize that you're basing your decision on what technology to use on things they ask for rather than a biased or personal recommendation. And it's not just about what technology you use, but how you solve problems, your implementation of a solution. You wouldn't talk about, for example, the performance of an algorithm. Instead, you would talk about how it's faster for a given user or how it actually affects the software as a whole. So focus on the user needs rather than the technological interpretation of those user needs. Your job is to interpret those user needs into the implementation, which ultimately does end up being a disambiguation of technological decision making, right? But your focus in a discussion should be on identifying the user needs and then you abstract away all of the discussion of the technological needs to your implementation. This instills a great level of trust with your clients because you're talking about the things that matter the most to them. Ultimately, most clients don't care what technology their particular product is built on just so long it works correctly for the people who are using it. And that should be your ultimate goal, to listen for those user needs when your client is talking. The second tip is similar. You should ask what a user is trying to accomplish not how they want to accomplish it. Listen closely to the desired outcome when a client asks for a feature. You should be asking yourself, who is the user? And what do they start with? What information do they have when they start using this particular feature? What do they end with? How quickly do they need to be able to perform that action? And do they need to do this many times in a row? Maybe multiple times per day? Or perhaps many times over the course of the products life? Or maybe they only need to do it once? These are the questions you need to be able to answer. Typically, this is articulated in something like a user story, if you're familiar. If you're not, we'll include a link in the show notes that describe what a user story is. But your job is to steer the client to focus on the ideal outcome, not on their presumption of the path to that outcome. In other words, a client may try to describe what they want you to do rather than what they want to accomplish. And it's your job to help steer them towards a conversation of what they want to accomplish and allow you to be the solution architect in that particular scenario. Your job as a developer is to determine the most dependable, effective, and efficient route to accomplish that business goal. While a client may have an idea of what that looks like, your job as a developer is to identify their business objective and determine the best solution. This is exactly what consulting is, and that's exactly what you're supposed to be doing for your clients. So take that burden off of them and make sure that you communicate to them, that you are intending to take that burden from them so they can focus on the outcomes, not the path to that outcome. The third tip I have for you today is that when you're meeting with a client, you should show that their time is important to you and your time is important to you. When you meet with a client, they should know that you don't take their time lightly, but you also want them to know that you don't take your own time lightly. By being on time and setting a clear agenda and desired outcomes from meetings and ending the meeting on time, you are showing that you value the time of everyone involved, both your client and yourself. Show that you care by intentionally turning off your phone and perhaps also turning off your laptop. I recommend listening and taking notes on paper. If you need to take notes on your laptop, be explicit that you only have your laptop open to take notes and close the lid when you're in a deep conversation with that person or when you're exchanging ideas back and forth. This may seem like kind of an old school tactic. It may seem a little bit legalistic, but really this is just an extra signal that you are engaged and invested in the meeting. If you show up late and you pick up your phone or you type on your computer or you ask them to repeat something because you aren't listening, you're not really offering them your full attention. And your client may feel like you're easily distracted or worse that you don't value their ideas. If you did that to me, I would feel that way. Even though I understand that you're probably doing something that is important and perhaps even relevant and that you can multitask and we all have our phones out during important conversations at some point. This can be just an offensive feeling, especially in a professional environment and in particular in the earliest meetings when you're setting out to develop the relationship with that client. Be intentional when you are with your client. Show that their time is important to you and that your own time is important to you, that you view that time as an investment. And ultimately, this sends the signal that you care about the relationship and you care about the work that is being done. The fourth and the final tip that I have for you today is to repeat questions and repeat answers in your own words. If you've never played a game of telephone, I recommend you try it the next time you're bored and have five or so friends in a room together. Here's how the game works. The first person comes up with a sentence. The more complicated the sentence is, the more extreme and hilarious the outcome. The first person then whispers this message into the second person's ear and the second person listens and then whispers what they heard into the third person's ear and so on down the line to the last person. Now the last person says what they hear out loud and then the first person says the original sentence out loud. Typically the results are both shocking and for some reason really entertaining. This illustrates a point about communication though. What you hear is not always what was said or at least what was intended. You see with telephone all you're trying to do is get the words right. But in a real conversation you're not only listening to the words but you're also adding context for example. Communication at its most fundamental level has a sender and a receiver. The sender is explaining their message and the receiver is interpreting the message. In the telephone game there's many senders and receivers which is why ultimately that message ends up getting distorted so easily. But you'd be surprised at how common it is that we get this wrong. The message we hear certainly is made up of words but it also relies on context, inflection and a host of other variables that may be difficult to dissect especially on the spot and especially with somebody that you barely know. And this is arguably the source of conflict for relationships perhaps more often than not. The message sender the client in our case may say something about a feature and the receiver that's you the developer may hear something or interpret something entirely different from what the client intended. One way to help overcome this issue is to re-articulate the message. This means to restate what the person said. But it's not just reciting the words that the client just spoke. Instead interpret what they said and put it into your own words. Summarize what they said. For example, the client may say something like they want a mobile friendly application. And you may say, so you want an application that works on mobile devices and is available in the Apple App Store as well as the Google Play App Store. The client may then clarify by saying something like, no, we want a responsive web application that works for users who are on a limited bandwidth connection. If you had not restated the request in your own understanding, you may have been playing a very professional game of telephone. But when you re-articulate the question and then also the answer, if you re-articulate what your client is telling you, then you are adding more context. You're disambiguating and ultimately creating a clearer picture of the message your client is intending to send to you as the developer. So let's go back over these. You want to listen for the user needs rather than focusing on the technological requests or the technological needs. Secondly, you want to ask what a user is trying to accomplish, not how they want to accomplish it. You focus on the business goal rather than the path to that business goal and then you create that path. Thirdly, when meeting with a client, show them that their time is important to you and that your time is important to you. And finally, re-articulate. Repeat the questions and repeat the answers in your own words. If you're ever unsure and even sometimes when you are sure, be intentional about repeating and rehashing to get the details straight to totally understand what your client is trying to say to you. It is much better to be more explicit and more clear than ambiguous. I hope you've enjoyed today's episode of Developer Tea and if you have enjoyed it, be sure to let me know. You can do that in many different ways. Want us to tell me on Twitter. The Twitter handle is at Developer Tea. You can tell me in the spec Slack community, which you can find at spec.fm slash Slack. You can also email me at developert.gmail.com. And the reason I want you to tell me whether or not you enjoyed this particular episode is because I want to decide whether or not I'm going to continue doing episodes about client relationships. I think this could be a very valuable discussion to start with you, your peers and perhaps even your clients themselves. Thank you so much again for listening to today's episode of Developer Tea and thank you to Dev Bootcamp. If you're thinking about becoming a software developer, you should check out Dev Bootcamp. Dev Bootcamp is a short term immersive software development program. It transforms those who are new to coding into job ready full stack web developers. Go to Dev Bootcamp.com slash Developer Teato learn more and let them know that you're coming up from Developer Tea. Be sure to subscribe to Developer Tea. If you don't want to miss out on future episodes, you can do that in pretty much any podcasting app. Until next time, enjoy your tea.