From Developer to Architect, the Career Path Nobody Explained

John Kilmister, · 13 min read

I have worked in software development for many years now, and for the first part of my career I did not really understand what an architect actually does. I had seen the job title, and over time learnt about good software architecture, but nobody had explained the architect role in practical terms, and how it was different from the activity of software architecture itself.

This post is a reflection on my journey, what changed as I moved into various architecture roles, and the techniques that helped me work effectively across teams. This reflection covers my personal journey and the lessons I have learnt so far, but I hope it is useful for anyone considering a similar move or just curious about what architects actually do.

In the Beginning

Like many developers, I started in a small team of about 5 people in a relatively small company where everyone did a bit of everything. There were no dedicated QA engineers, no business analysts, and definitely no software architects. As my career progressed at the company, the career ladder looked quite typical: developer, senior developer, then one day lead developer.

Eventually, I moved on to the next company and found a similar pattern. The teams were much larger, but the career path still followed the same pattern of roles: developer, senior developer, team lead, department manager. This time, we did have dedicated QA engineers and business analysts, but there was still no architect role (not that I really knew that was a thing at that point), with software architecture tasks being done by the team leads, of which I would become one. Being a larger company, I did learn a lot more about software architecture and building resilient global systems, but as the team grew, my responsibilities shifted. I also got more experience with technical strategy and design, but overall, the trajectory of the job eventually evolved into more and more people management and less and less technical work.

At the time, I did not see that as a problem. I enjoyed the work, and I thought that was the only progression for someone who wanted to have more impact on the organisation. I was still writing some code, but I was also hiring, structuring the team, and taking on leadership responsibilities.

Need for a change

More years passed, and I next moved to a company to help set up a new engineering team in a large established company. The company was growing fast, and the team grew from one engineer to around fifty in a couple of years. As the team grew, my job kept evolving, eventually splitting into two different roles near the top of the technology side of the organisation. On one side, I was doing technical work: proofs of concept, build-versus-buy analysis, technical strategy, and design guidance. On the other side, I was doing people management: hiring, structure changes, and leadership responsibilities. This was an exciting time, but it was also a very busy time. I learnt about team topologies and how to structure teams for scale, but I also had to learn about architecture patterns and how to design systems that could grow with the company.

Both of these sides of the role were very important, but trying to do both at once meant neither got enough attention. I was no longer close enough to the code to answer every technical question confidently, and I did not have enough time to support people in the way they deserved. So I started to think about how to split those two roles, and what the right path was for me.

The Trident Model

alt text

It was around this time that I discovered the the trident model by Pat Kua, and this helped me frame the options: management, individual contributor, and technical leadership as separate progression routes. This was a revelation, as in the organisations I had worked in, there was only one path, and it was the management path.

I moved onto the technical leadership path and took on a principal architect role, and a head of software development was hired to take on the other part of the role. That change clarified expectations, being a technical leader; however, it was not until later that I would really appreciate all the different types of architects and really build the toolbox and skills needed.

Understanding the Role

When I eventually started to look for the next role, I found that architect job descriptions were all very mixed. Some were very focused on technical strategy and design, while others were more about cross-team alignment and standards.

Job Titles

One of the biggest things I learned after taking an architect title is that the word architect covers many different jobs. Each company is different so what the titles mean can vary widely so this next bit is a huge generalization.

Red Hat Architect Types

The first thing I identified between the different architect job titles about scope of planning vs technical depth. As a general rule, I found that an Enterprise Architect role usually works at organisation level with a long planning horizon, often three to ten years. A Solutions Architect usually sits closer to programmes and major initiatives with a shorter horizon than enterprise architecture, often one to three years. Then there is a set of specialist architect roles, including cloud, software, network, AI, security, and data architects. These roles are a lot closer to delivery teams, and the horizon is often near-term, from current delivery up to the next year. The work includes technical standards, non-functional requirements, platform direction, and cross-team technical alignment.

From personal experience, few companies have all of those roles, and the responsibilities can be distributed differently, either in dedicated roles or responsibilities of other roles.

Red Hat Architect Types

Source: (What type of IT architect are you?)

I also found a great diagram from Red Hat that broke the architect roles into Business-oriented, Developer-oriented, Vendor-oriented, and Operations-oriented.

The Responsibilities

Initially, I found it hard to understand the split of responsibilities in the development team and how a software architect would fit in. I learnt that while the developer role is focused on Implementation, the team lead on Delivery and people management, the software architect role is about structure, alignment and strategy.

This usually means setting direction, shaping standards, supporting non-functional requirements, and helping teams make decisions that still work at organization scale. This is why the role becomes more important as the organisation grows, as more teams and more complexity mean more need for alignment and standards while preserving team autonomy.

This includes tasks such as setting a technical vision and golden path, deciding trade-offs, setting technical standards, helping with build vs buy decisions, supporting teams with non-functional requirements, and helping teams make decisions that still work at organization scale.

It can also include working with team leads to help unblock and resolve conflicts, risk management, and planning. Then, work closely with developers to help with technical challenges, and support them with design and architecture decisions. Proof of concepts and technical spikes are also common tasks to help teams evaluate new technologies or approaches and allow us to stay both ahead and hands-on.

If you want a broader map of architecture thinking beyond this post, Martin Fowler has a solid Software Architecture Guide.

I have also found Pat Kua’s Tech Lead Circles of Responsibility useful for explaining where architecture support begins and ends when working with delivery teams.

Placement in the Organization

The role of a software architect can be placed in different parts of the organisation. As a major part of the role is about cross-team alignment, architects often need to partner with multiple teams and departments. At the same time, technical architects also need to stay close to delivery teams to understand the technical challenges and constraints they face.

