Every Engineer Is an Architect — The Evolution of Technical Leadership

March 8, 2021

ICONIQ Growth Technical Advisory Board

The prevailing trend over the last 10 years has been to create small, agile engineering teams with decision-making pushed to the edges of the organizational graph. While this results in far greater development velocity, it often comes at the expense of strong and consistent technical leadership, particularly for larger organizations. Frequently, the lack of a consistent guiding hand is only felt as organizations hit painful technical scaling inflection points. More recently, there’s been a trend to reinstitute the role of technical architect to help accelerate progress in solving the thorniest, cross-cutting technical problems. This is a tricky role to get right given the egalitarian ethos of modern engineering teams.

Aditya Agarwal, Jeff Rothschild and Keith Adam — a dream crew of early engineers at Facebook and Slack — participated in an ICONIQ Growth roundtable to discuss their experiences striking the balance between a fast-moving and decentralized organization and strong technical leadership. The following is a summary of their comments.

The Decentralized Model

The centralized model — operating with a structured and hierarchical approach to creation, reporting, and growth — was overthrown by early technology leaders like Facebook. In a response to the antiquated, and inefficient centralized concept, companies adopted the decentralized model — small, nimble teams that were close to the product.

The decentralized model allows for engineers to envision, build, and own the final product. This provides a sense of investment that ultimately galvanizes the creative process and entrepreneurial innovation.

However, that lack of standardization and the environment of testing — which Jeff referred to as the “Wild Wild West” — comes with its own host of considerations. To find success in a decentralized model, leadership must keep the team in sync, like rowers on a boat.

Meanwhile, some standardization should be implemented. Organizations should determine a primary programming language in order to streamline code bases and increase operational efficiency. In addition to design review and coding standards, there should be standards on testing, release, configuration management, version control, and monitoring, among others. Shared infrastructure and cross functional projects must be done with some central authority to ensure clear communication and efficient timelines.

It’s interesting to note that the underlying programming languages and abstractions have all evolved to allow for more decentralization via object-oriented programming, service-oriented architectures, etc. Modern software engineering processes also have shifted from top-down waterfall planning and tracking toward alternate methodologies like agile, scrum, squads, etc.

Our panelist made it clear, however, that the best people produce the best outcomes. A motivated, engaged, and committed team — more so than a specific organizational structure — is the key to efficient collaboration and progress.

The Role of the Architect

A chief architect is a c-suite executive role responsible for setting an organization’s technical strategy and leading, guiding, and mentoring distributed engineering teams. The chief architect also serves as an advisory to the CTO, CIO, and SVP of engineering in order to ensure alignment, quality, and scalability. Architects are the central authority on technical strategy and standardization.

There is a strong belief that architects must still code and have the ability to build anything an engineer can. Yet the panelist noted that qualities such as empathy, communication strategy, and leadership skills are equally as important as an architect’s tech skills. Keith Adams reflected upon his time as chief architect at Slack, sharing that he believes he would have been even more effective in his role if he had focused less on building and more on sharing. “An architect can only be successful if their ideas stretch deep into the organization,” he said. Therefore, an architect should spend significant time continuously communicating, sharing, and reinforcing the technology vision and strategy, and the reasoning behind them.

There is debate over the value of the architect title, and hierarchical titles for engineers in general. Jeff advocated against titles, with the belief that instilling a sense of ownership — “all engineers are architects,” he said — and creative agency would better motivate engineers. While Jeff may think that ideas are more important than a title, Keith argued that titles motivate as they allow engineers to identify a progressive career path, and also help them to more effectively communicate outside of the organization.

Technology Roles Today

Aditya, Keith, and Jeff agreed that the flexibility and creativity afforded in a start-up versus a large corporate company may make the former an easier and more appealing work environment. The software profession has grown 100X in the last 30 years, with an emphasis on young people, making the field harder to break into.

Key Learnings

While the hierarchy of a centralized model may not be the best organizational design for creativity, it is sound to establish best practices early on. Launching open and participatory code reviews and shared design reviews, requiring stand-ups, and encouraging all team members to present, ask questions, and give feedback allows everyone to assume a bit of the architect role. Sharing knowledge is critical for a team’s efficiency and inspiration. Following just a few of these practices can unite the opportunities for unstructured innovation present in a decentralized system with the best practices of a hierarchical company.

Missed the event? Watch the recording here.