Architecture Reflections: What do I do?
Not too long ago, I replaced my job as a midlance cloud/data engineer to start as a Data Platform Solution Architect. In this blogpost, I would like to share some of the experiences with regard to transitioning from more of a tech lead, into something between an individual contributor and an Architect.
What do Architects do?
Architects are an odd bunch, and so is often their job description. Moreover, there’s enormous variety. Ask 10 different Architects to describe their role, and you will get 10 different answers. It is quite fun actually. Trust me, I do it all the time!
Becoming an Architect means answering more and more of these kind of questions: What do you do exactly here? Or, so when do I involve you again? And sometimes even; why do I need to you at all for my project?
Thankfully, some folks are doing a great job providing more clarification into what it means to grow into a role of leadership outside of management, like an Architect. I particular like the work by Will Larson. His whole definition of Staff Engineer and its archetypes is tremendously useful, as is his collection of stories from Staff Engineers and Architects.
Some even go so far as describing their role in essence as “whatever is needed for the company to succeed”, thereby jumping from engineer to PO, to projectmanager, to whatever is necessary. Even though this might be true, naming these kind of work activities as anything else but “glue” might make actual POs and managers around you anxious.
Luckily, because you are asked more often what you exactly do you’re able to iterate on your answer and improve! As such, even though the work definition can be more abstract, I find it often easier to explain to people than before!
Next to that, the somewhat lack of a clear work definition can also be useful. Especially when people are not really asking “what do you do?” but rather “what is it you can do for me”, I have occasionally used this freedom to define specific work relations.
What I mostly have been doing as an Architect
This is my blog, so let’s talk about me! :)
Much of the work of the last 2 years can best be qualified as Tech Lead or Individual Contributor; leading the implementation across multiple teams and picking up crucial engineering work between those teams that nobody directly feels responsible for or POs undervalue. Sometimes because it involves technologies or solutions the teams have not really been exposed to, and sometimes because several teams have to be involved across the organization, and perhaps even outside of my department.
The book by Harmel-Law defines this approach more roughly as a hands-on Architect, and very accurately describes some of the risks. Namely; strong cognitive load requirements, lots of context switching and the risk of becoming a bottleneck for multiple teams if the Architect is too central in overall decision-making. It’s an unsurprising reflex of someone who used to be an engineer himself, but the overexposure to detail across the board can make it difficult to also look at the bigger picture.
It’s also not really sustainable. Worst case you end up with a burnout, but probably you’re both holding back your department as bottleneck as well as your engineers in their own development and carreer progression. Engineers need to be exposed to Architecture decision-making in order to grow as engineers, both for themselves as well as the company. Because so is the nature of IT, and the underlying complexity it’s trying to manage.
What I will be Doing as an Architect
In the previous quarters, my department has been reorganized thoroughly, and lot of engineering expertise has been hired. Rather than solely focusing on data analytics, we are bridging the gap with the operational systems by hosting data-intensive and AI-intensive applications. Needless to say, this has also influenced my role and the expectations towards it from my organization. Rather than being hands-on involved and often even reviewing Pull Requests, the organization has been starting to expect me to take more of a systems view and articulate the future technical direction.
The project is growing, the teams are growing, and in the background AI created an expectation of continued future acceleration. Therefore, not only the underlying complexity within the content is greatly increasing, but also the complexity within cross-team communication and collaboration. More people means more connections, more potential loss of information and self-organization becomes more challenging. Off course there’s also more opportunity.
I am seeing that systems thinking is becoming more and more important, and I’m greatly investing into my own thinking and skills by taking a variety of courses on architecture, design as well as communication and storytelling. Next to that I have recently started to work with a speech coach to improve my own clarity of speech and fluency. As a recovering stutterer, I have firsthand experience how important that is when trying to convince people you do not know very well.
Next to that I’m explicitly bringing some of my old responsibilities to the team by redefining some of the definitions of our architecture practice. Rather than being involved with within-team decision-making, I’m setting up the rules and requirements of the decision-making process itself, and thereby frame the decisions. There are cases where I expect to have to step in or take over the role of decision-taker, especially when decisions go beyond the scope of a single team or touch multiple teams. It’s a process of calibration. Next to that there are off course also the system-wide problems for which I remain in the lead.
Finally, there is also the larger organization beyond my department, and it is becoming increasingly important to seek alignment across the business as a whole. Not doing so makes it more likely that past decisions, as well as past efforts, are reverted in the future. This happens off course all the time, as well as people reinventing the wheel, but the probability can significantly be reduced if we bring a larger part of the business along on our journey. That mostly means more often presenting our work, both internallly as well as outside the company. And blogging more often off course!