Chamber 🏰 of Tech Secrets #5
Is there still a place in this world for Architects?
The Chamber of Tech Secrets is open. This week, we’ll dive into the role of the Architect.
Do Architects fit today’s software world?
Are architects value-add roles? Are they out-of-touch with the real realities of software engineering? Useful? Useless? Somewhere in between? In a world that has long valued specialization and division of labor, is there a niche that architects need to fill.. where they can find things to do that “only they can do”?
Baseline
There are many kinds of architects: Enterprise, Solution, Data, Application, Platform, etc.
“Architect” doesn’t mean the same thing in every company.
Software companies and other types of enterprises have different situations. If your company makes software, you likely have engineers on everything you do. In an enterprise that, say, sells chicken, we do not (we might just have a business analyst / systems analyst that owns a domain where we use SaaS exclusively).
Some engineers don’t want anyone to tell them what to do at all. Cool. Other engineers appreciate platforms, standards and guidelines to allow them to focus on their core problem and move faster. Cool. Both of these exist in my organization and likely yours.
Enterprise Technology Architects
For the purposes of this post, I’d like to focus on what I call Enterprise Technology Architects.
Enterprise = scoped to the organization, not one product
Technology = software / infrastructure / platform / technical backgrounds
Architect = focused on how we design and build
Who is the Customer?
These Architects have a complicated customer base. The real answer is “the enterprise” which is just another way to say “the whole company”. Practically speaking, the enterprise is really a bunch of people working on different things: products, outcomes, plans, strategies, building something, operating something. Nearly everyone is a customer in some form or fashion. Business leaders. Initiative owners. Software product teams. Engineers. Fellow architects. Shared Services leaders. And more.
A friend referenced The Software Architect Elevator in a recent discussion. I haven’t read it so I asked my assistant to summarize:
At the lowest level, the software architect is focused on the technical details of the software development process, such as designing software architecture and choosing appropriate technologies. At the next level, the architect is responsible for leading a team of developers and managing the technical aspects of the project. At the highest level, the software architect is a strategic leader who is responsible for defining the technical direction of the organization and collaborating with other executives to ensure that the technology supports the business goals.
The elevator metaphor is useful because it emphasizes that software architects can move up and down these levels of responsibility based on the needs of the project and the organization. It also underscores the importance of being flexible and adaptable as a software architect, as different projects and organizations may require different levels of involvement and influence.
I think this is a good metaphor… being ready to “get off on any floor” and have an impact is a nice way to describe the role of the Architect.
The Hero Culture and Dictator Fallacies
I think the role of an Enterprise Technology Architect is about being a force multiplier for the organization while being careful not to become a hero or a dictator.
People love heroes, but Hero Culture does not scale forever. Being a hero feels great, but when that’s all you do for an extended time you are actually doing yourself and your organization a disservice.
Nobody likes Dictators and they tend to crash their entire system(s) by making decisions they aren’t equipped to make because they are out of touch with reality. They simply see a future (usually that is to their liking) and attempt to force compliance. They are eventually met with resistance from the masses and they lose their influence entirely.
Here are some activities I think technical architects can perform to be force multipliers without falling into the Hero Culture or Dictator fallacies:
Allocate capacity to R&D: allocated time + technical depth + organizational context = ability to do useful exploration of what’s next. Technology Architects can time travel into the future and bring back some practical learnings / technologies that teams can use. This R&D should be dotted line to current state: aware of current challenges but detached enough to explore non-linear outcomes and new ways of operating / building.
Backstop engineering teams on tricky problems: most technology architects have a background in software development, cloud, traditional infrastructure, middleware tools, networking, etc. They are generalists with tons of real-world experience. This means they are capable of helping solve sticky problems and they can be a sounding board or thinking partner for a software engineer that is stuck. In some cases, team’s don’t have engineering / solution architecture capacity at all, so this can also mean serving those teams with design and implementation input.
Put tools in the toolbox: Identify solutions for technology components that are by nature shared across product teams and therefore difficult to deliver in a completely autonomous product team model.
Create software-defined best practices: Create principles, best practices, and lightweight standards that are software-defined and encapsulated within platforms and tools instead of diagrams and wiki pages (though there are places for those to help with building shared context). Consult teams to help them leverage those tools and platforms and augment with human knowledge on things that are difficult to encode.
Look at products from outside in: Bring big-picture, company-wide context to the table and help product teams see things they wouldn’t see otherwise.
Foster alignment: Identify emerging patterns across teams and step in when multiple teams are developing similar solutions. Help resolve conflicts and enable teams to move on with their products with clarity. This is especially important when you have shared dependencies between teams that you can’t remove by other means. In my world at Chick-fil-A this often shows up for solutions targeting physical restaurant locations. We recently did this by bringing a bunch of people together who had a stake in the future of our ML-focused Edge Compute, building a shared context, and charting a path forward.
Mentor, coach, and encourage others: Make sure that when one team wins, everyone wins. Amplify successes and learnings from failures from all the diverse projects you’re exposed to. Build shared context.
Is this all unique to an Enterprise Technology Architect? Of course not. I do think its important to consider that humans respond to incentives. Having people in the organization that have the right incentives and the right focus to do these activities is critical, and Enterprise Technology Architects is one way to do that effectively.
The Perils of the Path
Being a technical architect is not easy and there are several perils they must face to be successful in their quest:
Earning the right to influence: If you want others to listen to you, you first have to invest time in helping them with their problems to build credibility and trust. Everyone that we’ve hired from outside to work on our team has seen early challenges with this, but eventually earned trust and then could influence select items.
Managing influence frustrations: Let’s be real. If you have “seen this movie before” but people don’t listen to you and go a different direction anyway, its easy to be frustrated. All the architects I know want to see the organization succeed and that’s it. They want to make things awesome. They have great ideas. When those ideas are shunned or ignored it hurts. This can be a role that is painful. I think every architect wonders why they even play this role and if they should just change paths at times.
Getting away from the code: When you don’t code every day, you do get rusty. If you stay too high level for too long, you can lose technical context and deep expertise, and then its tough to be effective.
My Experience
Let me tell you about my own experience in this role and use an interesting thread on twitter from Charity Majors as a backdrop.
Grown from within — I was grown from within, which I believe gave me two few very important things:
Context. Business context. Context on historical decisions. Context on the culture. Combining context with technology expertise is a great way to have a big impact, but context takes time to build. Technology without context is, IMO, how it can feel like architecture is “ivory tower”. Context sets the stage for good judgement.
Trust. Experience working with people that build relationships of trust where we were and are able to assume the best about each others intentions and understand that we have a shared goal of making the organization awesome.
Never more than a few years removed from building things
I have tried to learn Spanish for years, but I live in a world where I speak English every day. When I travel to a Spanish-speaking country, I usually get pretty good (relatively — I’m not that good) by the end of the trip. Inevitably a few weeks later, all is lost and I am basically back to the drawing board. The proverbial “use it or loose it” is in effect. Its sadly not like riding a bike.
I believe building software / infrastructure is a lot like speaking Spanish.
A lot of what I do is resolve conflict, create alignment, surface things we need to make investments in, listen to my team and share my team’s views with others. I do not get to build things every day. I need to spend my time on influence activities. I also need to keep a technical foundation such that I can speak the language (like for real, not just the buzzwords). How do you balance this?
Theory of the Waves
I believe in the theory of waves. The theory is simple. To be effective, you must dive deep for a time. You must surface and influence. Repeat.
To maintain a real connection to software and technology, its critical to have seasons of digging deeper and exploring things hands on (or close). If you become a regurgitator of ideas you don’t completely understand, you probably will not be able to help people solve real problems, and you might be replaced by ChatGPT eventually
If you do understand how things truly work, you are uniquely positioned to leverage tools like ChatGPT as force-multipliers, ask for the right things, know how to apply them, and have the ability to help others do so for the good and eventual win of the organization. And you are well-positioned to do all of the force-multiplying activities we unpacked above.
Here are a few insights I’ve had while living this process:
Allocate time to dive deep during the deep-dive seasons. At least 6-8 hours a week. Own your time. If you don’t you’ll be pulled into other stuff. With time, demand > supply.
Write about technical topics to stay sharp and accountable to technical details.
Accept that some seasons will be less technical than others, such as when I spent about 18 months focused on business architecture.
Accept that some seasons will be more technical than others, and that it might be a little painful while you try and immerse yourself again. Use tools to help make that less painful.
Understand that engineers will be deeper on at least some technology topics because they don’t live in waves… they are always deep. This is okay. Listen to these people and refine your mental technology models continuously. Test the ideas on your own though and learn first hand.
Don’t let your curiosity fade. Read a lot. Build things.
When you step away and then return, you’ll find that the painful parts of your organization’s developer experience are amplified. Silly things like setting up development environments or getting credentials might cause you disproportional pain. Use this as an opportunity to drive continuous improvement and make the best developer experience you can.
Teach what you learn, internal or external.
Can you be an out-of-touch, ineffective, frustrating-to-work-with architect? Absolutely.
The opposite is equally possible by applying the wave theory to the architecture role. By staying in touch with reality, architects can avoid the fallacies of the role (hero, dictator) and be force-multipliers for their organization in a way that adds tons of value.
The best article I've ever read on Architect's role and the debates around. The Theory of Waves provides a practical solution to the typical Depth vs Breadth problem for EA's, I'd certainly try that.