Mechanics of talking. Must-have soft skills of Solutions Architect.

You hear it everywhere: if you want to be a modern Solutions Architect and not get left behind, you must know #GenAI, #DDD, #EventSourcing, #EventStorming, or #EventModelling. That’s only partially true. I’d say it’s half the truth.

The other half—without which you simply won’t succeed—are soft skills.

If you’re not convincing, or confident if you don’t plan what you’re going to say; or if stress completely takes over—then you won’t be effective in the Solutions Architect role.

This article will set you on the path to mastering effective client communication.

Soft skills are just like technical skills: you can improve them. You can reduce stress. It’s not easy—but neither is anything else. Especially if you want to be more than an average Senior Engineer and keep your position safe in the coming years.

Must-have list

Here’s the must-have list of what I find crucial when it comes to the soft skills of a Solutions Architect.

1. Plan what you’re going to say

Don’t wing it.

Structure what you want to present using the STAR framework:

• Situation – What is the current context? What’s the environment? Who are the key actors? This is a recap, so everyone starts on the same page.
• Task – What is the problem or challenge?
• Action – What actions do you propose to solve the problem or improve the situation? This is the place where you can (and should) showcase your expertise.
• Result – What is the goal? What’s the end game? For example:- User conversion will increase by 10%- We will become compliant with standard X- Infrastructure costs will be reduced by €10,000 per year

This way, you speak the language of benefits and present your message in a positive light. The structure makes it easy to follow your reasoning and draw clear conclusions from the context.

2. Start with small talk

It’s worth a try.

Small talk relaxes the atmosphere and lowers tension. For me, it’s also crucial because it allows me to start controlling the situation, which significantly reduces stress. I feel much more comfortable seeing smiles than facing a cold, overly serious tone.

A few ways to make small talk work for you:

• If you don’t know the participants well, check their profiles on LinkedIn or other social media. Learn about their background, current or previous roles, interests, or recent posts. You might discover where they like to travel, whether they have kids or pets, or what they’ve been up to lately.
• Prepare a few light topics in advance. I prefer slightly playful or humorous ones. Example: “Has the snowman you built last week already melted, leaving only the carrot?”

Take notes on what stakeholders share about themselves. It gives you material to follow up on later—and makes people feel heard. Write down things like names and ages of kids, pets’ names, or how they spent the last weekend.

3. Confidence

Confidence is something you can train and apply intentionally. I’ll go even further: it’s something you can convincingly pretend.

If you can’t present your arguments with confidence, you’ll be perceived as untrustworthy. And then—even worse ideas proposed by others may win over yours.

How to boost your confidence:

• Prepare a clear plan for the meeting (See the “Plan what you’re going to say”).
• Anticipate follow-up questions and plan your answers
• Rehearse before the actual meeting
• Invite someone from your team to join you and support
• Sometimes I prepare a few opening paragraphs, write down the more challenging parts of an upcoming meeting, and memorize them. I also keep my notes visible throughout the conversation.
• Be mentally prepared for not following the plan. If you forgot about something, then it’s OK. You can mention that later during the meeting, skip it altogether, or write a follow-up e-mail.
• Remember that you are the expert. You must sound like the expert. Don’t be sorry too much. Don’t mumble. If you’re surprised, say you will get back with the answer later because you need more time to think it through.
• Apply other stress-mitigation techniques described later in this article

4. Talk slowly and clearly

Don’t rush. Your mouth is not a loaded gun, ready to fire words.

What feels obvious or simple to you may not be obvious to your interlocutors (conversers). Stakeholders often move from one meeting to another all day long—they can be tired, distracted, or overloaded with information.

Slow down.

Use pauses. They give others space to process what you’ve said and the opportunity to ask questions.

Before moving on to the next topic, explicitly check whether everything is clear or if anyone needs clarification. These meetings exist for communication and collaboration—not for you to scuttle through your agenda at all costs.

And one more important thing: check your microphone.

