Gratification for architects
Gratification is the pleasurable emotional reaction of happiness in response to a fulfillment of a desire or goal.
As a software architect, there are some projects that I've been working on for many months. This week a work stream that I helped start almost a year ago finally got completed and reached closure. It was a fulfilling moment and reminded me about the longer cycles of gratification with increased seniority.
Early life as a software engineer was simpler. Most projects had clear requirements and the hard parts were getting the project completed based on technical constraints. Programming languages, software libraries etc were my primary tools. Completing tasks showed clear progress towards completion of projects. Though there were last minute changes in project scope at times, for the most part life was simpler. It was easier to feel a sense of gratification.
Now, as an architect projects are much larger in scope and complex. Laying out the vision for particular areas is hard, requiring knowledge of the current domain and also having a sense of the future. Since projects are longer running, the feedback loops for any gratification are longer and sometimes missed. Contributions on projects are also different at senior levels. At times you are just helping in an advisory role, sometimes helping to initiate a project and raise funding. For a few you work actively and clear out technical hurdles. Often you need to work with stakeholders across functions to solve complex non-technical organizational hurdles. As an individual you need to look at being aware of how your work is impacting the people and projects. Just working without feeling connected or getting the sense of gratification will ultimately lead to a lack of motivation. Hence as a new architect you should be prepared to see a shift on how you will get feedback and hence any gratification. Based on your active or passive participation in a project, set valid expectations.
At senior levels, you are likely also trying to handle many projects or maybe some larger projects with increased risk. I try to balance a portfolio of work with some small low risk and one large high risk project. Projects fail for many reasons. Sometimes the timing is not right. Even if the idea is sound, the supporting environment for the project is not ready. For one multi-year project that we're working on, the environment has changed enabling the same idea but in a completely new packaging. You have to build an intuition and evaluate ideas based on a holistic set of parameters but at the same time be ready to adapt. De-risk projects as much as possible and hope for success. However in the technology industry we have rapid change. You need to lean into the future and look for common problems. Align with business and chart out where technology is going. Disruption is always happening. Take some bets. You also have to let go of some promising opportunities. Also know that bigger changes take time to take effect.