Founder & CEO @ Lever Talent | Host of The Lever Show | Helping leaders develop talent strategies that leverage a tech-empowered future.

You’re capable of more than you could ever imagine.

I started my career impatient, driven, and a little naive. In my mid-20s, I was sprinting up the corporate ladder… and got fired.  

That moment forced me to get honest about what actually changes a team: clarity, standards, and the courage to hold them.

My belief is simple: as AI and automation take more transactions, the human work matters more. Technology multiplies what’s already there (judgment, trust, focus). Software doesn’t change a team. Cadence does.

In 2022, I followed that belief and started Lever Talent. I work with CHROs, CPOs, and HR or L&D leaders to align talent with the business so teams get better because of technology instead of being buried by it. We make it practical:

• Lead with Leverage: a manager cadence that makes expectations real (and conversations easier)
• MVV that sticks: values → rituals → behavior change
• AI, but usable: 30-60-90 change plans that turn pilots into ROI
• People-ops command center: fewer dashboards, better decisions

With technology, our leverage is limitless. Let’s build teams that prove it.

DM me to get in touch.

Drew Fortin

With extensive experience in IT Technology Leadership, Enterprise Architecture, and IT Management, I have committed my career to advancing innovation and driving impactful transformation. As a Technology Architect at IAG Transform, I play a critical role in shaping digital transformation, aligning technology strategies with business goals, and implementing innovative, scalable solutions.

My expertise lies in navigating the complexities of enterprise IT to deliver secure, maintainable, and future-ready systems that meet strategic objectives. I am passionate about harnessing digital capabilities to redefine business landscapes, fostering agility, innovation, and sustainable growth.

Beyond technical expertise, I excel at building strong relationships, influencing stakeholders, and promoting best practices to ensure excellence in digital solutions. My leadership is driven by a dedication to bridging the gap between technology and business, empowering organizations to achieve their strategic vision.

Nadzeya Stalbouskaya

𝗧𝗵𝗲 𝟴 𝗧𝘆𝗽𝗲𝘀 𝗼𝗳 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘀 𝗬𝗼𝘂 𝗠𝗲𝗲𝘁 𝗶𝗻 𝗘𝘃𝗲𝗿𝘆 𝗖𝗼𝗺𝗽𝗮𝗻𝘆
After spending years working in enterprise architecture, I’ve started noticing something funny.

Almost every company seems to have the same types of architects.
Different industries. Different technology stacks. Different cultures.
But somehow the characters are always the same.

You probably know a few of them.

𝗧𝗵𝗲 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝗘𝘃𝗮𝗻𝗴𝗲𝗹𝗶𝘀𝘁.
Knows every page of TOGAF, Zachman, and every possible reference model. If a problem appears, the answer is usually “we should align this with the framework.”

𝗧𝗵𝗲 𝗗𝗶𝗮𝗴𝗿𝗮𝗺 𝗔𝗿𝘁𝗶𝘀𝘁.
Produces beautiful architecture diagrams. Layers are perfect. Colors are balanced. The slides look amazing. Sometimes the organization still tries to understand what problem the diagram actually solved.

𝗧𝗵𝗲 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗙𝗶𝗿𝗲𝗳𝗶𝗴𝗵𝘁𝗲𝗿.
Always busy. Always fixing something. Usually appears when two systems that “should have been integrated long ago” suddenly need to talk to each other tomorrow.

𝗧𝗵𝗲 𝗚𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝗚𝘂𝗮𝗿𝗱𝗶𝗮𝗻.
Knows every standard, every principle, every approval process. If something violates the architecture principles, this person will definitely notice.

𝗧𝗵𝗲 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗼𝗿.
One of the rare people who can sit with business leaders and explain complex technical topics in simple language. Often underestimated, but incredibly valuable.

𝗧𝗵𝗲 𝗦𝗵𝗮𝗱𝗼𝘄 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁.
Officially not an architect. But everyone quietly asks them for advice before making important decisions. Their influence is larger than their title.

𝗧𝗵𝗲 𝗟𝗲𝗴𝗮𝗰𝘆 𝗦𝘆𝘀𝘁𝗲𝗺 𝗪𝗵𝗶𝘀𝗽𝗲𝗿𝗲𝗿.
The only person who truly understands that one critical system built 20 years ago. No documentation exists. If they leave, the system becomes a mystery.

𝘈𝘯𝘥 𝘧𝘪𝘯𝘢𝘭𝘭𝘺... 𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁.

Not the loudest person in the room.
Not the one with the most slides.

But the one who quietly connects technology decisions with business outcomes, reduces complexity, and helps the organization move forward.

In my experience, good architecture teams actually need a mix of these personalities.

𝘞𝘩𝘪𝘤𝘩 𝘵𝘺𝘱𝘦 𝘥𝘰 𝘺𝘰𝘶 𝘴𝘦𝘦 𝘮𝘰𝘴𝘵 𝘰𝘧𝘵𝘦𝘯 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯? 𝘈𝘯𝘥 𝘸𝘩𝘪𝘤𝘩 𝘰𝘯𝘦 𝘥𝘰 𝘺𝘰𝘶 𝘵𝘩𝘪𝘯𝘬 𝘪𝘴 𝘵𝘩𝘦 𝘳𝘢𝘳𝘦𝘴𝘵?

#EnterpriseArchitecture #ArchitectureLeadership #TechHumor #ITArchitecture

Technology Architect at IAG Transform | Architecture Debt Advocate | Enterprise Architecture | Data & AI & Innovation | Digital Transformation

No alternative text description for this image

𝗧𝗵𝗲 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘀 𝗔𝘀𝗸 𝗧𝗵𝗮𝘁 𝗡𝗼𝗯𝗼𝗱𝘆 𝗟𝗶𝗸𝗲𝘀
Over time I noticed something interesting about architecture meetings.
The hardest questions are rarely technical. They are simple. But they make people uncomfortable because they reveal things organizations prefer not to see.

Here are a few questions architects often ask and why they matter.

𝟭. 𝗪𝗵𝗼 𝗼𝘄𝗻𝘀 𝘁𝗵𝗶𝘀 𝘀𝘆𝘀𝘁𝗲𝗺?
This question often reveals that ownership is unclear or shared between several teams. People don’t like it because it forces accountability. But without ownership, every system eventually becomes someone else’s problem.

𝟮. 𝗪𝗵𝘆 𝗱𝗼 𝘄𝗲 𝗵𝗮𝘃𝗲 𝘁𝗵𝗿𝗲𝗲 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀 𝗱𝗼𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘁𝗵𝗶𝗻𝗴?
This question touches politics. Every platform has history, budget, and supporters. But duplication quietly increases cost, integration effort, and confusion.

𝟯. 𝗜𝘀 𝘁𝗵𝗶𝘀 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗿𝗲𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱𝗲𝗱?
Integrations look great on diagrams, but every new connection adds complexity. Sometimes the integration exists simply because no one asked whether it creates real value.

𝟰. 𝗪𝗵𝗮𝘁 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗮𝗿𝗲 𝘄𝗲 𝘀𝗼𝗹𝘃𝗶𝗻𝗴?
This question can stop a meeting. Projects often start with solutions instead of clearly defined problems.

𝟱. 𝗪𝗵𝗼 𝘄𝗶𝗹𝗹 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻 𝘁𝗵𝗶𝘀 𝗶𝗻 𝘁𝘄𝗼 𝘆𝗲𝗮𝗿𝘀?
Everyone likes building new things. Fewer people think about long-term support. Many elegant solutions fail because no one planned maintenance.

𝟲. 𝗪𝗵𝗲𝗿𝗲 𝗶𝘀 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗰𝗼𝗺𝗶𝗻𝗴 𝗳𝗿𝗼𝗺?
This question quickly leads to deeper issues like data quality, ownership, and trust.

𝟳. 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗶𝗳 𝘁𝗵𝗶𝘀 𝗳𝗮𝗶𝗹𝘀?
Distributed systems fail. APIs fail. Dependencies fail. Good architecture assumes failure and plans for it.

𝟴. 𝗖𝗮𝗻 𝘄𝗲 𝘀𝗶𝗺𝗽𝗹𝗶𝗳𝘆 𝗶𝘁?
Possibly the most uncomfortable question. Complex solutions look impressive. But simplicity is often the real sophistication.

Architects ask these questions not to slow projects down, but to prevent hidden complexity.

And complexity, once it grows, becomes very expensive.

𝘞𝘩𝘪𝘤𝘩 𝘰𝘧 𝘵𝘩𝘦𝘴𝘦 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯𝘴 𝘤𝘳𝘦𝘢𝘵𝘦𝘴 𝘵𝘩𝘦 𝘮𝘰𝘴𝘵 𝘵𝘦𝘯𝘴𝘪𝘰𝘯 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘮𝘦𝘦𝘵𝘪𝘯𝘨𝘴? 𝘞𝘩𝘪𝘤𝘩 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯 𝘩𝘢𝘴 𝘴𝘢𝘷𝘦𝘥 𝘢 𝘱𝘳𝘰𝘫𝘦𝘤𝘵 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦?

