Patterns and Prototypes: Inside the Architect Archetype
Part 4 of staff engineering 101 covers the architect role
—
Last time, we covered solvers who go deep on complex, high-value problems and bring a toolbox built around experimentation, design, and team handoff. This week, we’re diving into architects.
Architects are masters at taming complexity through elegant systems and infrastructure design. They do this by having depth in one or more areas and enough breadth to understand how their designs fit into the bigger microarchitecture.
The architects I’ve worked with tend to exhibit these qualities:
Understanding the macro architecture and the business
Designing with Others and Rigorous Review
Execute and prototype to validate
Let’s step through each one with specifics.
Understanding the macro architecture
Teams and charters rarely are perfect, and software design will often mirror communication and team structure (e.g., Conway’s Law). As a result, teams will sometimes have blind spots and may design systems or architectures that make sense to their teams’ charter but don’t make sense in the broader architecture of their engineering solutions.
How this may manifest is:
Architecture Debt - This often exists in tightly or improperly coupled systems, and areas with fragmented or unreconciled duplication of capability.
Extensibility Debt - A system can often be well-architected but may be difficult to integrate or extend for other use cases. Narrow or rigid system designs are often a result of a lack of considering future business needs and thinking about how others may leverage the solution
Great architects design for the future and have a fair bit of depth in business needs and direction. This allows them to make design decisions today (e.g., choosing to design a more modular/extensible system may take more time in the short term, but allow future use cases the architect may forecast).
To develop this skill, I recommend a few songs to jam to:
Understand the architectures around your team (integration points, dependencies). Talk to those teams, look at their infra diagrams and designs, see what’s working and what’s painful.
Understand the business direction. Do you work directly on the initiatives called out in the plans, or are you part of a platform team? Either way, steer your designs so that they don’t just serve today but also in 2 or 3 years.
Designing with Others and Rigorous Review
In my experience at Netflix, architecture has historically had a bit of a “bad name.” If you’ve come from another FAANG+ or legacy tech company, you may be familiar with the architect who pontificates in front of a whiteboard but rarely designs systems people can deliver. We'll touch on this disconnect between architecture and execution a bit further, but the perception exists.
I have a colleague who's very much in the Solver camp and who’s also pretty darn good at Architecture. We recently designed a solution for identity translation, but he did this mostly by himself and shared a draft with key stakeholders (including other architects and teams who would execute) once he had a design done.
Folks felt a bit… frustrated at not being brought in earlier. While the design had merit, it would have been stronger if key architects had built with it. It was early enough that we could coarse correct and bring them in.
Additionally, we took that design and performed a review. Design reviews bring experts together to critique a design given a set of constraints and make it better. You invite folks in to provide deep criticism of your work and make it stronger. As a result, there is more shared ownership, which increases the chance of successful execution. I tend to provide this guidance for how to think about how deep to go in design reviews:
To develop this skill, I recommend a few songs to jam to:
Get on a whiteboard early, with other architects and builders. They’ll appreciate being brought in during ideation and get a chance to share feedback and shape the design. It will also lessen the number of loops you may have to run on design reviews
Design Reviews are essential. You can keep them lightweight, but many tech companies employ this practice to level up their designs and team skills.
Execute and prototype to validate
Building on point two, I strongly advocate executing some of the architecture. How do you know your design is good if you don’t see it through some degree of execution?
This could be a variety of approaches:
Prototypes
Building an MVP
Overseeing execution as a tech lead, in the short term
Writing some code, but also not being the primary executor
Separating execution from architecture is important. If the design is good, engineers who are earlier in their career journey should be successful at executing it. If you are involved more hands-on early, you can adjust what’s not working (change designs, introduce new constraints), and also show the execution team you're flexible and open to change. A failure condition is folks trying to execute on something that isn’t working, but they are afraid to speak up because they aren’t sure you’ll listen.
Measuring Success as an Architect
I look at a few key areas:
Are your designs being executed successfully, with teams hitting their key results (and when they don’t, it’s not related to design debt)?
Do your designs go through at least one or two loops of design review? Are you incorporating feedback?
Are you able to transition off of execution early once you see signs of success?
Practice This Week - Draw an Infra Diagram
Do you have something you are building or hacking? Draw an Infra diagram of the product. Consider
Infrastructure (Load balancers, Networking, Security Groups)
Security (Authn/AuthZ systems, others)
Datastores
Application
Tools I like when diagramming
Mermaid Diagrams (Chat GPT is great at generating them)
Exclidraw (can convert mermaid diagrams)
—
Let me know in the comments if this is the archetype for you or if you read this and thought, nope not for me!
-S.B.