I’ve spent years in architecture roles, guiding teams, making technical decisions, and shaping large-scale systems. But in the last 10~ years, I can see the shift happening and the role of the architect has changed.
As an architect, I designed systems, guided technical decisions, and ensured teams aligned with the broader architectural vision. Architects carried many responsibilities, including acting as gatekeepers of good engineering and maintaining consistency across the organization.
It worked — until it didn’t.
There is a growing need to ship value to customers and get feedback to shape the strategy in the right direction. Engineering organizations adopting the customer-first mindset, engineers these days are closer to the product and the customer needs. I tend to say that there is a transition in the engineering mindset — we ship products and not just code!
These changes lead engineering organization change into more independent, full-stack domain teams that will enable them set well defined objectives, scale independently and get the end-to-end ownership of solving customer problems. This shift in mindset and the need to scale the organization led companies embrace microservices, systems evolved into being deep distributed systems along with the changes in teams structure. As a result of this evolution, architecture became fluid, dynamic, and harder to control from a central point.
This shift isn’t theoretical — I’ve seen it happening. The role of the architect has changed drastically — the traditional architect role no longer fits modern software development and companies started adjusting. Instead of centralizing architectural decisions, organizations shifted toward embedding architectural thinking within engineering and evolving senior IC roles (such as: Principal Engineers). Not all companies have the luxury of clearly defining their engineering career ladders and IC path responsibilities with well-defined impact expectations. What I’ve observed in recent years is that “architect” is increasingly seen as a skill that engineers at every level are expected to develop, rather than a distinct role.
If you think about this carefully, it’s a natural path. You might seen this in your company as well, architects face the challenge of influencing software design and decisions when they are not part of the team. I can understand why engineering teams wouldn’t want someone external making decisions for them — especially if that person is disconnected from their codebase, unaware of their challenges, and not the one waking up at night for high-severity incidents.
I fully support engineers owning their software from requirements to production support. The culture of ownership — you build it, you ship it, you maintain it — empowers teams to make decisions, challenge product assumptions, and drive customer impact. Engineers and teams should seek the knowledge that helps them build better systems. They can consult, gather feedback, and learn best practices from anyone in the organization — including architects, who can be one of the many people they collaborate with. I’m not saying that the architect role is completely redundant but I think if an architect want to influence anything, they can’t stay in their “ivory towers” and create standards, processes or influence designs. It is a big challenge for an outsider to keep up with the changes in the team, their new developments and still provide a meaningful feedback on their designs. In order to really make an impact on the engineering, architects will need to be part of the development efforts, assist in debugging production incidents, drill down with the team in to their challenges, be part of the team to get an understanding on the last evolvements. Architecture is one of the skills that you want that your engineers to have at certain levels in your organization. I’m starting to ask myself if it the role can stand by itself? I assume that it varies between organizations maturity, size and it’s leadership that shaping the culture of their engineering organization.
What I have observed is that sometimes engineering organizations have challenges in multiple levels and they tend to believe that hiring an architect will solve them. For example, they might think, “We’ll hire an architect to set higher standards” or “We need an architect to oversee the overall architecture”. However, I sometimes wonder — does “overall architecture” really exist in this new era of deep microservices architectures? Here’s the hard truth (depends on the company maturity and size): There is no overall architecture anymore — at least, not in the way we used to think about it. Instead, we now have more architectural domains — logical groupings of services that share common patterns, constraints, and objectives. The idea of a single, unified architectural vision has given way to something more fluid: a set of loosely coupled but aligned architectures across teams. Architecture today is about continuous alignment, guiding through influence, and enabling teams to make good decisions autonomously. The power we once had to shape systems at a high level is now distributed among teams. But the real opportunity lies in adapting — becoming the bridge between teams, ensuring long-term stability without slowing innovation.
This shift aligns naturally with the engineering culture we want to see more — one that emphasizes greater autonomy, ownership, and empowerment. As engineers advance in their IC careers, they are expected to expand their influence beyond their own teams, impacting other groups and, eventually, the organization as a whole. I’m not sure what is the future of the the architect role as we knew it, what I see in the last years makes sense to me as an engineering leader (that would like to shape the culture into the right direction), it will enable us as an organization to impact customers and scale the business. I expect to see more Principal/Staff Engineers in the teams rather than architect as a role that is somewhere in the organizational structure and that its responsibilities aren’t well defined.
If you’re an architect, I encourage you to be actively involved in part of the teams development efforts, keep learning, break down barriers, and go beyond just building POCs. Deliver your code to production, continuously refine your core engineering skills, and stay relevant to the teams so you can have a real impact.