#EnterpriseArchitecture #ArchitecturePractice #TechLeadership #ITStrategy

First, the idea that AI adoption would automatically lead to productivity gains.
Sources:
https://www.gartner.com/en/articles/ai-value-realization
https://mitsloan.mit.edu/ideas-made-to-matter/why-ai-doesnt-automatically-make-teams-more-productive

Second, predictions around “autonomous enterprises” proved overly optimistic.
Source:
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Third, the expectation that governance would become lighter with smarter technology did not hold.
Source:
https://www.weforum.org/agenda/ai-governance/

https://www.pcquest.com/tech-explained/is-your-enterprise-architecture-ready-for-ai-10944385

𝗙𝗿𝗼𝗺 𝗖𝗵𝗮𝗼𝘀 𝘁𝗼 𝗜𝗻𝘃𝗶𝘀𝗶𝗯𝗹𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. 𝗪𝗵𝗲𝗿𝗲 𝗜𝘀 𝗬𝗼𝘂𝗿 𝗖𝗼𝗺𝗽𝗮𝗻𝘆 𝗼𝗻 𝗧𝗵𝗶𝘀 𝗦𝗰𝗮𝗹𝗲?
Over the years I’ve seen many architecture maturity models.
They are usually very structured.
Very precise.
And very optimistic.

But if we are honest about how organizations actually evolve, the path often looks a bit different. 𝖲𝗈𝗆𝖾𝗍𝗁𝗂𝗇𝗀 𝗅𝗂𝗄𝖾 𝗍𝗁𝗂𝗌.

𝗟𝗲𝘃𝗲𝗹 𝟭 — 𝗖𝗵𝗮𝗼𝘀. Systems grow organically. Everyone solves problems locally. Documentation is rare. Integration happens when something breaks.

𝗟𝗲𝘃𝗲𝗹 𝟮 — 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗲𝗱 𝗰𝗵𝗮𝗼𝘀. The architecture team arrives. Diagrams appear. Confluence pages grow. The landscape is finally documented... but still chaotic.

𝗟𝗲𝘃𝗲𝗹 𝟯 — 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗰𝗵𝗮𝗼𝘀. Some standards start appearing. Projects begin asking for architecture reviews. Not everything follows the rules, but at least people know they exist.

𝗟𝗲𝘃𝗲𝗹 𝟰 — 𝗚𝗼𝘃𝗲𝗿𝗻𝗲𝗱 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. Principles are defined. Decision processes exist. Exceptions are tracked. Architecture starts influencing delivery.

𝗟𝗲𝘃𝗲𝗹 𝟱 — 𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴. Teams stop building everything from scratch. Reuse becomes intentional. Shared capabilities appear.

𝗟𝗲𝘃𝗲𝗹 𝟲 — 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗮𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁. Technology discussions start with business capabilities and outcomes, not tools and systems.

𝗟𝗲𝘃𝗲𝗹 𝟳 — 𝗗𝗮𝘁𝗮-𝗱𝗿𝗶𝘃𝗲𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. Decisions rely on measurable insight. Data products, analytics, and AI begin shaping how the organization operates.

𝗟𝗲𝘃𝗲𝗹 𝟴 — 𝗜𝗻𝘃𝗶𝘀𝗶𝗯𝗹𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. This is the interesting one.

At this stage, architecture becomes almost invisible. Systems are coherent. Decisions are predictable. Teams know the guardrails. People move fast without constant architectural intervention.

In other words, architecture works so well that no one talks about it anymore.

Personally, I think most organizations oscillate between levels 2, 3, and 4 for quite a long time. And that is perfectly normal. Architecture maturity is not a straight line. It is more like a staircase with occasional slides backwards.

𝘞𝘩𝘦𝘳𝘦 𝘥𝘰 𝘺𝘰𝘶 𝘵𝘩𝘪𝘯𝘬 𝘮𝘰𝘴𝘵 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴 𝘳𝘦𝘢𝘭𝘪𝘴𝘵𝘪𝘤𝘢𝘭𝘭𝘺 𝘴𝘪𝘵 𝘵𝘰𝘥𝘢𝘺? 𝘈𝘯𝘥 𝘩𝘢𝘷𝘦 𝘺𝘰𝘶 𝘦𝘷𝘦𝘳 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦𝘥 𝘓𝘦𝘷𝘦𝘭 8 𝘪𝘯𝘷𝘪𝘴𝘪𝘣𝘭𝘦 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘪𝘯 𝘱𝘳𝘢𝘤𝘵𝘪𝘤𝘦?

#EnterpriseArchitecture #ArchitectureStrategy #PlatformThinking #DigitalTransformation

𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗜𝘀 𝗡𝗼𝘁 𝗔𝗯𝗼𝘂𝘁 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀. 𝗜𝘁’𝘀 𝗔𝗯𝗼𝘂𝘁 𝗖𝗼𝗻𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝘀.
Stop obsessing over the shiniest new tool.
𝚂𝚎𝚛𝚒𝚘𝚞𝚜𝚕𝚢.

If you call yourself an enterprise architect and your first instinct is to talk about which cloud vendor is superior, you're already missing the point.

I've seen too many architects go down the rabbit hole of specs, platforms, and frameworks. Hours spent debating monoliths vs microservices, diagramming for the sake of diagramming, name-dropping acronyms like they're going out of style. 

Guess what? None of it matters unless it moves the business forward.

You know what gets leadership's attention? Revenue. Growth. Customer happiness. That last one, you can't buy with a new API.

Here's the brutal truth: No boardroom ever asked, "𝘏𝘰𝘸 𝘮𝘢𝘯𝘺 𝘤𝘰𝘯𝘵𝘢𝘪𝘯𝘦𝘳𝘴 𝘤𝘢𝘯 𝘸𝘦 𝘴𝘱𝘪𝘯 𝘶𝘱?" 𝘞𝘩𝘢𝘵 𝘵𝘩𝘦𝘺 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘬𝘯𝘰𝘸 𝘪𝘴, "𝘏𝘰𝘸 𝘥𝘰𝘦𝘴 𝘵𝘩𝘪𝘴 𝘵𝘦𝘤𝘩 𝘩𝘦𝘭𝘱 𝘶𝘴 𝘴𝘦𝘭𝘭 𝘮𝘰𝘳𝘦, 𝘸𝘰𝘳𝘬 𝘧𝘢𝘴𝘵𝘦𝘳, 𝘰𝘳 𝘤𝘳𝘶𝘴𝘩 𝘵𝘩𝘦 𝘤𝘰𝘮𝘱𝘦𝘵𝘪𝘵𝘪𝘰𝘯?"

So if you want your seat at the table, stop treating technology as the hero.

𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵:
1. The business problem , not the tech fix.
2. The outcome , not the output.
3. The story , not the specs.

Let everyone else chase trends. You should be chasing business results. That's how you get invited to the real meetings.

Most tech conversations are just noise. Being obsessed with outcomes? That's how you deliver real value.

𝘙𝘦𝘢𝘥𝘺 𝘵𝘰 𝘮𝘢𝘬𝘦 𝘵𝘩𝘦 𝘴𝘩𝘪𝘧𝘵? 𝘖𝘳 𝘴𝘵𝘪𝘭𝘭 𝘴𝘵𝘶𝘤𝘬 𝘪𝘯 𝘵𝘩𝘦 𝘵𝘦𝘤𝘩 𝘦𝘤𝘩𝘰 𝘤𝘩𝘢𝘮𝘣𝘦𝘳?

#EnterpriseArchitecture #BusinessTransformation #OutcomeDriven

𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 𝗟𝗼𝗼𝗸 𝗟𝗶𝗸𝗲 𝘁𝗵𝗲 𝗙𝘂𝘁𝘂𝗿𝗲. 𝗜𝗻 𝗥𝗲𝗮𝗹𝗶𝘁𝘆, 𝗧𝗵𝗲𝘆 𝗥𝗲𝗾𝘂𝗶𝗿𝗲 𝗮 𝗠𝗮𝘁𝘂𝗿𝗶𝘁𝘆 𝗠𝗼𝘀𝘁 𝗢𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝘀 𝗗𝗼𝗻’𝘁 𝗛𝗮𝘃𝗲
AI agents are everywhere right now. Autonomous decisions. “Systems that act on their own.”

The idea is attractive. The reality is much harder.

From my experience, the main problem with AI agents is not the technology.
It’s the organizational and architectural immaturity around them.

Before we talk about autonomy, there are very basic questions that often have no answer:
𝘞𝘩𝘦𝘳𝘦 𝘢𝘳𝘦 𝘵𝘩𝘦 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘣𝘰𝘶𝘯𝘥𝘢𝘳𝘪𝘦𝘴?
𝘞𝘩𝘰 𝘪𝘴 𝘢𝘭𝘭𝘰𝘸𝘦𝘥 𝘵𝘰 𝘰𝘷𝘦𝘳𝘳𝘪𝘥𝘦 𝘵𝘩𝘦 𝘢𝘨𝘦𝘯𝘵?
𝘏𝘰𝘸 𝘥𝘰 𝘸𝘦 𝘳𝘰𝘭𝘭 𝘢𝘤𝘵𝘪𝘰𝘯𝘴 𝘣𝘢𝘤𝘬?
𝘞𝘩𝘰 𝘪𝘴 𝘢𝘤𝘤𝘰𝘶𝘯𝘵𝘢𝘣𝘭𝘦 𝘸𝘩𝘦𝘯 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 𝘨𝘰𝘦𝘴 𝘸𝘳𝘰𝘯𝘨?

