Key Things I learned after moving into a Software Architect role
A disclaimer: There have been many articles written about becoming a Software Architect out there (some of my favourites when I started the role was this article “The Path to Becoming a Software Architect”). This blog entry, however, focuses more on what key things I’ve learned since getting into the role — that I hope might still provide some snippets of things to expect coming into one.
First, some establishments of a sort of a baseline.
- I started as an engineer and moved towards a Tech Lead role prior to moving into the Architect role.
- In my case, the role is not a managerial role — I do not have a person or a team reporting to me, hence some of the key capabilities that I did in the previous role (as a direct line manager) were not as applicable moving to the role, but snippets of it are (e.g. coaching, etc).
The intricacies of the role may indeed vary from organisation to organisation, but for myself, I feel like I should establish what being a Software Architect is first to avoid some confusions. With this, we’ll rely heavily on concepts brought forth by Gregor Hohpe, author of “The Software Architect Elevator”.
The great Željko Obrenović, Principal Architect at Adevinta & a colleague (who I do consider as a mentor), brought forward in one of our Virtual Summits last year the notion that Architects are “Super Glues”.
[The Architects are the ones] who hold…