If people have already mentioned that your mic causes issues, it means that understanding you requires extra effort. Continuing to use the same setup in future meetings signals a lack of respect for others’ time and attention—and your chances of a productive meeting drop dramatically. People will be annoyed knowing they have to struggle through the same problem again.

Using headphones is also a good idea. They help you catch everything that’s being said—especially when the meeting isn’t in your native language.

4. Listen, and do the recaps. Ask stupid questions!

Let stakeholders talk. Talk and talk some more. That’s good—it means the conversation is productive.

You listen. If needed, turn on auto-generated captions. Take notes. Moderate the discussion.

When you notice a pause or a natural break, summarize what you’ve understood so far. Doing this shows that their words weren’t thrown into the void. Stakeholders feel heard, you appear in control, and—most importantly—everyone gets a second chance to digest the information and spot gaps or inconsistencies.

Chances are, you’ve spent far more time analyzing the technical side of the problem. You likely have a clearer view of feasibility, constraints, and possible solutions. But they are the domain experts. They know the processes inside out—they’ve been working with them for years.

It’s perfectly fine not to know everything. In fact, it’s expected.

Ask about anything you’re unsure of—especially the questions that feel “stupid.” Those are often the most valuable ones. Time and again, they’ve led me to the most insightful and productive conversations.

You can try structured frameworks for that type of conversation, for instnace LAER (Listen-Acknowledge-Explore-Respond).

5. Visuals over text—every time

Walking through dense blocks of text during a meeting—such as written requirements—is rarely effective. People struggle to read and listen at the same time, and you’ll quickly lose their attention.

Instead, I always try to visualize the essence of what we’re discussing—for example, using a Miro board.

I mentioned requirements earlier. My goal there is to understand them by drawing the business process as a flow. You can use any structured technique you like (you know, the ones ending in -Mapping, -Storming, or -Telling), but an informal method is perfectly fine as well.

The point is the outcome: with an initial flow on the board, the core of the requirements is squeezed from an intimidating wall of text. Once that happens, navigating the nuances and complexities of the problem becomes significantly easier—for everyone involved.

See the image below. A simple visual representation of the meeting's agenda will help everyone focus on the essence of the information you need to convey. Most of us prefer this way to an only auditory presentation. There’s a lot of research on this topic, one of which is The Effectiveness of Visual vs. Auditory Presentation of Information on Memory, Hannah L. Edwards of Lindenwood University.

If you want to learn more in terms of designing diagrams with varying roles and needs, you must definitely read Communication Patterns by Jacqui Read.

6. Stress mitigation

The most important thing to understand is this: stress is normal. You can’t make it disappear—and you shouldn’t try. Stress is your ally. It sharpens focus and increases alertness.

The problem starts when stress takes control of you—when it becomes disproportionate to the situation.

The good news? This is a matter of time and training.

I’ve already covered several effective techniques:

• Get to know your conversers before the meeting. Use social media or ask someone from sales who already knows them.
• Prepare a clear plan—for example, using the STAR framework.
• Prepare small-talk topics and practice how to start the conversation. A good opening sets a comfortable tone for the rest of the meeting.
• Memorize the most demanding parts of your presentation.
• Smile. Even if it feels forced at first. Smiling triggers a cascade of positive physiological effects: endorphins (natural painkillers and mood boosters), dopamine (motivation), serotonin (mood regulation), and oxytocin (the “bonding” or “trust” hormone).
• Use pauses and regularly ask whether anyone has questions.
• Speak slowly. Your brain is in high-alert mode and wants to escape. Gently hold it back. By speaking calmly, you signal to your body that there’s no danger.

Here are a few more things that help me personally:

• Consider skipping coffee before an important meeting.
• Use the restroom beforehand to avoid unnecessary physical tension.
• Practice breathing exercises before the meeting—or during it, when you have the space. For example: inhale slowly for three seconds, then exhale for six. Repeat a few times. Shallow, rapid breathing is the worst option—it can lead to hyperventilation and amplify stress.
• Remember to breathe. Seriously.
• During online meetings, try to actually look at your participants. When I don’t retreat into my own head—imagining how people might react—I stay present. Being “here and now” lowers stress and helps me respond more naturally.
• Practice the Jacobson Progressive Muscle Relaxation. Over time, you can learn what the difference is between tense and relaxed muscles and go in “relaxed” mode on demand.