In many companies, these questions are unclear even for human decision-making.
This leads to one uncomfortable but important conclusion.
AI agents without architecture do not create efficiency. They automate chaos.

𝟭. 𝗔𝘂𝘁𝗼𝗻𝗼𝗺𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝗶𝗲𝘀 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝗶𝗻𝘃𝗶𝘀𝗶𝗯𝗹𝗲 𝗿𝗶𝘀𝗸
Agents operate fast and confidently. If decision limits are unclear, they don’t pause.
They execute and amplify every structural weakness in the system.

𝟮. 𝗖𝗼𝗻𝘁𝗿𝗼𝗹, 𝗿𝗼𝗹𝗹𝗯𝗮𝗰𝗸, 𝗮𝗻𝗱 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗮𝗿𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀
Kill switches, escalation paths, auditability, and monitoring are not “AI features”.
They are design decisions. Without them, autonomy becomes operational fragility.

𝟯. 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝗱𝗲𝗹𝗲𝗴𝗮𝘁𝗲𝗱 𝘁𝗼 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲
When something fails, “the agent decided” is not an answer. Ownership, governance, and accountability must exist before autonomy, not after.

This is why agent-based solutions often look impressive in demos
and become dangerous in production.

AI agents may well be part of the future. But only in organizations mature enough to hold them.

𝘐𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯, 𝘸𝘩𝘰 𝘪𝘴 𝘢𝘤𝘤𝘰𝘶𝘯𝘵𝘢𝘣𝘭𝘦 𝘧𝘰𝘳 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯𝘴 𝘮𝘢𝘥𝘦 𝘣𝘺 𝘈𝘐 𝘢𝘨𝘦𝘯𝘵𝘴? 𝘈𝘳𝘦 𝘺𝘰𝘶𝘳 𝘢𝘨𝘦𝘯𝘵𝘴 𝘵𝘳𝘦𝘢𝘵𝘦𝘥 𝘢𝘴 𝘳𝘦𝘢𝘭 𝘤𝘢𝘱𝘢𝘣𝘪𝘭𝘪𝘵𝘪𝘦𝘴 𝘰𝘳 𝘴𝘵𝘪𝘭𝘭 𝘢𝘴 𝘦𝘹𝘱𝘦𝘳𝘪𝘮𝘦𝘯𝘵𝘴?

#EnterpriseArchitecture #ArtificialIntelligence #ArchitectureDebt #SystemsThinking

undefined undefined

𝗪𝗵𝗲𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗗𝗲𝗯𝘁 𝗧𝘂𝗿𝗻𝘀 𝗜𝗻𝘁𝗼 𝗢𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗙𝗲𝗮𝗿
here is a moment in many organizations that nobody names directly.
It’s the moment when change becomes uncomfortable not because the idea is bad, but because the system underneath feels fragile. And slowly, without anyone announcing it, the company starts building a culture of caution around its own architecture.

Here is the thesis I want to push:
𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗱𝗲𝗯𝘁 𝗲𝘃𝗲𝗻𝘁𝘂𝗮𝗹𝗹𝘆 𝘁𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝘀 𝗶𝗻𝘁𝗼 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗳𝗲𝗮𝗿. 𝗧𝗵𝗲 𝗺𝗼𝗿𝗲 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗱𝗲𝗯𝘁 𝘆𝗼𝘂 𝗮𝗰𝗰𝘂𝗺𝘂𝗹𝗮𝘁𝗲, 𝘁𝗵𝗲 𝗹𝗼𝘄𝗲𝗿 𝘆𝗼𝘂𝗿 𝗿𝗲𝗮𝗹 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗳𝗼𝗿 𝗰𝗵𝗮𝗻𝗴𝗲.

At first, architecture debt looks technical. A few integrations that are not clean. Some legacy components. A data landscape that grew faster than governance. Nothing dramatic. Everything is still running.

But complexity compounds. Dependencies multiply. Institutional knowledge fragments. Over time, fewer and fewer people understand the full impact of touching core systems. And that’s when behavior shifts.

Teams stop proposing deep changes.
Product avoids the platform layer.
Innovation gets redirected to the edges.

No one says, “We’re afraid of the system.”
Instead, we say:
“We need to protect stability.”
“Let’s control risk.”
“Now is not the right time to refactor.”

And to be fair, sometimes that is responsible thinking. But sometimes it is architectural exhaustion disguised as maturity.

I’ve seen companies where every significant initiative begins with weeks of dependency mapping, impact assessments, and escalation calls not because governance is strong, but because no one trusts the structural integrity of the landscape. Innovation becomes heavy. Not impossible, just expensive in emotional and political capital.

This is how architecture debt kills innovation. Not with outages. Not with dramatic failures. But by making experimentation feel dangerous.

And here is the uncomfortable part.

If “let’s not touch that” becomes a reflex in your organization, that is not a sign of stability. It may be a sign of accumulated architectural fragility.

Stability and resilience are not the same thing. A system that cannot be safely changed is not stable. It is brittle.

So here is the question I want to put on the table:
If every major change conversation in your company begins with defensive impact analysis rather than value discussion, is that governance maturity or is it structural fear?

And one more, slightly sharper:
Are your teams avoiding core systems because they are strategically optimized or because they are too risky to challenge?

Architecture debt is not just about systems. It is about the psychological confidence an organization has in its own structure. When that confidence erodes, ambition shrinks.

#ArchitectureDebt #EnterpriseArchitecture #Innovation #DigitalTransformation

𝗧𝗵𝗲 𝗠𝗼𝘀𝘁 𝗨𝗻𝗱𝗲𝗿𝗿𝗮𝘁𝗲𝗱 𝗦𝗸𝗶𝗹𝗹 𝗶𝗻 𝗖𝗼𝗿𝗽𝗼𝗿𝗮𝘁𝗲 𝗟𝗶𝗳𝗲: 𝗧𝗵𝗲 𝗔𝗯𝗶𝗹𝗶𝘁𝘆 𝗡𝗼𝘁 𝘁𝗼 𝗥𝗲𝗮𝗰𝘁
In my early career, I reacted to everything.
Every sharp comment in a meeting. Every late message. Every “urgent” escalation. Every change in tone from leadership.

I thought being fast meant being professional. I thought reacting immediately meant being strong.
Over time, I realised something uncomfortable.

The people with the most influence in the room were rarely the fastest to speak. They were the calmest.

A few years ago, during a tense architecture discussion, someone openly criticised a decision I was responsible for. My first instinct was to defend it immediately. I felt it physically. But I paused. I listened. I asked one question instead of five arguments.

The conversation shifted. Not because I won. But because I didn’t escalate.
That moment changed how I see professional maturity.

𝗡𝗼𝘁 𝗿𝗲𝗮𝗰𝘁𝗶𝗻𝗴 𝗶𝘀 𝗻𝗼𝘁 𝘄𝗲𝗮𝗸𝗻𝗲𝘀𝘀. 𝗜𝘁 𝗶𝘀 𝗰𝗼𝗻𝘁𝗿𝗼𝗹.
In corporate environments, speed is often confused with strength. But emotional discipline creates authority. 
When you don’t react impulsively, you choose your position instead of protecting your ego.

𝗘𝘃𝗲𝗿𝘆 𝗿𝗲𝗮𝗰𝘁𝗶𝗼𝗻 𝗵𝗮𝘀 𝗮 𝗰𝗼𝘀𝘁.
Defensiveness creates tension. Immediate responses create noise. Escalation creates fatigue.
Sometimes the most strategic move is silence. Or a delayed response. Or one calm question.
Not everything deserves your energy.

𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗯𝘂𝗶𝗹𝗱𝘀 𝘁𝗿𝘂𝘀𝘁 𝗳𝗮𝘀𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗯𝗿𝗶𝗹𝗹𝗶𝗮𝗻𝗰𝗲.
In leadership, architecture, strategy people don’t follow the loudest voice.
They follow the most stable one.
When others panic and you stay grounded, you become a reference point.
And that changes how you are perceived.

Today, I measure myself not by how quickly I respond, but by how consciously I choose to.
Because maturity in corporate life is not about knowing more.
It’s about reacting less.

𝘞𝘩𝘢𝘵 𝘴𝘪𝘵𝘶𝘢𝘵𝘪𝘰𝘯𝘴 𝘵𝘳𝘪𝘨𝘨𝘦𝘳 𝘺𝘰𝘶 𝘵𝘩𝘦 𝘮𝘰𝘴𝘵 𝘢𝘵 𝘸𝘰𝘳𝘬? 𝘋𝘰 𝘺𝘰𝘶 𝘵𝘩𝘪𝘯𝘬 𝘴𝘪𝘭𝘦𝘯𝘤𝘦 𝘪𝘴 𝘢 𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘺 𝘰𝘳 𝘢 𝘳𝘪𝘴𝘬?

