I went through a major role change in my professional life recently. I switched from a Front-end Architect position back to a Software Engineer one. When observed from a prism of a corporate career ladder it seems to be a demotion. Yet, somehow, it doesn’t feel this way.

The main reason for the change for me was that my position wasn’t making me happy. One could argue that work is not there to bring joy. Anyway, I can’t help but seek happiness. The joy of creating, learning, collaboration, accomplishment, success. There are a bunch of different definitions and expectations placed upon a software architect in the industry, I won’t go in the details of this particular role. Enough to say that the kind of challenges I faced as a software architect weren’t bringing me joy.

What I realized when I started coding again is that my time as an architect is absolutely not time that was wasted. My perspective on software development matured significantly. Much of that is thanks to my collaboration with other architects who without exception were very knowledgable and talented. In this blog post I want to walk through the lessons I learned as an architect that I see impacting my work as a software engineer.

Praise of voice

I’m kinda shy. Ok, ok, if there was a global dashboard with an average shyness level of the human population I’m pretty sure there would have been a significant increase roughly 30 years ago when I was born. Still, it didn’t stop me from meeting with a bunch of people every week. Most of those events were even hosted by me. Low-profile no-camera participation was definitely off the table. Not only was I able to pull it off but also I was able to enjoy it.

The fear of communication with plenty of people or, to be precise, the fear of making a mistake in front of them is a very strong reason to stay silent. I still see this fear blocking me, I see it affecting other folks working as engineers. As a software architect I’ve seen many more mistakes done by saying nothing. Not being able to communicate plans, changes, a lack of celebration or correcting faults - such things should embarass engineers instead.

Power of writing

Another thing that I appreciate much more now is writing. Thought expressed in writing gets depth. The thought must be formulated with exact words and structure. Once written it has a very interesting property - it persists. The text can now be discussed, critiqued upon and updated. The text can be referenced by people.

Team members communicate in text in many situations, it’s not limited to a remote environment. Writing skills come handy in daily communication, code review, ticket descriptions. All that is important but I would like to highlight one particular application of technical writing.

Even though I wasn’t tracking my work with Jira tickets, many of my duties could be represented as a “Think about …..” ticket worth 2 story points. I was also exposed to so many different ideas, problems, solutions everyday that it was impossible to keep all that information in my mind anyway. My notes became my second brain. Writing thoughts down was the only way for me to handle the load. Interestingly, writing things down led to higher quality results. When I put my thoughts into a document I usually already had a list of a few follow-up threads to explore as a result. I was able to iterate on the ideas and refine them. It didn’t stop at the individual level though. When a team came to me with a written proposal, the quality of the conversation was higher. When I shared some information in writing with one team, I immediately had useful content to share with all of my teams. When I had a written documentation for a project it was much more difficult for others to ignore it. Everything I was involved in was easier and better with a document behind it.

Priorities

I had plenty of opportunities to scale my work with the help of the teams. It usually took the form of a request for research or implementation. What I learned is that a question phrased as “can you do X?” prompts a defensive answer like “we don’t have time“. The teams have stakeholders to satisfy, promises to fulfill, their team spirit to boost. They are fully dedicated with solid plans for the near future. Of course, teams already have more on their plate than they can chew. Anything less would be a bad sign.

There is little discussion related to the lack of time, however, the conversation can become much more productive. Is there anything that the team works on or plans to work on in the near future that is less important that what I am bringing? To prepare for this conversation I had to understand if my request had a healthy rate of interest. First of all there is the effort - the best ideas for me were usually pretty small or ones that could be validated with low effort. However, understanding what value the idea brings and if it’s time-sensitive turned out to be the biggest challenge.

Surprisingly, the “we don’t have time” trap wasn’t reserved to external actors. I noticed that engineers were policing themselves rigorously when faced the high-priority projects. The team was asked to deliver changes as soon as possible but nobody asked for a version full of defects or side-effects harmful for the long-term health of the application.

Leadership

Finally, I’ve learned a very important aspect leadership. It’s a painful experience for individual engineers who spend all their time coding. A leader is needed the most when the group has no idea how to make a change or when they don’t see the problem that would require the change. What first-time leaders are frustrated by is uncertainty, ambivalence or even resistance. On the other hand, if the group has a common objective, is dedicated and skilled to face the challenges and operates like a well-oiled machine - the leader’s work is done and they may feel redundant. Either way it can be an uphill battle. Rewarding, sure, but fuelled by frustration and pain.

Would I do it again?

Absolutely yes! The opportunity to focus a lot of my attention on software development beyond coding opened my eyes in many areas. I had an opportunity to be a part of so many projects at once, an experience unavailable to me as a developer. I see how this time improved me as a software engineer. My contributions to the team have had much broader impact ever since.