When you tell people you are a software engineer, most people inevitably assume your job is to sit in front of the computer, punching the keyboard. But you, the engineer, know that being great at your job requires much more than writing code.\n\nOften, you need to be able to sit down with a client or a stakeholder and knowledgeably discuss business aspects of their products. Other times, you have to use your technical and problem-solving skills to figure out a better/easier way of doing things.\n\nIn general, you can help your client best by focusing on high-leverage activities moving their business in the right direction. Writing code can be high-leverage, but another great use of your time is helping make better decisions.\n\nOne way you can do it is by playing a role of a technical consultant — coming up with solutions to problems, but also giving your clients technical advice.\n\n### Prerequisites to giving advice\n\nThere are two prerequisites to being a technical consultant and giving your clients technical advice: expertise, and trust.\n\nBecoming an expert in your field is, obviously, outside the scope of this article. When it comes to trust, last time [we discussed](https://firstname.lastname@example.org/consulting-for-software-developers-1-building-trust-547f8957cf6a) some of the little things you can do to build trust with your clients, and the reasons why you’d want to be a consultant in the first place.\n\nFor now, we’re going to assume you’ve got both trust and expertise covered, and focus on what is required to actually give clients good advice, and help them succeed.\n\nIn a typical scenario, a client will want you (or your team) to solve a business problem using technology — implement a feature, come up with an architecture of the system, etc. It’s your job to assess the situation and come up with a solution. Often times, you also need (or want) to share your ideas or discuss different approaches with the client, your team, or other stakeholders.\n\nThis is what I refer to as giving advice, and it consists of:\n\n* Understanding the problem well\n* Coming up with a solution\n* Sharing your thoughts and ideas\n\nSo how do we go about getting better at these?\n\n### Ask questions and listen\n\nIf you want to give a good advice, you first need to understand the problem thoroughly. When talking to a client you want to listen deeply to them describing the issue, and ask good questions to get the most information out of the conversation.\n\nI can’t stress this enough. Asking the right questions and listening patiently is a much better use of your time than trying to come up with a gazillion clever solutions right ahead.\n\n> _“Asking the right questions takes as much skill as giving the right answers.”_\n\n> _— Robert Half_\n\nHere are some of the aspects you might want to zero in on, together with some useful questions to ask:\n\n#### Business context\n\n* “Why are we interested in solving this problem, right now?”\n* “What’s the business use case behind this?”\n* “Is there anyone else on your side involved in this?”\n* “Can you tell me a little bit more about the people you envision using this solution?”\n\n#### Previous experiences\n\n* “What has this process looked like in the past?”\n* “Are there any options/approaches you have already tried? Why didn’t they work?”\n\n#### Expectations\n\n* “What would the process look like if we built the perfect version?”\n* “What is the best/worst thing that can happen?”\n\nThere’s a lot of excellent resources on listening and asking questions, including the following books:\n\n* _“Deep Listening: Impact Beyond Words”_ by Oscar Trimboli\n* _“A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas”_ by Warren Berger\n* _“Reframe: Shift the Way You Work, Innovate, and Think”_ by Mona Patel\n\n### Don’t jump to conclusions\n\nSo the client tells you about a problem they face, and it rings a bell. The problem is somewhat similar to the one you’ve recently faced and solved. It’s really tempting to go ahead and shout out your idea for a solution.\n\nMost of the time, however, it’s much better to keep it to yourself — for a little while. Instead, you might want to keep collecting more information and make sure you really understand the problem (and the context) well. It doesn’t hurt to wait until after the meeting is over and think about it deeply for some time. This way, your opinion will be much better informed.\n\nThis becomes _really_ important if you are working in a team, and _crucial_ if the team is not there in the meeting with you. They might have a totally different point of view and may suggest something you haven’t thought of.\n\nOf course, it all depends on the team dynamics. The ideal world would be one where everyone is invited (and happy!) to share and discuss their spontaneous ideas instantly — but you don’t need to **decide** on anything right there and then, in the meeting.\n\n### Think deeply about the problem\n\nIf you think you got all the information required to start thinking about the problem, there are a couple of tips that will help you come up with a better solution.\n\n**Play a Devil’s advocate**\n\nAs soon as you come up with a solution, try to consider it from a different point of view and refute it. I know it’s hard to try to disprove the ingenious idea your brain has just conjured. If you want to be professional, though, you need to ask yourself the questions that you feel your client/teammates would ask anyway:\n\n* “Why is this so complicated? Isn’t there a simpler way to achieve the same thing?”\n* “Have you considered all edge cases?”\n* “We have done it differently in the past. Why change?”\n* “This looks like a common problem — someone must have solved it already, right?”\n* “Is there an off-the-shelf solution we could use?”\n\nAsking yourself these kinds of questions will do one of the following things: make you abandon a bad idea, make the idea bullet-proof against your colleagues’ questions, or help you come up with a better version of the idea. All of which are great outcomes.\n\n**Try to be objective, avoid thought mistakes**\n\nYou need to acknowledge that your judgment is not always perfect. There are some reasoning traps that are really common and easy to fall into — fallacies, and cognitive biases. Some of the examples include:\n\n* [Texas sharpshooter fallacy](https://en.wikipedia.org/wiki/Texas_sharpshooter_fallacy),\n* [Sunk cost fallacy](https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy),\n* [Confirmation bias](https://en.wikipedia.org/wiki/Confirmation_bias).\n\nI really recommend reading about these and other reasoning problems — it will make your critical thinking skills much sharper.\n\nAnother great resource on the subject is the psychological tome by Daniel Kahneman — _“Thinking, Fast and Slow”_.\n\n**Keep the pragmatism-idealism balance**\n\nMost of the time, a problem can be solved in a number of different ways. Some are quick-and-dirty, others are more robust but also time-consuming. You need to make the best choice given the problem, context, time-constraints, and expectations.\n\nYou will be tempted to do it one way (_“It’s easy, let’s fix it real quick and get it over with!”_) or another (_“If we don’t do it properly now, it will hurt us in the future!”_). What you need to keep in mind, though, is that you can’t reliably gauge if _your own balance_ is right. Having a team composed of people with different perspectives is really advantageous in situations like this.\n\n### Give the advice\n\nOnce you’ve come up with a solution to the client’s problem, you might need to discuss it with a client. You want to give them advice, and you want them to seriously consider, and execute it — or give you the green light to execute. Of course, they might have ideas on how to improve your approach even further!\n\nIf we’re trying to give advice, two things are crucial: you need to be empathetic, and you need to support your advice.\n\n**Be empathetic**\n\nWhen it comes to empathy — you want your client to feel you really care about their business (because you should, and you do). According to research by Tiffany Barnett White of University of Illinois,\n\n> “Consumers who faced emotionally difficult decisions were willing to trade off expertise for benevolence”\n\n> — Tiffany Barnett White, “Consumer Trust and Advice Acceptance: The Moderating Roles of Benevolence, Expertise, and Negative Emotions”\n\n**Support your advice**\n\nWhen trying to support your advice, you might want to mention the following aspects:\n\n* Which aspects of the background/context have you considered important? You can say things like _“I know we’re really concerned about data privacy here, so…”_\n* What other approaches have you considered?\n* Mention previous, related experience.\n\nIf you are a software developer, like me, you might think that our job is to write code for clients. This is a dangerous oversimplification. Ultimately, **our job is to help our clients succeed**.\n\nTo do that, we have to be able to collect the information we need, come up with a good solution, and discuss it with a client.\n\nKeeping the tips I mentioned in mind will help you become better at advice giving, and reveal the blind spots you might have missed.