#Leadership #ProfessionalGrowth #EmotionalIntelligence #WorkplaceCulture

𝗧𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗼𝗳 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀. 𝗪𝗵𝘆 𝗦𝗼𝗺𝗲 𝗖𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀 𝗠𝗼𝘃𝗲 𝗙𝗮𝘀𝘁𝗲𝗿 𝗧𝗵𝗮𝗻 𝗢𝘁𝗵𝗲𝗿𝘀
One thing I’ve started noticing more and more in large organizations is that the slowest system is rarely technology.

𝗜𝘁’𝘀 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻-𝗺𝗮𝗸𝗶𝗻𝗴.

Infrastructure can scale. Cloud platforms can scale. Data pipelines can scale. But decisions often cannot.

I once participated in a program where the technical architecture was actually quite solid. The teams were strong, the technology stack was modern, and the data platform was well designed. But every cross-domain change required weeks of alignment. Ownership was unclear. Escalations moved slowly. People hesitated to take responsibility for decisions that affected multiple teams.

Nothing was technically broken.But the organization moved slowly.
That experience made me think about architecture in a slightly different way.

Architecture is not only about systems and platforms. It is also about how quickly an organization can make coherent decisions across complexity.

If the architecture creates too many dependencies, every decision becomes negotiation. If ownership is unclear, every decision becomes escalation. If governance is weak, every decision becomes debate.

And suddenly the biggest bottleneck in the system is not technology.
It’s organizational architecture. I sometimes call this decision latency. The delay between recognizing a problem and actually agreeing on a change.

Interestingly, the companies that move fastest are not always the ones with the newest technology. They are the ones where responsibility boundaries are clear and decision paths are short.
Architecture shapes that more than we often admit.

𝘞𝘩𝘢𝘵 𝘴𝘭𝘰𝘸𝘴 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯𝘴 𝘵𝘩𝘦 𝘮𝘰𝘴𝘵 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯 𝘵𝘰𝘥𝘢𝘺?
𝘛𝘦𝘤𝘩𝘯𝘰𝘭𝘰𝘨𝘺 𝘤𝘰𝘮𝘱𝘭𝘦𝘹𝘪𝘵𝘺, 𝘨𝘰𝘷𝘦𝘳𝘯𝘢𝘯𝘤𝘦 𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦𝘴, 𝘰𝘳 𝘶𝘯𝘤𝘭𝘦𝘢𝘳 𝘰𝘸𝘯𝘦𝘳𝘴𝘩𝘪𝘱?
𝘈𝘯𝘥 𝘩𝘢𝘷𝘦 𝘺𝘰𝘶 𝘦𝘷𝘦𝘳 𝘮𝘦𝘢𝘴𝘶𝘳𝘦𝘥 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘭𝘢𝘵𝘦𝘯𝘤𝘺 𝘢𝘴 𝘱𝘢𝘳𝘵 𝘰𝘧 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘮𝘢𝘵𝘶𝘳𝘪𝘵𝘺?

#EnterpriseArchitecture #ArchitectureLeadership #TechnologyStrategy #DigitalTransformation

𝗟𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽, 𝗖𝘂𝗹𝘁𝘂𝗿𝗲, 𝗮𝗻𝗱 𝗚𝗿𝗲𝗮𝘁 𝗖𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻𝘀 𝗶𝗻 𝗟𝗼𝗻𝗱𝗼𝗻
Yesterday evening I had the pleasure of attending the London Tech Leaders event “𝗨𝘀𝗶𝗻𝗴 𝗖𝘂𝗹𝘁𝘂𝗿𝗲 𝗮𝘀 𝗮 𝗟𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝗧𝗼𝗼𝗹.

It was one of those events that reminds you how important professional communities really are. Sophie Valentine Sam Burrows Manogna Machiraju Lacey Firestone Joanna Crown

Great people, open conversations, and many honest discussions about leadership, culture, and how organizations actually function behind the scenes. Not the polished conference slides, but real experience from people building and leading teams every day.

A big thank you to the organizers for creating such a welcoming and thoughtful environment. Events like this require a lot of invisible work, and it truly showed. The discussions were engaging, the atmosphere was warm, and the energy in the room was fantastic.

It was also a real pleasure meeting so many interesting professionals. I always enjoy these moments when conversations quickly move from introductions to deeper topics leadership challenges, organizational dynamics, and the realities of building effective teams.

One thing that stood out to me during the evening was how often culture came up not as a soft topic, but as a real leadership tool. Technology strategies often look great on paper, but without the right culture, even the best ideas struggle to work in practice.

In many ways it reminded me of architecture discussions as well. Frameworks, platforms, and processes matter, but people and culture often determine whether those ideas actually succeed.

Thank you again to everyone who organized, spoke, and participated in the event. It was a pleasure to be there and to meet so many inspiring people.

𝘋𝘰 𝘺𝘰𝘶 𝘢𝘵𝘵𝘦𝘯𝘥 𝘵𝘦𝘤𝘩 𝘤𝘰𝘮𝘮𝘶𝘯𝘪𝘵𝘺 𝘦𝘷𝘦𝘯𝘵𝘴 𝘳𝘦𝘨𝘶𝘭𝘢𝘳𝘭𝘺? 𝘞𝘩𝘢𝘵 𝘮𝘢𝘬𝘦𝘴 𝘢𝘯 𝘦𝘷𝘦𝘯𝘵 𝘵𝘳𝘶𝘭𝘺 𝘷𝘢𝘭𝘶𝘢𝘣𝘭𝘦 𝘧𝘰𝘳 𝘺𝘰𝘶 𝘵𝘩𝘦 𝘴𝘱𝘦𝘢𝘬𝘦𝘳𝘴, 𝘵𝘩𝘦 𝘥𝘪𝘴𝘤𝘶𝘴𝘴𝘪𝘰𝘯𝘴, 𝘰𝘳 𝘵𝘩𝘦 𝘱𝘦𝘰𝘱𝘭𝘦 𝘺𝘰𝘶 𝘮𝘦𝘦𝘵?

#TechLeadership #LondonTech #Leadership #TechCommunity

London Tech Leaders

Product leader shaping meaningful innovation in digital health

Strategic Technologist | Transformation Advisor | Executive Leader | High Performance Advocate | Execution & Delivery | GenAI & AI Enthusiast | DEI Advocate

Head of Engineering | Speaker

Technology Services Managing Partner, VP | Speaker | Mentor | DE&I Advocate | Experience Enthusiast | Former Chief of Staff

Director of Data & AI @ Moonpig | Data & Product Leader | ML & AI | Passionate about Responsible Technologies

𝗔𝗯𝗼𝘂𝘁 𝘁𝗵𝗲 𝗽𝗲𝗼𝗽𝗹𝗲 𝘄𝗵𝗼 𝗷𝘂𝘀𝘁 𝗱𝗼 𝘁𝗵𝗲𝗶𝗿 𝘄𝗼𝗿𝗸 𝗮𝗻𝗱 𝗱𝗼𝗻’𝘁 𝗯𝘂𝗶𝗹𝗱 𝗮 𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗯𝗿𝗮𝗻𝗱
I have worked with architects and technology leaders who never posted a single thought online. No articles. No threads. No “lessons learned”. And yet, when something truly complex broke, everyone knew exactly who to call.

These people rarely speak the most in meetings. They don’t optimise visibility. They don’t carefully curate their image. They simply know their domain deeply. They understand consequences. They see risk before it materialises. And they carry responsibility without broadcasting it.

In architecture, especially, this kind of quiet competence is powerful.

At the same time, I work in a world where visibility matters. Conferences. Articles. LinkedIn discussions. Influence shapes perception. And perception shapes opportunity.

So I live in this tension myself.

I build visibility. I write. I speak. I position ideas. But I also know this truth from experience:

Some of the strongest professionals I’ve met have almost no personal brand.

A few years ago, during a major transformation discussion, one of the most critical technical arguments in the room came from a person who had zero online presence. No polished slides. No public persona. Just clarity. And depth. And credibility built over years.

1️⃣ Visibility amplifies. It does not replace substance.
A personal brand can open doors. It can create opportunities. It can shape influence.
But it cannot compensate for shallow expertise.
If depth is missing, visibility only magnifies the gap.

2️⃣ Quiet excellence still builds trust.
In complex environments, especially in enterprise architecture and large organisations, long-term trust is built on stability, not noise.
The people who calmly deliver, consistently think long-term, and avoid unnecessary drama often become the real anchors of transformation.
They may not be loud. But they are respected.

3️⃣ The real question is not “brand or no brand”.
It is alignment.
Does your external visibility reflect your internal competence?
Or is it compensating for something?
There is an interesting Harvard Business Review discussion about “reputation capital” versus “social capital”. Visibility builds social capital. Competence builds reputation capital. Sustainable careers require both but in the right order.

Personally, I believe depth should always come first. Visibility without substance is fragile. Substance without visibility is sometimes invisible.

And finding balance is a strategic decision. Now I’m curious.

