The Conversation

The Conversation

The conversation has more control over the outcomes of our projects than we like to admit. I can write great code, I can write performant code. I can write code that is so flexible that no kind of messed up data thrown at it causes any bad exposures or mishandlings. Guess what? It does not matter

Regardless of how good or bad your code, review process, versioning and branching strategy there is one outcome that matters more than all the others. Does your code do what your business needs it to? Whether you are working on an internal application, a public facing website, or a simple utility for maintanance tasks on a server the same truth remains. Software solutions must be solutions to the problems you are being asked or at a minimum, a step on the way to solving those problems.

Think of this from a manufacturing perspective. If I’m an engineer and I get asked to find a way to make a racecar lighter and I instead find a way to make a racecar smaller, but just as heavy, I havent solved any problems. The power to weight ratio of the car will remain the same. Maybe there is some advantage gained, but guess what, the person who hired you to make the racecar lighter isn’t going to be particularly pleased. More often than not, software solutions that do not solve the problems they have been asked to solve deliver no value to your organization, customers, or even yourself. The thing that probably did happen, is someone in your organization probably has to socialize that yet again, IT gave them a swing when they had asked for a ladder.

Why do good conversations matter

The best way to avoid missing on a delivery is to have a common understanding with your stakeholders and customers about what it is that you need to deliver. That common uderstanding relies on several factors, but ultimately the way to get there is to simply talk to the people you need to deliver working software to. This creates oppourtunities for clarification, refinement, and a deeper understanding of the problems being solved. Often times assumptions have been made at some level about what software can and cannot do. The limitations of a platform, license, environment, or legal restrictions could make an assumed solution invalid. A good conversation gives you the chance to chalenge those assumptions.

How to have good conversations

The most important aspect of a good conversation is to let experts be experts. What that means is that the software developer needs to trust that the stakeholders involved understand the problems that need to be solved. The stakeholders also need to trust that the developer understands how to solve them. This mutual trust and respect means that both parties will listen to the other on the parts that they hold expertise. If I, as a stakeholder ask for a way for people to pay our company on their cell phone and ask the developer of team for the best way to do that then we have a good conversation. If I come to the developer and ask for a way to pay us through a mobile web app written using react.js, I may have overstepped.

Understanding the demarcation lines of expertise is tricky, and ultimately depends on the structure of your organization. The key here is to understand your own organization and structure and to respect the authority that each group has. Regardless of where those lines lie, coming to a conversation with respect will make the most difference.

Challenge Assumptions

The biggest place we can save ourselves and our stakeholders from getting a solution that solves an irrelevant problem is to challenge both our and their assumptions about what our problem is and what kinds of solutions we need. To do this effectively we must first have the previously mentioned respect. The next step is to listen, and to clarify. Let the stakeholders explain what they want, and let them explain fully. This is a great place to not interrupt, and to write down your questions until they have finished presenting their problems and possibly a suggested solution. When you have heard the vision and intent start asking questions.

Ask good questions Good questions are questions that are not leading, that are hopefuly restatements of what you understand the stakeholders to want, and show good faith in trying to solve problems. “Why would you ever want an android app for the apple watch?” is not a good question. “Are you saying you want to support the apple watch on our android app? How often do our users that buy their smartwatches from apple but then buy android smartphones?” is a much better question. In this made up scenario the stakeholder just meant a smart watch, and not an apple watch. Regardless of how crazy or off the wall an idea may seem, ask questions that challenge it, but also respect it. If an idea sounds absolutely crazy, it might be better to see where you might misunderstand, rather than challenge the sanity of your stakeholders.

Follow up, Be specific

The last bit that makes a good conversation good is what happens after. Depending on the way work flows through your organization use the appropriate tool to digest what you understand is desired and then follow up with a restatement of what you plan on delivering. Be specific enough that the stakeholders should not be suprised by what they get when you deliver. This gives one last chance for a check on clarity of your goals with the solution. A simple email stating:

“Hey Bill, I understand that we need our current website to be accessible from a mobile device. I am going to make our website responsive, which is to say I will update our current website to dynamically change its shape and layout to fit the screen that is accessing it regardless of size. I know we had some confusion about whether or not this would impact our mobile apps so I am also confirming that none of these changes will impact the look, feel, or functionality of our mobile apps, and that if that is desired will constitute a new story being written. If you could confirm for me that my understanding of what I am delivering is correct I’d appreciate it. It was good talking to you today Bill. –Justin”>

How to recognize bad conversations

Bad conversations are actually pretty easy to spot. The challenge is just paying attention. The biggest things you will see with bad conversations are when devlopers and product owners/customers are using advesarial language. If the conversation is combative that usually means you aren’t hearing each other well. Another indicator is if one side of the conversation is being prescriptive to the other side. “You don’t need a mobile website, you need an app. We shouldn’t even be doing this” Language like that just makes it harder to make progress. In general if you are working together and talking in a way that takes you to serving your organization in the best ways possible then you are at least staying away from the worst conversations.

Takeway

Having good conversations is hard. Having bad conversations are harder. As devlopers, product owners, customers, and just as people, the better we can communicate and the more we learn to hear each other the better things will go. As far as we know there are no mind readers, and so we must be sure to clearly communicate to each other. If we do not then we risk losing track of what is important.