In today's episode, we're talking about a fundamental skill for building client relationships: active listening. 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.
In today's episode, we're talking about a fundamental skill for building client relationships: active listening.
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.
Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell. 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 Bootcamp, a short term immersive software development program. We will discuss more about what Dev Bootcamp 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 developers, 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 into strong, healthy, lasting relationships that are beneficial, not only for the client, but also for you. And of course, those are the best kinds of relationships. So as we get into the subject, we need to... kind of 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. So I want to make sure that I kind of explain some of the assumptions that I'm going to make. And 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 kind of 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 freeloader. 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. And 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. So 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. And 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. And 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. And 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 we're not going to be able to do that. But we're going to be able to do that. 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 DevBootCamp. If you're thinking about becoming a software developer, check out DevBootCamp. DevBootCamp 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-end and back-end software development programs and back-end web development, teamwork and leadership skills in a rigorous and inclusive environment. In just 19 weeks, you can join over 1,900 graduates and counting. DevBootCamp has several locations around the country and is accepting applications now. So visit devbootcamp.com slash developer T to learn more. And make sure to let the folks at DevBootCamp know that you are a developer T listener. Thanks so much to DevBootCamp for sponsoring today's episode. of developer T. 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. 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. So if you're talking about a product that's not going to work for them, you're talking about 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 product's 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 outcome for your client. 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 best solution. Your job as a developer is to determine the most dependable outcome for your client. 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 best solution. Your job as a developer is to determine the most dependable outcome for your client. 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 best solution. Your job as a developer is to determine the most dependable outcome for your client. And that's exactly what you're supposed to be doing for your client. So take that burden off of them so they can focus on the best solution. Your job as a developer is to determine the most dependable outcome for your client. And that's exactly what you're supposed to be doing for your client. So take that burden off of them so they can focus on the best solution. So 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. 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 phone. They want a mobile phone. They want a mobile phone. They want a mobile phone. They want a mobile phone. They want a mobile phone. They want a mobile phone. 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 message, the client may then clarify by saying something like, no, we want a mobile phone. 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. The second point is to re-articulate the question and then also the answer. If you re-articulate what the client is trying to accomplish, you focus on the business goal rather than the path to that business goal. And then you create that path. And 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 if you're not sure, you can re-articulate the question and repeat the answers in your own words. 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. One is 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 developertea at 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 devbootcamp.com slash developertea to learn more and let them know that you're coming from Developer Tea. Be sure to subscribe to the Dev Bootcamp channel. And if you haven't already, please do so by clicking the developer tee. 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.