𝘋𝘰 𝘺𝘰𝘶 𝘵𝘩𝘪𝘯𝘬 𝘲𝘶𝘪𝘦𝘵 𝘱𝘳𝘰𝘧𝘦𝘴𝘴𝘪𝘰𝘯𝘢𝘭𝘪𝘴𝘮 𝘪𝘴 𝘴𝘵𝘪𝘭𝘭 𝘦𝘯𝘰𝘶𝘨𝘩 𝘪𝘯 𝘵𝘰𝘥𝘢𝘺’𝘴 𝘤𝘰𝘳𝘱𝘰𝘳𝘢𝘵𝘦 𝘦𝘯𝘷𝘪𝘳𝘰𝘯𝘮𝘦𝘯𝘵? 𝘏𝘢𝘷𝘦 𝘺𝘰𝘶 𝘴𝘦𝘦𝘯 𝘴𝘵𝘳𝘰𝘯𝘨 𝘱𝘳𝘰𝘧𝘦𝘴𝘴𝘪𝘰𝘯𝘢𝘭𝘴 𝘰𝘷𝘦𝘳𝘭𝘰𝘰𝘬𝘦𝘥 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘵𝘩𝘦𝘺 𝘢𝘷𝘰𝘪𝘥𝘦𝘥 𝘷𝘪𝘴𝘪𝘣𝘪𝘭𝘪𝘵𝘺?

#Leadership #CareerGrowth #EnterpriseArchitecture #ProfessionalDevelopment

𝗪𝗵𝘆 𝗻𝗼𝘁 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 “𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰” 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁
The word “strategic” has become almost magical in corporate life.
If something is called strategic, it automatically sounds big. Important. Untouchable.

I’ve been in many meetings where the moment a slide says “Strategic Initiative”, the tone in the room changes. People become more careful. More respectful. Less critical.

But over the years, I’ve learned something uncomfortable. Not everything that is strategic is actually important.

A few years ago, I was deeply involved in a transformation programme. It had executive sponsorship. It was visible. It was presented as critical for the future. It had all the right language.

At the same time, in parallel, there were smaller, less visible activities happening. Cleaning integration gaps. Clarifying ownership. Fixing architectural inconsistencies. Reducing complexity.

Guess which work actually reduced incidents and improved daily operations.

Not the slides. Not the positioning.
The boring fundamentals.
That experience changed how I look at strategy.

1️⃣ 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗼𝗳𝘁𝗲𝗻 𝗺𝗲𝗮𝗻𝘀 𝘃𝗶𝘀𝗶𝗯𝗹𝗲, 𝗻𝗼𝘁 𝗲𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹.
Visibility and importance are not the same thing.
Some initiatives are labelled strategic because they align with long-term narratives. But when you ask a simple question “If this stops tomorrow, what really breaks?” the answer is sometimes uncomfortable.
In architecture, real importance shows up in operational stability, not in presentation quality.

2️⃣ 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝘄𝗼𝗿𝗸 𝗶𝘀 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝘂𝗻𝗴𝗹𝗮𝗺𝗼𝗿𝗼𝘂𝘀.
Data governance. Ownership clarity. Technical debt reduction. Simplifying processes.
None of this looks impressive in a board update. But without it, every strategic ambition becomes fragile.

There’s a famous Peter Drucker quote: “There is nothing so useless as doing efficiently that which should not be done at all.”

3️⃣ 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗴𝗿𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝘁𝗵𝗲𝗮𝘁𝗿𝗲.
If a strategic initiative does not change how people actually work, reduce real friction, or eliminate risk, then it is positioning, not progress.
I’ve learned to test strategy with three practical filters:
𝘋𝘰𝘦𝘴 𝘪𝘵 𝘳𝘦𝘥𝘶𝘤𝘦 𝘤𝘰𝘮𝘱𝘭𝘦𝘹𝘪𝘵𝘺?
𝘋𝘰𝘦𝘴 𝘪𝘵 𝘳𝘦𝘮𝘰𝘷𝘦 𝘳𝘪𝘴𝘬?
𝘋𝘰𝘦𝘴 𝘪𝘵 𝘤𝘳𝘦𝘢𝘵𝘦 𝘮𝘦𝘢𝘴𝘶𝘳𝘢𝘣𝘭𝘦 𝘤𝘢𝘱𝘢𝘣𝘪𝘭𝘪𝘵𝘺?

If the answer is unclear, then maybe it’s strategic in language but not in impact.

Personally, I have become much more interested in leverage than in labels.

𝘏𝘢𝘷𝘦 𝘺𝘰𝘶 𝘦𝘷𝘦𝘳 𝘴𝘦𝘦𝘯 𝘢 “𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘪𝘤” 𝘪𝘯𝘪𝘵𝘪𝘢𝘵𝘪𝘷𝘦 𝘵𝘩𝘢𝘵 𝘤𝘩𝘢𝘯𝘨𝘦𝘥 𝘷𝘦𝘳𝘺 𝘭𝘪𝘵𝘵𝘭𝘦 𝘪𝘯 𝘳𝘦𝘢𝘭𝘪𝘵𝘺? 𝘐𝘯 𝘺𝘰𝘶𝘳 𝘦𝘯𝘷𝘪𝘳𝘰𝘯𝘮𝘦𝘯𝘵, 𝘸𝘩𝘢𝘵 𝘢𝘤𝘵𝘶𝘢𝘭𝘭𝘺 𝘮𝘰𝘷𝘦𝘴 𝘵𝘩𝘦 𝘯𝘦𝘦𝘥𝘭𝘦 𝘧𝘶𝘯𝘥𝘢𝘮𝘦𝘯𝘵𝘢𝘭𝘴 𝘰𝘳 𝘷𝘪𝘴𝘪𝘣𝘪𝘭𝘪𝘵𝘺? 

#EnterpriseArchitecture #Leadership #Strategy #Transformation

𝗠𝘆 𝗻𝗲𝘄 𝗮𝗿𝘁𝗶𝗰𝗹𝗲 𝗶𝘀 𝗹𝗶𝘃𝗲 𝗶𝗻 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗣𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 𝗝𝗼𝘂𝗿𝗻𝗮𝗹:
“𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗴𝗲 𝗼𝗳 𝗔𝗜: 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆, 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝗶𝗲𝘀, 𝗮𝗻𝗱 𝗛𝗶𝗱𝗱𝗲𝗻 𝗖𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆.”
https://lnkd.in/dmEcGsWK

This piece is personal.
Over the last two years, I’ve seen the same pattern repeat across organizations. AI projects move fast. Pilots appear quickly. Demos look impressive. Expectations rise even faster.

And then something breaks. Not because the model failed. But because no one defined the boundaries.

Who is responsible for AI decisions? Who owns the data quality? Who monitors unintended consequences? Where does human judgment stop and automation begin?

These questions are rarely answered clearly.

In my experience, AI does not reduce complexity. It redistributes it. And often hides it.

Architects are not becoming less relevant in this environment. They are becoming more accountable. Not for building models, but for shaping decision structures, ownership models, escalation paths, and system coherence.

AI amplifies what already exists.

If governance is weak, AI scales weakness.
If architecture debt exists, AI accelerates it.
If responsibility is unclear, AI makes that ambiguity visible.

This article is my reflection on what the role of an architect truly becomes in the AI era. Less about drawing diagrams. More about holding the system together under pressure.

𝘞𝘩𝘦𝘳𝘦 𝘥𝘰 𝘺𝘰𝘶 𝘴𝘦𝘦 𝘳𝘦𝘴𝘱𝘰𝘯𝘴𝘪𝘣𝘪𝘭𝘪𝘵𝘺 𝘨𝘢𝘱𝘴 𝘪𝘯 𝘈𝘐 𝘪𝘯𝘪𝘵𝘪𝘢𝘵𝘪𝘷𝘦𝘴? 𝘏𝘢𝘴 𝘈𝘐 𝘴𝘪𝘮𝘱𝘭𝘪𝘧𝘪𝘦𝘥 𝘺𝘰𝘶𝘳 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘰𝘳 𝘦𝘹𝘱𝘰𝘴𝘦𝘥 𝘩𝘪𝘥𝘥𝘦𝘯 𝘤𝘰𝘮𝘱𝘭𝘦𝘹𝘪𝘵𝘺? 𝘈𝘯𝘥 𝘸𝘩𝘰, 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯, 𝘪𝘴 𝘵𝘳𝘶𝘭𝘺 𝘢𝘤𝘤𝘰𝘶𝘯𝘵𝘢𝘣𝘭𝘦 𝘧𝘰𝘳 𝘈𝘐 𝘰𝘶𝘵𝘤𝘰𝘮𝘦𝘴?

#EnterpriseArchitecture #ArtificialIntelligence #ArchitectureDebt #TechnologyLeadership

eapj.org

Architect in the Age of AI Responsibility, Boundaries, and Hidden Complexity

𝗙𝗲𝗱𝗲𝗿𝗮𝘁𝗲𝗱 𝗗𝗮𝘁𝗮: 𝗙𝗿𝗲𝗲𝗱𝗼𝗺 𝗼𝗿 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗖𝗵𝗮𝗼𝘀?
Federated data architecture sounds attractive.
Domain autonomy. Data products. Decentralized ownership. Faster decisions.

