Architects & Tech Leads

What do they do and how do they work together?

In most product development teams we are all aware of the roles that engineering managers and product managers play. What is often more confusing is the other two distinct roles that individual contributors often play on product development teams - architect and tech lead. Today I want to focus on these two roles, how they interact, how they work with product managers, and highlighting potential areas of conflict and the crucial role of engineering managers in resolving these.

Architects

Let’s start with architects. I’ve written recently about the difference between software and systems architecture. The same distinctions are often found in the role of an architect where some focus more on systems designs while others are focused on software architecture. Generally, I find systems architects centralized under a chief architect and software architects are decentralized and work on product development teams. Obviously this isn’t always the case but for today’s discussion, when we mention architects we will primarily be thinking about software architects who are embedded on product development teams. Needless to say, in practice, architects often handle both software and systems architecture but it is helpful to differentiate these conceptually.  

Software architects are responsible for the high-level design and strategic planning of the software. They ensure that the software is scalable, maintainable, and aligned with business goals. Unlike systems architects who may deal with a broader scope of how information flows between systems and how infrastructure scales, software architects concentrate on the software components and their integration. A software architect makes high-level design choices and frames technical standards. This might include tools, software coding standards, or platforms to be used. To be effective, a software architect needs both a broad perspective on current technologies such as frameworks, libraries, and services and a deep technical knowledge of the applicable ones in order to guide their team on how to properly implement them.

Tech Leads

Tech leads, often embedded within development teams, oversee the technical aspects of project execution. They bridge the gap between the strategic direction set by architects and the day-to-day development activities. A technical lead is responsible for helping their team members with the technical aspects of their jobs, such as coding and programming. Their responsibilities include coding, mentoring developers, managing technical debt, and ensuring that the team adheres to coding standards and best practices. They may also explain new projects to their team and troubleshoot any problems that occur. Tech leads might help with prioritization and planning as well as helping to communicate status updates to other teams.

Architect vs Tech Lead

As you can see the two roles are different but have the potential for a lot of overlap, not just between them but also between the engineering manager and product manager roles. While there is no hard and fast definition or role disambiguation, although some companies have tried to develop something of this nature, we can put forward a high level proposal for how the roles differ. Both architects and tech leads significantly impact their teams, albeit in different ways. Architects provide a roadmap, guiding principles, and a vision that shapes the project's direction. They influence through their expertise in software design, often setting standards and frameworks that teams follow. Tech leads, in contrast, are more hands-on, directly influencing the project's progress through active coding and problem-solving. They are instrumental in translating the architect's vision into tangible results, often acting as a liaison between the development team and the architect. While architects ensure that the technical strategy aligns with long-term business objectives, tech leads deal with the practical aspects of implementation. This dynamic can sometimes lead to differing priorities, where architects typically advocate for sustainable and scalable solutions, while tech leads tend to manage the immediate technical challenges and team bandwidth. This is when engineering managers need to step in to resolve these disagreements or differing priorities.

Architect & Tech Lead vs Eng Mgr & PM

The relationship between architects, tech leads, engineering managers, and product managers is a dance of balance. Product managers define what needs to be built, focusing on user needs and business goals. Architects and tech leads then translate these requirements into technical solutions. Engineering managers oversee the work, manage the people on the team, and ensure tasks get accomplished. This all sounds neat and tidy on paper but the problem with these clearly defined roles is that rarely is how this is done in practice. The reasons for this are numerous and include people’s skill sets, their predilections to certain types of work, the relationships between people, and of course the culture and norms of the organization.   

Before we get into how these should work together symbiotically, let’s focus on how conflicts arise. Differences in vision, approach, and priorities between architects and tech leads are not uncommon. Architects might emphasize a robust, scalable architecture, which can conflict with the tech leads' focus on meeting immediate project deadlines. These situations necessitate the involvement of an engineering manager who can mediate, align priorities, and ensure that both long-term and short-term goals are met in a balanced manner. While engineering managers might help resolve conflicts between architects and tech leads, they also might cause conflict by interjecting their opinions on how much tech debt can be paid down while still trying to meet deadlines or project goals. Product managers also have a perspective on all of this and want to have a voice in how the team should balance short term accomplishment of goals with long term investment for easier and more rapid development in the future. 

In the past when we approached software development like a manufacturing line, with a waterfall methodology, each role played a specific part and their span of control and authority were well defined. The problem with this is that software isn’t best developed this way. The folks who gave us the agile manifesto saw the problems with this approach and outlined principles such as “Individuals and interactions over processes and tools.” As no doubt many of you have seen, often engineers have brilliant ideas in the discovery phase and product managers have great insights in the delivery phase. If we relegated them to their respective areas of specialization, we lose all of these opportunities to produce better products. In one of Marty Cagan’s recent posts co-authored with Spotify coach Joakim Sundén he states:

Like other product model companies, Spotify recognizes that the most innovative ideas—those that truly resonate with customers—often originate from those who engage with the enabling technology daily – the engineers. They are uniquely positioned to identify emerging possibilities. 

In the diagram above, I’ve depicted the four main roles in product development teams that we’ve been discussing. There are quite a few others including the actual engineers, designers, researchers, and analysts. You could try to force the use of a RACI or some other framework designed to clarify and define roles and responsibilities in cross-functional projects and processes. However, doing so in my opinion is a failure of team building and leadership. Think about the best teams in the world, e.g. special operations forces or professional football teams. Each person brings skills and is assigned a role but they aren’t expected to “stick to their lane” during the action. On the very best teams everyone can pitch in where and how the overall mission is served best. Of course, if you don’t do your own role well and keep jumping into other people’s areas but not adding value, you will quickly be replaced. When everyone on the team does their role really well and adds to other areas, that’s when the team is way more than the sum of the parts. 

In modern software development we think of the team as jointly discovering, developing, delivering, and supporting the product. As the team is responsible for the entirety of the process, there aren’t areas of sole responsibility. Rather, each team member brings their own individual strengths and skills to bear on a problem. During some phases of problem solving, one person might play a supporting role whereas in a different phase that same person plays a leading role. This flexibility allows everyone in the team to play the part best suited for their skills and interests. For example, if the team is working on an optimization of a page, the architect might not play much of a role during discovery. However, if the team is launching a new feature the architect might be highly engaged during discovery as their knowledge of what data is already being collected might be invaluable.  

If you leave this article thinking about the role of the architect and the tech lead as “it depends” you’re not far off the mark. They definitely do have prescribed roles, responsibilities, and areas of focus. However, on the very best teams they compliment each other as well as the other leadership roles including engineering manager and product manager. If the tech lead has particular knowledge about a domain the architect should be willing to let them voice their opinions. If the architect has particular opinions about priorities or how to deliver something, the tech lead should encourage them to speak up. In this way we take advantage of everything everyone on the team has to offer. Of course there will be conflicts or disagreements and that’s when understanding who gets to make the final decision based on roles is useful. This is also why we have an engineering management chain of leadership. We should expect to need to escalate things periodically. This is when we get to disagree and commit, which is a thought for another day and another article.