The Roman statesman Cicero once said:
As a general truth, as it seems to me, it is weariness of all pursuits that creates weariness of life.
Here, we find an ancient observation of burnout.
To put it another way, when there is a sense of "nothing up from here," people become weary.
In the realm of software engineering, this phenomena is not uncommon.
It is well known that impostor syndrome can cause weariness due to a lack of assurance of being able to fulfill the responsibilities of a role. However, this sort of weariness protects from another sort of weariness--the "nothing up from here" weariness.
Impostor syndrome implies that there is an up-from-here. Namely, there is an active pursuit in becoming more confident in one's skills and fulfilling the responsibilities of a role.
Burnout can happen when impostor syndrome is accomplished and engineers mature.
They may have mastered their ability to be a sound contributor--they can do their job flawlessly. Then, there comes the creeping thought of "now what."
This creeping thought may be prevented when the following circumstances are sturdy:
- The business is doing well and morale is good.
- The product team one is working on has a strong mission-mindset and great chemistry.
- Compensation is good.
- There are open-ended challenges that require rigorous technical collaboration.
- There are ways to master one's craft in step with product development.
- One is in a very specialized role that affords a lot of freedom and creativity (e.g. a design system developer).
- There is focus.
- There is clear visibility into what is being worked on and why--and who made the decision and what for.
Usually, when teams breakdown and weariness ensues, it is due to more senior engineers burning out. They burnout when those pleasant circumstances previously described begin to evaporate. It has a cascading effect that can seriously harm the bottom line--whether higher-ups admit it or not.
You see, all the circumstances described above are"up-factors."
- The business is doing well --> I'm contributing to something that's successful.
- The product team has great chemistry --> The product team is presenting a strong vision of what we are working on, and the engineers are collaborating well to implement that vision. We're on a mission.
- Compensation is good --> I have a bonus to look forward to.
- There are open-ended challenges that require rigorous technical collaboration --> I'm learning a lot about the product and big-picture technical decision-making. I'm excited for the next product.
- There are ways to master one's craft --> I'm able to try new technologies and design patterns in the codebase. I'm excited to share the next one I'm working on.
- One is in a very specialized role that affords a lot of freedom and creativity --> I get to build out a design system. This is a really fun project. I can't wait for it to be implemented across our various products.
- There is focus --> I know what I'm working on and can easily find a way to resolve the situation if I don't. I can come into work ready to get things done.
- There is clear visibility into what is being worked on and why --> my team is on a mission, and I see how this ties in with the broader company's mission. I can't wait to see what we accomplish.
Many more examples may be given, but all of these provide up-factors. They fuse together personal accomplishment and a team mission.
From the vantage point of a junior engineer, these "up-factors" (or, the lack thereof) are important but not as impactful when compared to senior engineers. The reason being is that junior developers don't have as much to compare to, and they are motivated by being able to do what they're asked--they are less cognizant of the why things are being done and how to do them very well.
Case in point, junior engineers usually need direction to move beyond meeting the bare requirements of a story/ticket. They need to not just get their code to work, but for it to meet a good level of quality. This requires refactoring code and a large amount of intentionality. In addition to code quality, there is a such thing as an organization quality. Senior engineers becomes more cognizant of organization quality and its importance than junior engineers.
Organizational quality goes down when the up-factors evaporate.
From the position of a senior engineer, it can be quite illusive to sense when things are evaporating. It is not as if all circumstances are pulled out from underneath. Rather, there is a sort of death by a thousand paper-cuts--death by the slow removal of "up-factors."
- The business is doing well --> We had a bad quarter. We have to hit all our marks in the next one.
- The product team has great chemistry --> The product manager now owns multiple teams and their appearance is more infrequent (and hence, the collaboration and visibility that developers previously has implicitly been removed).
- Compensation is good --> No bonus this year.
- There are open-ended challenges that require rigorous technical collaboration --> The product team starts to make decisions without developer input, providing tightly-defined sets of work for them--the team starts to work like contractors.
- There are ways to master one's craft --> There is not enough "bandwidth."
- There is focus --> The developers become cross-functional across multiple projects because some far away higher-ups said so.
- There is clear visibility into what is being worked on and why --> The team is split in too many directions. It's hard to keep track.
The removal of these up-factors will certainly weary senior engineers.
So, what does this mean? It is imperative for software engineering management to factor in the intangibles, to present up-factors and maintain them as if it does impact the bottom line (which it does)--to not hyper-analyze efficiency (by which only short-term efficiency is assumed).
Where do you see a need for up-factors?
By the way, I wrote a book on trying to rethink Agile and present up-factors if you're interested.
Top comments (0)