In today’s fast-paced digital landscape, the role of a solution architect goes far beyond designing systems — it’s about translating business goals into sustainable, scalable technical strategies. We caught up with Patrik Schrey, one of our seasoned solution architects, to ask him five quick questions about the challenges he faces, how he handles tough conversations, and the frameworks that help him build trust across teams.
What types of requests do you most commonly have to say “no” to in your role as an architect?
Patrik: “One of the most common requests I have to push back on is the idea of migrating a complex application in a single “big-bang” release. While it may sound efficient, it’s rarely realistic. Most of these systems require a phased-release approach to reduce risk and ensure continuity.”
What advice would you give to new architects who are afraid of being labeled “difficult” for pushing back?
Patrik: “Start with “Seek first to understand, then to be understood” — a principle from Stephen Covey. Before pushing back, make sure you’ve fully understood the request and, especially, the scope. Then, explain your reasoning in the stakeholder’s language.
For more complex decisions, I recommend using Architecture Decision Records (ADRs). They help compare options transparently and document the trade-offs, which makes the decision process more collaborative and less personal.”
How do you ensure everyone in the room feels heard — especially when people have different levels of technical understanding?
Patrik: “When everyone is in the same room, I use plain language and avoid technical jargon or abbreviations. Analogies that resonate with a broad audience are key — but I still make sure to address concerns specific to each stakeholder.
If I can organize separate sessions tailored to different stakeholder groups, I adapt the messaging and analogies accordingly. Then I validate that the information shared across sessions remains consistent and aligned.”
How do you maintain trust and collaboration after rejecting an idea or proposal?
Patrik: “Again, it comes back to Covey’s principle — seek first to understand. When people feel truly heard and see that your feedback is based on shared goals, not personal opinions, it’s easier to maintain trust. The key is empathy, clarity, and transparency.”
What helps you uncover what people really mean when they describe a problem or requirement?
Patrik: “I usually start by asking what added value they’re aiming for — or what would be missing if nothing changes. That quickly surfaces the “why” behind the request.
Next, I ask about the scope: is the issue affecting all users or just a specific group? For complex issues, tools like a fishbone diagram help map out potential root causes and bring clarity to what’s actually needed.”
Whether he’s facilitating tough conversations or architecting a multi-phase migration, Patrik’s approach highlights the value of empathy, structure, and clear communication in tech leadership.
Are you also interested in learning more about IT architecture — or ready to take the next step in your career? Check out our job openings: https://www.agilearchitects.be/jobs/