On slides, it looks modern and mature. In reality, it is much harder.

I have worked in environments where every domain wanted control over “their” data. And I understand that instinct. Domains know their processes. They move faster when they are not waiting for a central team.
But I have also seen what happens when autonomy grows without shared discipline.

Definitions start drifting. The same metric exists in five versions. Integration becomes negotiation. Enterprise reporting becomes political.

Autonomy without standards does not create agility.
It creates fragmentation.

There is a well-known principle in system design: “Loose coupling, strong contracts.” We love the loose coupling part. We often forget about the strong contracts.

In my view, federated data architecture only works when some elements remain clearly centralized.
Not centralized execution. Centralized foundations.
What must stay centralized?

Core data definitions. Enterprise-wide standards. Security and compliance guardrails. Decision rights in cross-domain conflicts.

What can be federated?

Data product development. Domain-specific modeling. Prioritization within business context. Local innovation.

The balance is delicate.

Too much central control, and domains slow down. Too much freedom, and enterprise coherence disappears.

I personally believe federation is not about freedom. It is about structured discipline. It requires stronger architecture, not weaker.

Because once you distribute ownership, you multiply complexity.
And complexity needs guardrails.

𝘐𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯, 𝘸𝘩𝘢𝘵 𝘩𝘢𝘴 𝘸𝘰𝘳𝘬𝘦𝘥 𝘣𝘦𝘵𝘵𝘦𝘳 𝘴𝘵𝘳𝘰𝘯𝘨 𝘤𝘦𝘯𝘵𝘳𝘢𝘭 𝘥𝘢𝘵𝘢 𝘤𝘰𝘯𝘵𝘳𝘰𝘭 𝘰𝘳 𝘧𝘦𝘥𝘦𝘳𝘢𝘵𝘦𝘥 𝘮𝘰𝘥𝘦𝘭𝘴? 𝘞𝘩𝘦𝘳𝘦 𝘥𝘰 𝘺𝘰𝘶 𝘥𝘳𝘢𝘸 𝘵𝘩𝘦 𝘭𝘪𝘯𝘦 𝘣𝘦𝘵𝘸𝘦𝘦𝘯 𝘴𝘵𝘢𝘯𝘥𝘢𝘳𝘥𝘪𝘻𝘢𝘵𝘪𝘰𝘯 𝘢𝘯𝘥 𝘢𝘶𝘵𝘰𝘯𝘰𝘮𝘺? 𝘏𝘢𝘷𝘦 𝘺𝘰𝘶 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦𝘥 𝘧𝘦𝘥𝘦𝘳𝘢𝘵𝘪𝘰𝘯 𝘵𝘶𝘳𝘯𝘪𝘯𝘨 𝘪𝘯𝘵𝘰 𝘧𝘳𝘢𝘨𝘮𝘦𝘯𝘵𝘢𝘵𝘪𝘰𝘯?

#EnterpriseArchitecture #DataArchitecture #FederatedData #DataGovernance

𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗮𝗴𝗿𝗲𝗲𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. 𝗡𝗼 𝗼𝗻𝗲 𝗼𝘄𝗻𝘀 𝗶𝘁. 𝗧𝗵𝗮𝘁’𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺
At some point in every organisation, the same question quietly appears. Who actually owns architecture decisions.

On paper, the answer often looks clear. There is an architecture function, a board, a set of roles. In practice, ownership becomes fragmented very quickly. Strategy is “shared”. The portfolio is “maintained by architecture”. The roadmap is “owned by delivery”. And decisions fall somewhere in between.

This is where things start to drift.

When ownership is blurred, architecture turns into advice instead of authority. Architects recommend. Delivery adapts. Business decides. And no one truly owns the long-term consequences of those decisions.

I’ve seen portfolio discussions where everyone agreed on priorities, but no one could say who was responsible for stopping an investment. I’ve seen roadmaps approved without anyone owning the architectural risks embedded in them. Not because people avoided responsibility, but because responsibility was never clearly assigned.

Architecture debt grows very comfortably in this setup. Decisions are made locally, trade-offs are accepted implicitly, and accountability dissolves across committees and forums.

Here’s an opinion that is sometimes uncomfortable. Architecture governance cannot compensate for missing ownership. You can have all the right processes, templates, and boards, but if no one owns the final architectural call, the system will optimise for short-term delivery every time.

For me, ownership doesn’t mean control. It means being accountable for consequences. It means being able to say yes, no, or not now, and to stand behind that decision when pressure arrives.

When architecture has real ownership, something changes. Portfolios become sharper. Roadmaps become more honest. Strategy stops being aspirational and starts being selective.

And that’s usually when architecture begins to matter.

𝙌𝙪𝙚𝙨𝙩𝙞𝙤𝙣𝙨 𝙛𝙤𝙧 𝙮𝙤𝙪:
-𝘸𝘩𝘰 𝘵𝘳𝘶𝘭𝘺 𝘰𝘸𝘯𝘴 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯𝘴 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘴𝘢𝘵𝘪𝘰𝘯 𝘵𝘰𝘥𝘢𝘺
-𝘸𝘩𝘦𝘳𝘦 𝘥𝘰𝘦𝘴 𝘰𝘸𝘯𝘦𝘳𝘴𝘩𝘪𝘱 𝘣𝘦𝘤𝘰𝘮𝘦 𝘣𝘭𝘶𝘳𝘳𝘦𝘥 𝘰𝘳 𝘥𝘪𝘭𝘶𝘵𝘦𝘥
-𝘢𝘯𝘥 𝘸𝘩𝘪𝘤𝘩 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯𝘴 𝘸𝘰𝘶𝘭𝘥 𝘭𝘰𝘰𝘬 𝘥𝘪𝘧𝘧𝘦𝘳𝘦𝘯𝘵 𝘪𝘧 𝘰𝘸𝘯𝘦𝘳𝘴𝘩𝘪𝘱 𝘸𝘢𝘴 𝘦𝘹𝘱𝘭𝘪𝘤𝘪𝘵

#EnterpriseArchitecture #ArchitectureGovernance #TechnologyStrategy #ArchitectureDebt

𝗜𝗳 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆, 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀, 𝗮𝗻𝗱 𝗜𝗧 𝗗𝗶𝘀𝗮𝗴𝗿𝗲𝗲 — 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗙𝗮𝗶𝗹𝗲𝗱
Nobody cares about your five-layer architecture diagram.
Executives want clarity. Teams want direction. Nobody wants to read a manual.

Enterprise Architecture gets bloated with frameworks, but the point is simple: 𝙄𝙩'𝙨 𝙖𝙗𝙤𝙪𝙩 𝙖𝙡𝙞𝙜𝙣𝙢𝙚𝙣𝙩, 𝙣𝙤𝙩 𝙙𝙤𝙘𝙪𝙢𝙚𝙣𝙩𝙖𝙩𝙞𝙤𝙣.

Three worlds collide every day:
✔️ Strategy says one thing.
✔️ Business hears another.
✔️ IT builds something else.

That's how you end up with tech that solves problems nobody has, or projects that burn months with nothing to show for it.
𝙏𝙝𝙚 𝙧𝙚𝙨𝙪𝙡𝙩: money wasted, teams exhausted, and progress measured in PowerPoint slides instead of outcomes.

Real architecture isn't a theory. It's a translation layer. It turns big ideas into constraints teams actually use, so everyone moves fast, but in the same direction.

No alignment, no value. Doesn't matter how pretty your models look.
Good architecture keeps people moving together, not just moving.
Alignment is the only real deliverable that matters.

𝘞𝘩𝘦𝘯 𝘸𝘢𝘴 𝘵𝘩𝘦 𝘭𝘢𝘴𝘵 𝘵𝘪𝘮𝘦 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘢𝘤𝘵𝘶𝘢𝘭𝘭𝘺 𝘤𝘩𝘢𝘯𝘨𝘦𝘥 𝘢 𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘪𝘤 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯? 𝘈𝘳𝘦 𝘺𝘰𝘶𝘳 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘢𝘳𝘵𝘪𝘧𝘢𝘤𝘵𝘴 𝘥𝘳𝘪𝘷𝘪𝘯𝘨 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘰𝘯 𝘰𝘳 𝘫𝘶𝘴𝘵 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘪𝘯𝘨 𝘪𝘵? 𝘐𝘧 𝘢𝘭𝘪𝘨𝘯𝘮𝘦𝘯𝘵 𝘪𝘴 𝘵𝘩𝘦 𝘨𝘰𝘢𝘭, 𝘩𝘰𝘸 𝘥𝘰 𝘺𝘰𝘶 𝘮𝘦𝘢𝘴𝘶𝘳𝘦 𝘸𝘩𝘦𝘵𝘩𝘦𝘳 𝘺𝘰𝘶 𝘵𝘳𝘶𝘭𝘺 𝘩𝘢𝘷𝘦 𝘪𝘵?

