Effectively Communicating Technical Solutions for Various Stakeholders

Whether you're a technical architect, solution architect, or enterprise architect, communication is not an optional soft skill – it's essential to our success. We can have the most brilliant ideas but if we're ineffective in communicating their value, if we're unable to articulate the details, if we can't obtain buy-in from our stakeholders, we won't be successful.

As part of the leadership track at the 2018 O'Reilly Software Architecture Conference in New York City in February, I presented a tutorial on shaping and communicating architectural decisions. The tutorial focused on raising awareness of the importance of good communication skills and laid out several strategies and techniques.

The Illusion of Communication

All too often, there are patterns that people follow that seem like communication but are actually indicative of a failure to communicate. Think back and consider the last time you’ve heard or said these phrases:

“I told them that”

“It was in an email”

“They were in the room when it was discussed”

“It’s in the code!”

It’s time to change the way we think about communication. It’s not enough to have communicated something without also taking responsibility for the follow-up. You’ve probably heard that “communication is a two-way street,” but as software architects and solution providers, we own both understanding others and being understood. While this may not sound fair, it’s a mindset that will help drive to successful communication.

Our Architectural Decisions Methodology

We need a methodology for shaping our architectural decisions, and I’ve found that the best methodology follows a similar pattern to a good sales process. You might think, “Sales? Why are we talking about sales?”

There are many parallels between our process and the sales process. A good sales process starts with the end in mind and a good salesperson seeks first to understand. From sales, we know that it’s all about listening and understanding, identifying the problems that need to be solved while understanding that all decisions are emotional.

Architects work with numerous stakeholders that each have different needs, provide different inputs, and can be the sources of different friction points. Navigating this complexity requires a good strategy. A key element of this strategy is where we move from “speaking and advocacy” to “listening and inquiry.”

Resist The Urge To Solve Problems Immediately

Another important aspect of the process is the concept of not solving problems, or at least not jumping to solutions before we fully understand the context. It’s important that we fight the temptation to snap out a solution as soon as we hear a problem because we often miss the context. More importantly, if our proposed solution misses the mark, doesn’t actually solve their problem, or didn’t fit for reasons we failed to uncover, we’ll also lose credibility.

Asking questions to disprove your initial thoughts helps to probe deeper and provide a more comprehensive solution. For example, you might be designing and eCommerce system and planning on implementing an architecture that would enable 1000s of transactions per minute. You could ask a question that achieves confirmation bias, such as “we’d want to be able to support a high transaction volume soon, right?”. The business owner will probably answer “yes” because it’s a leading question. It would be better to structure the question in a way that an answer could disprove your theory, such as “how many transactions do you expect there to be in the first year this is live.” You might find out that the answer is really small and that it’s more important that you go live sooner than take longer to enable a level of scale that is never needed.

Communicating Complex Subjects

There are various techniques for effectively communicating complex subjects that I covered in my talk, but one that I’ll share here is the power of the readback.

We need to be constantly asking questions and making sure that everyone is clear about the terms and phrases that are being used. For instance, a question like the following can help add clarity and avoid potential miscommunication down the road:

“Lean” has a certain meaning in our industry, but what do you mean when you say you have a lean organization?”

In addition, when listening, you can use a couple of simple phrases to verify that you've understood what you've heard. Try these on for size:

"What I hear you saying is..."

"OK, so my understanding is..."

"To summarize, you want to do 3 things..."

Don’t be afraid to say the wrong thing here; it’s more important, especially early on in the process, to be on the same page and to understand the context.

Own Both Understanding and Being Understood

As software architects, we have challenges that align with both sales and project management. Our success often relies on our ability to translate the technical problems (Slow queries, Bad throughput, Server upgrades, Bugs) to the business problems they create (Bad experiences affect retention, Slow browsing leads to dropoff, Users are unable to… etc.) We must be masters of our own communication patterns while also taking on the burden of making sure we’re being understood.

If you’d like to learn more about how we provide customized training for teams, drop us a line here.

Make sense? Great. Now go ahead and read that back to me...

The O’Reilly Software Architecture Conference is a great place for developers, architects, CTOs, development managers, and other members of the tech industry from all over the world to gather and learn from each other. In 2018, the sessions and training covered several key areas, including microservices, distributed systems, cloud-native, enterprise architecture, security, and leadership skills.