Last week, I was promoted to the position of CTO at Adafy. Partially due to this promotion, I’ve been reflecting a lot lately on the significance of the architect role and the career path to becoming one. The prevalent notion suggests that the career trajectory for a software developer is Software Developer => Senior Software Developer => Software Architect. However, there’s a slight contradiction in this, as the role of a Software Architect is quite different from that of a Software Developer, yet of course it’s difficult for anyone to work credibly as a Software Architect without experience in software development.
Attributes
Approaching this career path dilemma, I started by simply listing the skills and qualities we expect from someone working under the title of Software Architect. This listing resulted in what I call the skill wheel of a Software Architect, consisting of three main areas: leadership, technologies, and customer work. Technologies are a fairly obvious aspect, listing the key technologies of the company. For example, at Adafy, this slice includes Azure, ServiceBus, Logic Apps, C#, NoSQL, Microservices, etc. The leadership aspect involves team management, training, and innovation. Not all companies have architects leading teams or responsible for internal training, but since Adafy is a company of fewer than 50 employees, our architects are also responsible for running teams, defining, internal training, and seeking new customer solutions. So, the role is quite comprehensive.
In the customer work aspect, I listed communication skills, negotiation skills, documentation, prioritization, etc. Communication is a significant part of the software architect’s work in the 2020s, and in smaller companies, proficiency becomes even more important as small companies usually lacks the project managers and account managers.
Architect or Architects?
As I filled out the skill wheel from Adafy’s perspective, I found that just in the areas of leadership and customer work, I had listed over 30 skills we expect from an architect. That’s a staggering number when you add almost the same amount of different technologies on top. Due to this vast skill set, I have been considering the option of differentiating architect roles into more specific, better-defined roles. For example, Solutions Architect, Azure Architect, or Integration Architect. With a more detailed role description, we can better delineate the required skills. An Azure architect, for instance, might be expected to have a deeper understanding of Azure, but on the flip side, they should be able to focus more on the technical side and less on team management. Similarly, a Solutions Architect is more sales-oriented and supportive of sales.
Through defining more specific roles, we can reduce the number of required skills and, on the other hand, better define what an architect does in the company. The definition of the architect’s role is not yet complete, and I haven’t been able to finalize the definition yet. However, the work is important because often in companies, we place expectations on employees regarding their skills and job description, but we may not necessarily communicate our expectations to the employees accurately enough. For example, we might expect an employee to be good at documenting their work, but we don’t tell them or provide sufficient training on the matter. We set silent expectations and simply expect things to happen as we have envisioned. This combination easily leads to conflicts and disappointments for both parties. By defining job descriptions more precisely (in collaboration with employees), we can simultaneously communicate our expectations outwardly.