#EnterpriseArchitecture #BusinessAlignment #TechLeadership #DigitalStrategy #Architecture

𝗠𝗮𝗿𝗰𝗵 𝟴. 𝗡𝗼𝘁 𝗮𝗯𝗼𝘂𝘁 𝗳𝗹𝗼𝘄𝗲𝗿𝘀. 𝗔𝗯𝗼𝘂𝘁 𝘀𝗽𝗮𝗰𝗲.
Today isn’t just about celebrating women. It’s about noticing how much invisible work they still carry.

In tech.
In leadership.
In architecture.

I’ve sat in rooms where a woman’s idea was ignored until someone else repeated it louder. I’ve seen talented professionals hesitate before speaking, calculating the cost of being “too direct.” I’ve watched women outperform expectations while quietly doubting themselves.

And yet.

I’ve also seen women reshape organizations. Ask uncomfortable questions. Redesign broken systems. Build clarity where there was noise.

Strength in our industry isn’t loud. It’s consistent. It’s thoughtful. It’s resilient.

𝗙𝗼𝗿 𝗺𝗲, 𝗠𝗮𝗿𝗰𝗵 𝟴 𝗶𝘀 not about proving anything. 𝗜𝘁’𝘀 𝗮𝗯𝗼𝘂𝘁 𝗰𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 𝘄𝗵𝗲𝗿𝗲 𝗽𝗿𝗼𝘃𝗶𝗻𝗴 𝗶𝘀𝗻’𝘁 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱. Where competence speaks. Where leadership isn’t gender-coded. Where ambition isn’t apologetic.

To every woman building, leading, questioning, learning, unlearning, you don’t need permission to take space. And to leaders real progress isn’t celebrating diversity once a year. It’s designing systems where it thrives every day.

𝗛𝗮𝗽𝗽𝘆 𝗜𝗻𝘁𝗲𝗿𝗻𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗪𝗼𝗺𝗲𝗻’𝘀 𝗗𝗮𝘆.

𝘞𝘩𝘰 𝘪𝘴 𝘢 𝘸𝘰𝘮𝘢𝘯 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘤𝘢𝘳𝘦𝘦𝘳 𝘸𝘩𝘰 𝘲𝘶𝘪𝘦𝘵𝘭𝘺 𝘤𝘩𝘢𝘯𝘨𝘦𝘥 𝘺𝘰𝘶𝘳 𝘵𝘳𝘢𝘫𝘦𝘤𝘵𝘰𝘳𝘺? Tag her.

#InternationalWomensDay #WomenInTech #Leadership #Inclusion

𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗗𝗲𝗯𝘁 𝗜𝘀 𝗮 𝗖𝘂𝗹𝘁𝘂𝗿𝗮𝗹 𝗠𝗶𝗿𝗿𝗼𝗿
We often explain architecture debt in technical language. Legacy systems. Poor modularity. Tight coupling. Missing standards.

But I believe that’s a convenient simplification.
Architecture debt is not primarily a technology problem. It is a reflection of organizational maturity and culture.

And sometimes that statement makes people uncomfortable.

I’ve worked in environments where architects were strong, frameworks were clear, and governance existed on paper yet architecture debt kept growing. Not because people lacked competence. But because the culture quietly punished structural conversations.

In companies where conflict is avoided, architecture debt grows.
When no one wants to challenge timelines or question a rushed integration, compromises become embedded into the foundation.

In companies where it’s “not acceptable” to push back on business, architecture debt grows.
When architectural risk is reframed as resistance, the system stops evolving intentionally. It starts bending.

In companies where decisions are not documented, architecture debt grows.
When trade-offs are not recorded, risks are not assigned owners, and target states are not clarified, every workaround silently becomes permanent.

And here is the thesis I want to push:
Architecture debt is a symptom of leadership behavior, 𝗻𝗼𝘁 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗶𝗺𝗽𝗲𝗿𝗳𝗲𝗰𝘁𝗶𝗼𝗻.

You can hire better engineers.
You can buy better tools.
You can implement better CI/CD pipelines.

But if architects are not empowered to say “no,”
if trade-offs are not transparently owned,
if long-term thinking is constantly sacrificed for short-term optics,

the debt will return. Always.

Architecture debt is rarely created in a single dramatic decision.
It accumulates in small moments of silence.

In meetings where someone thought, “This is risky,” but didn’t say it. In steering committees where the focus was only on cost and delivery date. In transformations where documentation was considered optional.

That’s not a code issue. That’s a governance pattern.

In immature organizations, debt is emotional. Political. Denied. Normalized.

So let me ask something slightly provocative:
𝗜𝗳 𝘆𝗼𝘂 𝗿𝗲𝗺𝗼𝘃𝗲𝗱 𝗮𝗹𝗹 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄 𝗻𝗼 𝗰𝗼𝗱𝗲, 𝗻𝗼 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲, 𝗻𝗼 𝗱𝗶𝗮𝗴𝗿𝗮𝗺𝘀 𝘄𝗼𝘂𝗹𝗱 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝘁𝗵𝗮𝘁 𝗰𝗿𝗲𝗮𝘁𝗲𝗱 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗱𝗲𝗯𝘁 𝘀𝘁𝗶𝗹𝗹 𝗲𝘅𝗶𝘀𝘁?

Because if they would, then the root cause was never technical.

It was cultural. And culture is much harder to refactor than code.

𝘐𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯, 𝘸𝘩𝘰 𝘪𝘴 𝘵𝘳𝘶𝘭𝘺 𝘢𝘭𝘭𝘰𝘸𝘦𝘥 𝘵𝘰 𝘤𝘩𝘢𝘭𝘭𝘦𝘯𝘨𝘦 𝘢 𝘳𝘪𝘴𝘬𝘺 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘢𝘭 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘣𝘦𝘪𝘯𝘨 𝘭𝘢𝘣𝘦𝘭𝘦𝘥 𝘢𝘴 “𝘣𝘭𝘰𝘤𝘬𝘪𝘯𝘨 𝘥𝘦𝘭𝘪𝘷𝘦𝘳𝘺”? 

#ArchitectureDebt #EnterpriseArchitecture #LeadershipAndCulture #DigitalTransformation

𝗔 𝗺𝗮𝘁𝘂𝗿𝗲 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘄𝗵𝗼 𝗸𝗻𝗼𝘄𝘀 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴.
Early in my career, I believed that competence meant having answers.
If someone asked a question, I felt I had to respond. If there was uncertainty, I tried to reduce it quickly. If I didn’t know something, I felt uncomfortable.

I thought confidence meant certainty.
Over time, working in architecture and transformation, I realised something very different.

The strongest professionals in the room are often the ones who say, calmly,
“𝘐 𝘥𝘰𝘯’𝘵 𝘬𝘯𝘰𝘸 𝘺𝘦𝘵.”
“𝘓𝘦𝘵’𝘴 𝘷𝘢𝘭𝘪𝘥𝘢𝘵𝘦 𝘵𝘩𝘪𝘴.”
“𝘓𝘦𝘵’𝘴 𝘩𝘦𝘢𝘳 𝘢𝘯𝘰𝘵𝘩𝘦𝘳 𝘱𝘦𝘳𝘴𝘱𝘦𝘤𝘵𝘪𝘷𝘦.”

And they say it without losing authority.

A few years ago, during a complex discussion about platform design, a senior leader was asked a very direct question about risk exposure. Instead of giving a polished answer, he paused and said, “I don’t have enough data to answer responsibly. Let’s review it and come back.”

Nobody doubted his competence.
In fact, the room trusted him more.
That moment stayed with me.

1️⃣ 𝗞𝗻𝗼𝘄𝗶𝗻𝗴 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗶𝘀 𝗻𝗼𝘁 𝘀𝘁𝗿𝗲𝗻𝗴𝘁𝗵. 𝗜𝗻𝘁𝗲𝗹𝗹𝗲𝗰𝘁𝘂𝗮𝗹 𝗵𝘂𝗺𝗶𝗹𝗶𝘁𝘆 𝗶𝘀.
In complex systems, no one sees the full picture.
Enterprise environments are layered. Interdependent. Political. Technical. Human.
Pretending certainty in such systems is often an illusion.
There is a concept in psychology called the Dunning–Kruger effect. It describes how people with limited knowledge often overestimate their competence, while experts tend to recognise the limits of their understanding.
The more you learn, the more you see what you don’t know.
That’s not weakness. That’s maturity.

2️⃣ 𝗔𝗱𝘂𝗹𝘁 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹𝗶𝘀𝗺 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗷𝘂𝗱𝗴𝗲𝗺𝗲𝗻𝘁, 𝗻𝗼𝘁 𝗮𝗻𝘀𝘄𝗲𝗿𝘀.
When I was younger, I wanted to demonstrate expertise.
Now I care more about asking better questions.
𝘞𝘩𝘢𝘵 𝘢𝘳𝘦 𝘸𝘦 𝘮𝘪𝘴𝘴𝘪𝘯𝘨?
𝘞𝘩𝘰 𝘪𝘴 𝘯𝘰𝘵 𝘪𝘯 𝘵𝘩𝘦 𝘳𝘰𝘰𝘮?
𝘞𝘩𝘢𝘵 𝘢𝘴𝘴𝘶𝘮𝘱𝘵𝘪𝘰𝘯𝘴 𝘢𝘳𝘦 𝘸𝘦 𝘮𝘢𝘬𝘪𝘯𝘨?
In architecture work, asking the right question often creates more value than giving a fast answer.

