Pieter is manager of a mid-sized automotive company. He sends a company-wide email: they're switching to a new inventory platform and the go-live date is set for the first of next month.
What the email didn't mention was “why”. A major investor, and co owner, had just signed on and their compliance requirements mandated that all product certifications are to be digitally tracked through that exact system. The contract said no system, no deal.
That context never reached the software department.
To Pieter this is a simple "system switch." A few clicks, some data migration, done. To the developers, it was something else entirely: this new platform needed to connect to their inventory system but also to a legacy access management system nobody had documented since 2019. Because back then there was "no time."
This is a classic example of Business-IT alignment failure. The business doesn't understand software complexity and the software department doesn't understand strategic goals and motives behind them.
Over the years, working across companies in interim architect or dev lead roles, the job turned out to be far less about technical problem-solving than expected.
This blogpost is about some of the things that I have learned in the last few years.
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. Also understand the customer relationship and the history about the relationship and how this relationship is formed. Because sometimes the customer relationship can have an impact on the system design. It shouldn’t, but sometimes it's not that simple.
Relationships
While talking about relationships. Try to proactively reach out to key figures in your business, introducing yourself, finding the people willing to talk. Creating and building relationships is vital for an architect. Trust isn't built in one or two conversations. It takes patience, consistency, and genuine curiosity about other people's work.
Know your development team
Beyond understanding the business, there's the question of understanding the people who actually build the software. Take time to get to know your team. Know their personalities, their skill sets and the team dynamics. This determines 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 and how you can facilitate this process.
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 frustration. Small, manageable improvements work better. This builds confidence and will let people adapt gradually to the changes.
Politics
This one took the longest to accept. Most architects with a technical background, like me, 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 you have a good relationship with the business and stakeholders of your projects, this relation also needs to be maintained. That means giving the business and stakeholders genuine visibility into what the technology is actually delivering. When they see the value, the collaboration becomes self-reinforcing. With baby steps it's easier to show these results and its value. You have to prove that there is progress, communicate clearly, and turn a working relationship into a lasting one.
