Taking complex technical issues and breaking them down into a format that everyone can consume is an extremely important ability. Spending hours or days developing a fantastic solution that completely is off target puts everyone in a bad situation.
In order to be successful with the technical solutions we come up with, as developers, we need to make sure that our ideas are being vetted by those that know the business issues. The only way to do this is to have the stakeholders verifying our ideas and solutions. How can that happen if we have difficulty understanding one another.
In this article I am going to focus on the verbal communication that goes on when describing or demoing technical solutions. While there are many more forms of communication that happen over the course of a project these face-to-face meetings (virtual or in person) can have the most impact.
For me the first step in communicating effectively is knowing my strengths and weaknesses. Sometimes I talk too fast or cover topics too briefly. I have two approaches to figuring out my strengths and weaknesses.
First I record myself and listen to it. I do this when presenting to… no one (definitely not my kids stuffed animals). Saying things aloud is very different than just writing them down. And hearing myself, while unnerving, really closes the loop on understanding tone, tempo, and all the little details that I don’t think about when talking. This does not need to be done for every meeting (that would be time and soul crushing).
The second tact is to present my technical ideas to a non-technical person. Getting feedback about what is understandable and what is not is invaluable. While one of my strengths is being precise with my descriptions, a weakness is being too brief. Bouncing my words off someone else really helps me know when I am crossing a line into losing my audience.
Each person involved in creating a solution is vitally important. While the developer might be the person to actually create the code to implement the solution, it is up to everyone on the team to help determine what that solution is. Every project is in a different domain and has a different group of people involved. Knowing how to effectively communicate across everyone involved means there is a really good chance the solution will solve the problem.
Everyone has their own expertise to add. While developers are the experts in the tech stack, they usually aren’t the domain experts. You never know where a great idea might be hiding.
Get to know the team by getting everyone involved. Don’t assume everyone’s knowledge level. Asking questions and verifying understanding is a great way to get to know each other and figure out how to relay information in a consumable way. Knowing more about your team will help you empathize with each member allowing a greater connection to form.
It is the developers responsibility to consume everything they can in order to implement the best possible solution giving the projects constraints. There should be someone who is responsible for taking all the input information and forming consumable stories for the developer to easily understand and implement.
This process of creating consumable pieces is important, but can’t always answer everything. Make sure you ask questions as they come up. I have a note taking document that I leave up to write down my questions as they come up.
While the implementation might be complicated it should be relayed in a way that makes it easy to understand. Everyone has their own area of expertise. Make sure they know that you respect what they are bringing to the table.
Break the solution down into pieces for each member of the team to review. This allows for relaying information to a smaller group, focusing on communicating with them in a way that works effectively. Use terminology they are used to. Show how the solution will benefit them specifically.
Breaking it down also keeps everything small as to not overwhelm anyone with too much information. I find that the best way to communicate is through examples. Giving and showing examples that show a small piece of functionality really highlights the solution. It also creates a space for them to ask questions and give feedback.
The only way the best solution will see the light of day is to make sure everyone is free to discuss anything. An open and safe environment will spur some great discussions. Allow for that space to exist. Show everyone that you care; take notes, verify their feedback by restating, allow others to pitch in as well.
While having too much discussion can derail the meeting, giving them room is important. If the discussion is going in circles and not productive, try to bring everyone back to the original issue. Noting that if more discussion is needed then those involved can meet about that specifically.
Make sure during this time you are probing the participants for comprehension. If someone isn’t understanding, this is a learning opportunity to figure out what will help them comprehend.
Everyone communicates differently and has their own area of expertise. Discussion and demoing solutions based around each individual will make for great solutions and happy team members.
Are you ready to build something brilliant? We're ready to help.
Are you ready to future-proof your career? Stay in the loop of our Learn with Redwood Masterclass.