Over time, these practices will rewire your reactions. Your baseline stress level will drop—and stressful situations will start to feel manageable, even familiar.

⭐⭐⭐ Guests

As a matter of soft skills is broad and many different disciplines are in that bag, I asked real experts to contribute to the topic.

⭐ Szymon Waluś. Trainer and practitioner of a trauma-informed approach.

Trainer’s perspective — the human side of architecture

I was invited to write a few words about soft skills in the work of a Solutions Architect. It feels like a natural fit. I hold a Senior EQF Level 5 Trainer certification in social skills, but more importantly, my entire professional path has been focused on developing human competencies — communication, emotional awareness, and working with stress and relationships.

As someone coming from outside the IT environment, the title Solutions Architect sounds very telling to me. I imagine a person whose role is to design solutions in complex environments. And every complex environment that involves people is, by definition, emotional, social, and relational.

This is where soft skills stop being “nice to have” and become mission-critical.

What soft skills really are

In simple terms, soft skills describe how you are with people and with yourself — not what you technically know.

They include:

• communication,
• emotional regulation,
• self-awareness, relationship building, dealing with stress and change.

These skills directly influence how you function in teams, how you make decisions, and how others perceive your expertise. From my experience working with professionals from the IT industry, one thing is very clear: technical competence may get you the role, but soft skills determine how far you will go.

The biological reason soft skills matter

There is a deeper reason why these skills are so crucial. Humans are social beings. Neuroscience consistently confirms that our brains are wired for cooperation, belonging, and social safety. We are, in a sense, “tribal” creatures. This means that in every professional environment — including tech teams — two fundamental human needs are constantly active:

Belonging (symbiosis) – the need to be part of the group

Autonomy (individuality) – the need to express our own ideas and direction

And these needs often create internal tension.

A Solutions Architect constantly operates in this tension:

• Is it safe to propose my idea?
• How will stakeholders react?
• Will this strengthen or threaten my position in the group?

Most of these questions happen below conscious awareness, yet they strongly influence decisions, communication style, and confidence. Soft skills help you navigate this inner dialogue, rather than being unconsciously driven by it.

Why this matters for Solutions Architects

The role of a Solutions Architect naturally includes elements of leadership, influence, and decision-making under uncertainty.

That means success depends not only on technical excellence but also on the ability to:

• communicate ideas clearly,
• regulate stress,
• build trust,
• hold authority without aggression,
• stay present in difficult conversations.

In other words, the “human layer” of architecture is just as real as the technical one.

And the good news is: just like technical skills, these competencies can be trained and developed.

👉 Szymon Waluś

Trainer and practitioner of a trauma-informed approach. I lead body-based experiences and personal development workshops, supporting the growth of body and emotional awareness. Creator of the podcast and personal development program for men “Men’s Nature”.

⭐ Jacqui Read. Lead Technical Architect and author of Communication Patterns (O’Reilly)

The architect’s role is to essentially make other people’s jobs easier. To be a conduit for communication: translating the intent of the business and users into designs and architectures that developers can implement. But this is not a one-way conduit, the impacts from implementation must feed back into architecture and design. To help to understand and implement this concept I created the ACED Model.

The Modern Architect

Communication has always been an important skill for architects, but even more so with the profusion of AI in how we work and within our work.

This is not just because technical skills are being perceived as less valuable (although I think they are now more valuable!). Architects are the people who act as a filter and a guide. Before LLMs, architects took the new idea from the CIO and provided an analysis, options, and a recommendation. They helped the development team to make a decision about a new technology that one of the developers wanted to try. The AI explosion meant this guiding role also exploded.

