I was reading through another spicy blog post written by Charity Majors focused on her experience with the role of the architect at various organizations. There’s a lot of ideas and inputs sprinkled in throughout the article and I generally agree with most of it.
The post inspired me to write down my thoughts on what great architects actually do with their time. It forced me to navel gaze a little, challenge my own assumptions, and think through a bunch of different experiences.
Here we go.
Contents
Context
Let’s start with some context so that we can align on a few things.
First, I’m not in either camp when it comes to using the term architect for a role. In my business, titles are all over the place and I roll with it the best I can to figure out what someone does or does not do. Making assumptions based on title is a brittle pattern anyway.
Second, I challenge the herd in thinking that engineering and architecture are any different. I don’t believe you “level up” into an architect as if your brain suddenly works differently. The only quantifiable difference between the general terms of “engineer” and “architect” is scale (from smaller scope to larger scope, respectively). As I described in the Oxygen Not Included post, we grow in scale from knowers of things to patterns to contracts. I feel this is not only more realistic but an easier method of measuring both growth and success of your team members.
For the rest of this post, I’ll be using architect to mean the person in the RACI matrix as “responsible” for seeing the success of the product or mission.
With that said, what do great architects actually do? Let’s dive deeper.
They Build Guiding Principles
A friend of mine recently asked about what it feels like to become “less technical” as you start taking on team leadership for a group of engineers. I thought about it for a little bit and responded as follows:
I look at it this way. I can architect stuff 80 hours a week and get X done. Or I can lead a bunch of smart engineers to help me build things for 50 hours a week and get 100X done. Who’s more technical than the other? Neither. It’s about scale, not expertise.
An effective leader is one who can impact the organization at scale. Being able to build structure for a team, get them focused and running together, and granting them the agency of ownership over the success of their work.
These should be your personal Guiding Principles carrying you and the team to their desired outcomes. The wind beneath your sails, so to speak. Consider this the foundation for constructing the next layer – team Guiding Principles. The team will use these guiding principles for times when decisions need to be made and you’re not there. It improves the ability for your team to scale and apply logic creatively.
I use PEP20 as an inspiration, with my default being:
- Now is better than never.
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one – and preferably only one – obvious way to do it.
- If the implementation is hard to explain, it’s a bad idea.
- If the implementation is easy to explain, it may be a good idea.
If you’re doing this work at the scale of an entire program, go read Program Leadership as a bit of extra detail to this section.
They Share Ownership
When it comes to building a solution, no one owns architecture and everyone owns architecture. This problem traditionally results in what I have technically coined to be “janky architecture” 😉 that evolves in real time by the persons present at the moment.
Janky architecture smells:
- A bunch of questionable decisions were made and no one who made them remembers why (or is even around anymore)
- Teams are using fundamentally different core design patterns and structure
- Shared services are not available ubiquitously across teams
- Greater than 20% of time is spent keeping the lights on
The root problem to these smells is consistency.
Consistency is the gold standard of a high quality architecture. It is only achievable with a lot of thought, governance, and a safe environment where people can speak their mind. It can be hard to build and even harder to re-build or re-factor, but it is worth the effort.
Achieving consistency means aligning teams to share in the ownership of the design process. And for that, we come to the next thing on the list that great architects do.
They Build Architecture Knowledge Management
Back to my earlier point about joining a project only to find that no one remembers why anything was decided. This is a red flag and, should you encounter this at your organization, the highest priority to tackle.
Great architects spend a considerable portion of their time constructing knowledge management. They understand that what they build is a snapshot in time, that people will step into and out of the project’s journey, and that they are building for their future replacement.
For me, this is often a Confluence space dedicated to Architecture Decision Records (ADRs) and the processes that govern them. ADRs are, in a nutshell, just a record of something you decided to do and the support context behind it.
They Make Decisions With the Group
Adopting ADRs means giving the power of solving a problem into the hands of everyone. It means building processes to intake those decision proposals, review them as a team, socialize what will work and what needs iteration, and finally locking hands on the solution that everyone feels ownership over.
Beyond that, however, ADRs are your lifeblood as the architect.
The cold reality is this: you are too far removed from the work to have the best perspective on how to solve the problem. You have to be that far removed. There’s no way to “see” everything if you’re living down in the weeds. Architects have to see the forest and the trees.
It is vital, then, to have those who are close to the work weighing in on requirements, context, and potential solutions to begin prototyping and modeling a viable way forward. It is also vital to have the team and impacted stakeholders on board and a part of the review. This process will keep you informed on relevant solutions and new technologies while also ensuring that a lot of eyeballs were placed on the design, yielding something far better than what only one or two people could construct.
I won’t go on further about ADRs. They’re great and I use them. Go read Making a Technical Decision for another perspective on this.
They Are a Lighthouse
For everything else, think of yourself as a lighthouse.
- Show everyone clearly where the dangerous rocks are and guide the team to safety as a coach and mentor
- Show everyone where the clear, navigable waters lay while giving them the agency to choose the best route
Remove churn from your team and keep them focused.
Remove thrashing from decisions as a calm, cross-functional presence.
Message to motivate.
People don’t need to report to you to be on your team – make all the teams you need.
~~~
And with that!
✌
