A typical Monday morning. Pieter, COO of a mid-sized automotive company, sends a company-wide email with a triumphant tone: they're switching to a new ERP platform, go-live date set for the first of next month.
What the email didn't mention was why. A major investor had just signed on — and their compliance requirements mandated that all product certifications be digitally tracked through that exact system. No system, no deal.
That context never reached the software department.
To Pieter, it was a "system switch." A few clicks, some data migration, done. To the developers, it was something else entirely: the new platform needed to connect to their inventory system, their planning tool, and a legacy access management system nobody had documented since 2019 — because there was "no time."
This is a typical example of Business-IT alignment failure. The business doesn't understand software complexity and software department doesn't understand strategic goals. And somewhere in the middle, a missed investor deadline quietly kills a contract.
Over the years, working across companies in interim architect roles, the job turned out to be far less about technical problem-solving than expected.
This blogpost is about what that experience actually taught me.
Learn the domain
To be taken seriously, you have to understand the world of the people you're working with. That starts with a simple question: how does this company actually make money? Once that's clear, technical proposals stop floating in the abstract and start connecting to real goals. Understanding the customer relationship changes everything — it becomes possible to design solutions that facilitate the business instead of quietly working against it.
Relationships
Don't wait for an invitation. Proactively reaching out to key figures in the business, introducing yourself, finding the people willing to talk — that's where the real work begins for the architect. Trust isn't built in one or two conversations. It takes patience, consistency, and genuine curiosity about other people's work. Human connection is the infrastructure everything else runs on.
Know your development team
Beyond understanding the business, there's the question of understanding the people who actually build the software. Their personalities, skill sets, team dynamics — these determine what's actually achievable, not what looks good on a roadmap. When a goal turns out to be out of reach with the current setup, the answer isn't just "no." It's figuring out how to grow toward it together.
Baby steps
When change is needed, the instinct is often to fix everything at once. That instinct is almost always wrong. Trying to reorganize large parts of the software architecture or development process in one sweep creates resistance, confusion, and exhaustion. Small, manageable improvements work better. This builds confidence and will let people adapt gradually to the changes.
Connect the dots
Once a relationship is established, it becomes possible to point out what isn't working without triggering defensiveness. Blame is a sign of weakness anyway — and it solves nothing. The real job is holding knowledge of both worlds and using it to build a shared understanding. A plan everyone can actually follow.
Politics
This one took the longest to accept. Most architects with a technical background want to stay far away from organizational dynamics, competing interests, and influence without authority. But avoiding that dimension doesn't make it disappear — it just makes you less effective. Once that reality is embraced, the frustration starts to lift. Navigating the organization becomes part of the craft, not an obstacle to it.
Show results
When a partnership is working, it needs to be maintained. That means giving the business genuine visibility into what the technology is actually delivering. When they see the value, the collaboration becomes self-reinforcing. Proof of progress, communicated clearly, turns a working relationship into a lasting one.