Now the shareholders, C-suite, product managers, and your uncle, all have an opinion on “AI”: “We need to use AI”, “We must add AI to our product.”, “Everyone is using AI, we must keep up with our competitors!”. And the architect must act as the voice of reason, questioning why. Why do you want to use AI? What outcomes are you looking for? As well as providing that analysis and recommendation.

And to do all that the architect must have good communication skills, as well as technical understanding.

The Technical Architect

AI cannot take the place of an architect (or a developer). LLMs (Large Language Models) - and their associated paraphernalia - are a tool that architects can use to help form ideas and perform research, but they are an unreliable tool. Even replies that contain references have been shown to be wrong, with the references often not backing up the LLM’s claims (if they exist at all).

As LLMs are used to produce more and more code, technical skills are going to be needed even more to review that code and to handle problems with unreviewed code. Tech companies that jumped on the we-don’t-need-as-many-developers-now-we-have-AI bandwagon are now finding they need to re-hire developers they laid off.

Architects play a crucial role in managing LLM code by:

• Setting guidelines and standards for all code, developer or LLM written. Agent files, such as CLAUDE.md are a useful aid, being readable by human and machine.
• Helping in the clear up of LLM-generated code by applying similar tools to those used for rewriting a legacy system. You may not need to completely re-write the system, but skills such as DDD (Domain-Driven Design) will help in these situations.

The Valuable Architect

In a world where technical skills are perceived as less valuable, architects (and developers) need to maintain and improve their soft skills, which are really core skills. Visual, written, verbal and nonverbal communication skills are all important and must be applied to all areas of work, including knowledge management and remote working.

The technical skills of an architect (and developer) are still valuable, and I think those currently on the AI bandwagon will come to realise that eventually. Don’t lose these skills.

Even if LLMs remain accessible to many, your technical skills remain important. But when AI companies come to a point where they need to start making money, rather than spending double or more the revenue they receive to just run the LLM (see Ed Zitron & Cal Newport), your technical and communication skills together will be priceless.

👉 For more from Jacqui check out https://jacquiread.com and her book Communication Patterns.

⭐ Daniel Orzadowski. Consultative Sales Specialist | GTM Strategy | AI-Driven Sales Intelligence.

Every Software Architect is also a salesperson.

The greatest problem in communication is the illusion that it has taken place. – George Bernard Shaw.

Among all the soft skills Artur writes about, the most important one is being certain that communication is actually happening.

Your path in this area can be divided into two stages: the time when you learn post factum (by seeing weak workshop results) and the moment when you begin to consciously orchestrate it.

We all know quite a lot about Solutions Architects. But can you be sure that your story about it truly reflects the day-to-day reality of a workshop participant?

This is a critical point. Although it may seem trivial and dependent on simple research, this is precisely where the line runs between CO-CREATING real change and merely “ticking off” a workshop.

I clearly remember the first time I consciously applied this perspective. I was speaking at a trade fair with a manufacturer of blood coagulation equipment. I wanted to understand his needs regarding custom software.

Instead of talking about technology, I adopted the perspective of a nurse who would need to be trained to use the new equipment. I focused on her resistance to the idea that a mobile application was supposed to “help” her.

It wasn’t improvisation. It was a deliberate effort to stop talking about what I know about software development in the strict healthcare environment—and instead find the point of view from which the client, or the client’s client, looks at the process.

If you’d like to systematize your knowledge about this skill, I recommend two books:

“Supercommunicators” – Charles Duhigg.

“Metaphors We Live By” – G. Lakoff, M. Johnson (if you prefer a more technical approach to language).

And a small request to all of us: run workshops diligently. For us in sales, solid architecture is the guarantee that we’re selling a robust product—not “the carrot left over from a snowman” (referring to Artur’s joke).

👉 Daniel Orzadowski

Closing words

There are countless books explaining what it means to be a Solutions Architect. Yet none of them tell you the most important truth: technical skills are only half of your job.

Don’t think of yourself as the one exception who can’t grow in soft skills. That’s simply not true. It’s possible — it’s just a demanding road.

See you next time 👋