3️⃣ 𝗖𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝗰𝗲 𝗮𝗻𝗱 𝗵𝘂𝗺𝗶𝗹𝗶𝘁𝘆 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗼𝗽𝗽𝗼𝘀𝗶𝘁𝗲𝘀.
This is something I had to learn. You can be confident in your experience and still open to correction. You can lead and still admit uncertainty. You can be strong and still say, “Let’s rethink this.”
In fact, that combination creates psychological safety. And without psychological safety, no team can innovate honestly.

For me, being a mature professional now means this: I don’t need to win the room. I need to improve the outcome.

#Leadership #ProfessionalGrowth #EnterpriseArchitecture #WorkplaceCulture

𝗗𝗮𝘁𝗮 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝗼𝗳𝘁𝗲𝗻 𝗹𝗼𝗼𝗸𝘀 𝗶𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝘃𝗲.
Clear roles. Named data owners. Formal policies. Steering committees with structured agendas. Maturity models. Heatmaps.

On paper, everything is under control.
But I have seen situations where all of this existed and standards were still ignored the moment delivery pressure increased.

The real problem was not documentation.
It was authority.

I remember one transformation program where data ownership was clearly defined in the governance deck. Every domain had a “data owner.” It looked structured. Responsible. Mature.

But when two domains disagreed about which dataset was authoritative, no one had the mandate to decide. Meetings multiplied. Deadlines slipped. Local solutions were implemented “temporarily.” That temporary solution is still there.

That is the moment I understood something very simple.
Governance without decision rights is just coordination.
And coordination does not scale in complex enterprises.

Especially in federated organizations, autonomy is strong. And I support autonomy. Domains should move fast. They should innovate. They should own their data products.

But autonomy without guardrails becomes fragmentation.

Enterprise Architecture, in my view, is not there to write more principles. It is there to anchor governance in real decision structures.

𝘞𝘩𝘰 𝘤𝘢𝘯 𝘣𝘭𝘰𝘤𝘬 𝘢 𝘯𝘰𝘯-𝘤𝘰𝘮𝘱𝘭𝘪𝘢𝘯𝘵 𝘴𝘰𝘭𝘶𝘵𝘪𝘰𝘯?
𝘞𝘩𝘰 𝘤𝘢𝘯 𝘳𝘦𝘴𝘰𝘭𝘷𝘦 𝘤𝘳𝘰𝘴𝘴-𝘥𝘰𝘮𝘢𝘪𝘯 𝘤𝘰𝘯𝘧𝘭𝘪𝘤𝘵?
𝘞𝘩𝘢𝘵 𝘩𝘢𝘱𝘱𝘦𝘯𝘴 𝘪𝘧 𝘢 𝘵𝘦𝘢𝘮 𝘪𝘨𝘯𝘰𝘳𝘦𝘴 𝘴𝘵𝘢𝘯𝘥𝘢𝘳𝘥𝘴?

If those answers are unclear, governance is advisory. And advisory governance works only when everyone behaves ideally. Real organizations do not behave ideally. They behave under pressure.

There is a famous quote often attributed to Peter Drucker: “Culture eats strategy for breakfast.” I would adapt it slightly for data: operating model eats governance documents for breakfast.

If your operating model does not reinforce standards, your standards are optional.

And optional standards are not standards.

𝘐𝘯 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯, 𝘸𝘩𝘰 𝘩𝘢𝘴 𝘵𝘩𝘦 𝘳𝘦𝘢𝘭 𝘢𝘶𝘵𝘩𝘰𝘳𝘪𝘵𝘺 𝘵𝘰 𝘦𝘯𝘧𝘰𝘳𝘤𝘦 𝘥𝘢𝘵𝘢 𝘴𝘵𝘢𝘯𝘥𝘢𝘳𝘥𝘴?
𝘏𝘢𝘷𝘦 𝘺𝘰𝘶 𝘴𝘦𝘦𝘯 𝘨𝘰𝘷𝘦𝘳𝘯𝘢𝘯𝘤𝘦 𝘧𝘢𝘪𝘭 𝘯𝘰𝘵 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘰𝘧 𝘣𝘢𝘥 𝘪𝘯𝘵𝘦𝘯𝘵, 𝘣𝘶𝘵 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘰𝘧 𝘶𝘯𝘤𝘭𝘦𝘢𝘳 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯 𝘳𝘪𝘨𝘩𝘵𝘴? 𝘞𝘩𝘢𝘵 𝘸𝘰𝘶𝘭𝘥 𝘤𝘩𝘢𝘯𝘨𝘦 𝘪𝘧 𝘨𝘰𝘷𝘦𝘳𝘯𝘢𝘯𝘤𝘦 𝘸𝘢𝘴 𝘵𝘪𝘦𝘥 𝘥𝘪𝘳𝘦𝘤𝘵𝘭𝘺 𝘵𝘰 𝘧𝘶𝘯𝘥𝘪𝘯𝘨 𝘰𝘳 𝘦𝘴𝘤𝘢𝘭𝘢𝘵𝘪𝘰𝘯 𝘱𝘢𝘵𝘩𝘴?

#EnterpriseArchitecture #DataGovernance #DataArchitecture #OperatingModel

𝗗𝗶𝗴𝗶𝘁𝗮𝗹 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗟𝗲𝗴𝗮𝗰𝘆 𝗖𝗹𝗲𝗮𝗻𝘂𝗽 𝗜𝘀 𝗝𝘂𝘀𝘁 𝗘𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝗧𝗵𝗲𝗮𝘁𝗲𝗿
Every executive says they want digital transformation. Few are ready to bulldoze legacy thinking.

Here's the thing most people miss. You can throw millions at new tech and still end up with 1999 problems in 2024.

I've seen it play out in boardrooms and server rooms:
1. Leaders say "innovate," but cling to old architecture like a security blanket.
2. Teams chase buzzwords. AI here, cloud there. No context. No plan.
3. Results? A shiny new chaos layered on ancient chaos.

I'm tired of watching this movie.

Here's my blunt, field-tested blueprint for moving from "legacy" to "leading-edge" (without burning out everyone involved):
- Face the skeletons. List every legacy process you're afraid to touch. Put a dollar sign next to each one. If it's costing more than it's worth, it goes.
- Stop "transformation theater." Half-measures and shiny pilots impress no one. Go all-in on ONE business capability that matters. Nail it. Then scale.
- Make architecture debt as real as financial debt. Report on it. Prioritize it. Give your teams permission to fix it.
- Don't worship the new for the sake of new. If your processes stink, AI will only make them smellier, faster.
- Exit the echo chamber. Listen to your people on the ground floor. They know the cracks in the foundation, even if the C-suite doesn't.

I've watched organizations chase digital unicorns for years and end up with Frankenstein's monster.

𝘞𝘩𝘢𝘵’𝘴 𝘵𝘩𝘦 𝘰𝘯𝘦 𝘭𝘦𝘨𝘢𝘤𝘺 𝘴𝘺𝘴𝘵𝘦𝘮 𝘺𝘰𝘶𝘳 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯 𝘪𝘴 𝘢𝘧𝘳𝘢𝘪𝘥 𝘵𝘰 𝘵𝘰𝘶𝘤𝘩 𝘢𝘯𝘥 𝘸𝘩𝘺?
𝘈𝘳𝘦 𝘺𝘰𝘶 𝘪𝘯𝘷𝘦𝘴𝘵𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘪𝘯 𝘪𝘯𝘯𝘰𝘷𝘢𝘵𝘪𝘰𝘯... 𝘰𝘳 𝘪𝘯 𝘱𝘳𝘰𝘵𝘦𝘤𝘵𝘪𝘯𝘨 𝘰𝘶𝘵𝘥𝘢𝘵𝘦𝘥 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦?
𝘐𝘧 𝘺𝘰𝘶 𝘮𝘢𝘥𝘦 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦 𝘥𝘦𝘣𝘵 𝘷𝘪𝘴𝘪𝘣𝘭𝘦 𝘵𝘰 𝘵𝘩𝘦 𝘣𝘰𝘢𝘳𝘥 𝘵𝘰𝘮𝘰𝘳𝘳𝘰𝘸, 𝘸𝘩𝘢𝘵 𝘸𝘰𝘶𝘭𝘥 𝘩𝘢𝘱𝘱𝘦𝘯?

#DigitalTransformation #EnterpriseArchitecture #LegacySystems #TechLeadership #ArchitectureDebt

taplio

The Battle

Drew Fortin

Nadzeya Stalbouskaya

Followers

Posts

Engagements

Likes

Performance ScoreNadzeya Stalbouskaya's LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

Drew Fortin

Nadzeya Stalbouskaya

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}Nadzeya Stalbouskaya's LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreNadzeya Stalbouskaya's LinkedIn Performance