In some companies, architects are part of a central architecture team that provides guidance and standards across the organisation. In others, architects are embedded within delivery teams, working closely with developers and product managers to shape the technical direction of specific projects.

For me, in my first architect role, I was the only Architect, sat across all the engineering teams reporting to the CTO. The following role was similar, but this time I worked in a team of software architects, with each of us closely aligned to a select set of delivery teams.

Misconceptions

There are a number of pitfalls and misconceptions about the architect role that I have encountered over the years. Here are a few of the most common ones and how I have found to avoid them.

Everyone is an Architect

We don’t need architects; everyone can do architecture. This is a common misconception that I have heard many times. It is true that software architecture is a team activity, and everyone can contribute to it, but that does not mean we do not need the role of architects.

If we think about quality assurance or security. These are also everyone’s responsibility, but we still have dedicated roles for QA engineers and security specialists. Architects play a similar role in ensuring that the overall technical vision is maintained and that teams are aligned with it. Architects act as the “keepers of the vision,” ensuring that coding decisions don’t accidentally compromise the overall solution. This becomes increasingly important as the organisation grows and more teams are involved in building the system. Without architects, we risk creating a fragmented codebase where every team does things differently, making it harder to maintain and evolve the system over time.

Teams Need Autonomy, Not Standards

The second is that standards reduce autonomy. In practice, good standards create guardrails, not barriers. We need standards to ensure consistency, maintainability, and scalability across teams. Without them, we risk creating a fragmented codebase where every team does things differently, making it harder to maintain and evolve the system over time.

Teams move faster when there is a clear default path and a lightweight way to justify exceptions. Personally, I use ADRs to make exceptions visible and to help teams evaluate trade-offs when they need to deviate from the standard. This way, standards become enablers of autonomy rather than constraints. In some organisations, ADRs can replace the need for Architectural review boards. Tech radars can also help make standards visible while still leaving space for controlled experimentation.

Architects Need to Know Everything

It can sometimes be assumed that architects need to be the technical experts in every area of the system. This is not the case and cannot be done practically. The teams that work on the code know the code best, and architects need to trust them to make the right decisions. Architects need to have a broad understanding of the system and the technical landscape, but they do not need to be experts in every area. Instead, architects should focus on facilitating discussions, helping teams make informed decisions, and ensuring that the overall technical vision is maintained.

Ivory Tower Architects Stereotype

There is a stereotype of architects being detached from delivery and only focused on high-level strategy. This is a failure mode that I have seen in some organisations, and it can lead to architects making decisions that are not grounded in the reality of delivery teams.

The best way I have found to avoid it is to stay hands-on with technical work that supports teams: proofs of concept, internal tooling, platform adoption, and targeted code spikes. You do not need to own product features to stay grounded, but you do need regular contact with the same workflows and constraints as delivery teams.

The second way is often early collaboration, bringing people on the journey with you. This is not just about communication, but also about co-creation. When teams are involved in shaping the technical vision and standards, they are more likely to buy into them and follow them. It also helps architects stay connected to the challenges and opportunities that teams face on a day-to-day basis.

The Toolbox

Over time I found that software architecture is easier when communication is structured and decisions are visible. I wanted to share here a few tools I have found useful in my journey as an architect, and that I think are worth considering if you are moving into a similar role.

Storytelling

Storytelling became more important than I expected. Change only works when people understand why it matters, what is changing now, and what is coming next. Regular architecture updates helped keep that narrative clear, focusing on what we have done, what we are doing and what we will do.

For anyone wanting to improve this skill, TED Talks: The Official TED Guide to Public Speaking is a practical reference.

Architecture Diagrams

It is a bit of a stereotype that architects draw a lot of diagrams, but I have found that good architecture diagrams are a powerful tool for communication. They help teams understand the overall structure of the system and how different components interact with each other.

Diagrams often have the issues that;

  • They use UML (so you have to read a book before you can understand them)
  • They use AWS/Azure icons that only make sense to architects and cloud engineers
  • They are so detailed that they are hard to read and maintain
  • They are too high-level or too low-level to be useful for most conversations

C4 diagrams helped standardise system communication and resolve these issues. They made it easier to discuss architecture with both technical and non-technical stakeholders without switching notation styles every time.

It is also important that teams own the diagrams and that they are living documents that evolve with the system. This way, they become a useful tool for communication rather than a static artifact that is quickly outdated. As an architect, I found it useful to partner with delivery teams to create and maintain these diagrams so they feel ownership and are grounded in the reality of the codebase.

ADRs

ADRs were equally important. Recording technical decisions in the repository gave teams historical context and reduced the need for heavy approval boards. If you are starting out, these Architecture Decision Record examples and templates are useful, and the UK Government also publishes an Architectural Decision Record Framework.

Tech Radars and Developer Portals

Tech radars also worked well in larger organisations. They made standards visible while still leaving space for controlled experimentation. The Zalando Tech Radar is a good open-source implementation.

When you combine those with a developer portal such as Backstage, knowledge becomes much easier to discover and share.

Summary

Moving from developer to architect is less about becoming the person with all the answers and more about helping teams make better decisions together.

For me, the shift was about choosing a technical leadership path, improving how I communicated change, and using lightweight architecture practices that scaled across teams.

If you are considering the same move, start by shaping standards where they are missing, broaden your view beyond one codebase, and make technical decisions more visible through tools such as ADRs and C4 diagrams.

Title Photo by Photo by Mitchell Luo on Unsplash

Recent and Related Articles