Talk Like an Architect: How to Use the Building Blocks of Communication

Architecture only works when people understand it.

Effective communication allows architects to bridge the gap between business needs and technical possibilities by creating a shared understanding across both. This essential skill can be the deciding factor in whether a design gets built, is adopted, drives impact, and achieves scalability — or simply gets scrapped. This is what it means to talk like an architect.

While many view architects as the creators of complex blueprints, their true value lies in their ability to translate vision into reality through the power of connection. But in practice, communication is often where architectural intent breaks down. The challenge is rarely the solution itself; it is explaining the thinking behind it to different audiences.

Our new Talk Like an Architect blog mini-series focuses on communication as a core architectural skill. This first post reframes the architect as a “connector” and introduces the foundations of effective communication, setting the stage for deeper dives into visual storytelling and active listening.

Defining an architect

The role of an architect is frequently reduced to a boilerplate definition, such as Merriam-Webster‘s “a person who designs and guides a plan or undertaking.”

Others define architects by their output: diagrams, technical debt assessments, and system landscapes. However, truly effective architects shine through their role as both an expert in their domain and a bridge between that domain and its stakeholders. This is a key part of learning to talk like an architect.

By spanning the different pillars of a project, architects become the “glue” that holds it together. They strive to balance business needs with technical realities and connect all stakeholders to ensure that the final product brings the business value in a technically sound way.

• Business stakeholders know the “why” by:
  • Identifying the use cases, the users, and their specific needs
  • Bringing in relevant subject matter experts to evaluate the “room for change” in a process
  • Assessing the stability and possible unification of business processes, especially across different departments or regions
  • Identifying where the business can adopt out-of-the-box capabilities versus where industry, regional, or company regulations require existing processes
  • Ensuring that the system supports the user’s workflow
• Technical stakeholders are experts in the “how” by:
  • Establishing the technical realities and possibilities of the system
  • Evaluating implementation and maintainability efforts
  • Following or defining best practices and assessing system stability
  • Assessing each requested feature to determine the most appropriate implementation approach based on its specifics
  • Handling features subject to frequent changes, like market evolutions or quarterly processes, differently than tasks that support business as usual

The architect sits in the middle of these stakeholders. Their job is to ensure that the business focus on ease of use, flexibility, and rapid feature delivery aligns with the technology focus on ease of maintenance, scalability, and qualitative improvement throughput.

Architects explain business needs to technology teams and bring technical constraints back to the business to drive collaboration around solution design. They highlight the end user needs or user experience concerns to technology stakeholders, and then bring back risks and mitigation strategies to business stakeholders in an effort to manage the overall implementation. 

Without effective communication skills to interact with these vastly different stakeholders, an architect cannot create the shared understanding needed to build a valuable solution that works for everyone.

Breaking down communication into building blocks

To understand how to effectively communicate and talk like an architect, let’s explore the fundamental building blocks of communication: 

The Sender:

• Represents the person trying to communicate an idea to an audience
• Example: For a blog post, this is the author

The Message:

• Contains the specific information transmitted by the sender
• Conveys core concepts or data to the audience
• Example: The message of this blog post is about the value of communication skills and their importance to architects

The Receiver:

• Is the target audience that the sender intends to reach
• Identifies the people that the sender wants to impact with the message
• Example: For a blog post, this is the reader

The Channel:

• Defines the way the sender delivers the message, such as a blog post, presentation, email, social media post, or Slack message
• Determines the tools at your disposal based on its specific characteristics
• Example: With a blog post, it is not possible for the reader to alter or provide feedback directly into the post’s copy

The Encoding:

• Materializes an idea into tangible communication
• Incorporates the sender’s background, vernacular, and context into the message
• Example: This blog post was written by a non-native English speaking architect and it therefore may include some language-related quirks regarding specific vocabulary, phrases, and expressions

The Decoding:

• Interprets the message through the receiver’s own background
• Influences how the audience understands the transmitted information
• Example: The audience for this blog post includes mixed  experience levels ranging from aspiring to established architect, and likely speaking a host of different languages

The Feedback:

• Provides the verbal or non-verbal response from the receiver
• Helps the sender discern if the message landed well
• Example: Feedback on our blog posts comes in asynchronously through continued conversation on other platforms like LinkedIn

Navigating noise and distractions

Complications often arise during the encoding and decoding phases. Messages often get “lost in translation” due to language barriers or differing professional contexts. Even when the sender and receiver are on the same page, encoding and decoding complications can mix up the message.

For example, think about the last presentation you attended: were you laser focused throughout or did you notice your attention drifting to other things from time to time? Receivers could easily be multitasking while engaging with your message either virtually or in person. They might be reading your document during a meeting, checking Slack while listening to you speak, or even thinking about their weekend plans during your presentation. Because of this, keeping their priorities in mind helps you tailor your communication and retain their attention. 

Ask yourself these:

• Who is my receiver?
• What matters to them?
• What concerns do they have?
• How can I make my message relatable?

Once you know who they are and what they care about, you can use these insights to speak their language. If you’re talking to a business audience, for example, highlight why your solution yields more return on investment. Explain how it lowers the total cost of ownership and delivers faster time to market. Focus on business impact, so your receiver can use this to shape their business case to build your solution.

Engaging your audience through storytelling

Because you are often competing with distractions and noise, your message needs to be more than just accurate. It needs to be engaging. Avoid encoding-decoding complications and keep your receiver’s attention by refining your message in the following ways:

• Use storytelling to create a relatable narrative
• Leverage visual and auditory variation like artifacts and intonation
• Focus on your end-to-end narrative first and bring in details when needed only
• Utilize specific vocabulary related to your receiver, channel, or context

Communication is rarely a single-stream event. Verbal and non-verbal communication often happen simultaneously. 

When using verbal communication skills, treat your business process as your story. Your audience is familiar with this story and understands it, so you can tie your narrative to this process because it has a clear beginning, middle, and end. 

Your story should have one primary goal: solving your stakeholders’ needs.  These needs are your north star and the glue holding all elements of your story together. It’s what your audience cares about most, which keeps them interested.

In your story, too much detail distracts from the goal and the narrative. Save your details for complex or novel concepts. Give more time to details that are essential to the cohesion of your story.

Finally, consider the distractions that your audience might face. You might want to borrow a technique commonly used by comedians: the purposeful repetition or callback. Some key points of your message are important enough to revisit a few times, like a good punchline. If you were to ask your audience to boil down your story into three bullet points, these callbacks would be those points.

Practicing how you talk like an architect

Communication is a muscle that cannot be trained in a vacuum, especially when learning to talk like an architect in real-world scenarios. It requires constant practice and feedback. While it is helpful to observe others, you must find your own style rather than simply emulating a TED talk.

As you refine your voice, remember these three key takeaways:

1. Prioritize communication: Recognize it as the core of the architect’s bridging role
2. Know your components: Keep the message, receiver, and channel in mind at all times
3. Tell your story: Use storytelling techniques to deliver your message in an engaging way

While verbal communication skills are essential, never underestimate the power of non-verbal communication. Words set the stage, but your visual delivery and presence bring the blueprint to life. 

Keep an eye out for the next installment of our Talk Like an Architect mini-series. We’ll dive deep into the world of non-verbal communication and visual storytelling to help you be more intentional with your presence in the room and the visuals you include.