Jun 29th, 2023
Best Practices
Difficulty Itself
Written by: Max Hoaglund, Senior Technology Lead
To manage technology projects means to cyclically encounter new worldly problems of various kinds, and to try and solve them collaboratively within a matrix of varying colleagues and resources. This model of a problem could be parted out into a few detailed takes on different sources of challenge – people, software, culture, time, and so on. In describing approaches to these different problem spaces, I might reference “resources”- skills, money, compute cores, and the precious limited time of people. These are all critical things to manage, and any successful project has managed some or all of them at least pretty well. Yet as I work on my nth project of the year, the details and qualities of all those problem spaces frankly run together. Certainly, a single specific implementation might have been extra-difficult because of a choice of tool or an ambitious timeline - but what sticks out to me is the constant presence of difficulty itself. I think this is an important concept to deal with on its own, disconnected from any granular industry obstacle.
We talk about difficulty together with resilience often. Resilience resides in you, the person taking the action or making the choice. Difficulty seems to reside in the outside world - where your challenge originates from. It would be insulting to resist this postulate completely and trivialize difficulty as solely existing in the realm of perception. However, it’s also true that since it’s a phenomenon with a name, it’s something we all have tacit beliefs about. It’s helpful to be aware of those beliefs, since they may be governing your interactions with and perceptions of difficulty, and of resilience.
In my best moments, one of my beliefs is that difficulty is real the way air is real. It’s completely true that programming and management are both hard, and they have this quality independently of my experience level. (This difficulty probably arises from inherent complexities in the set of problems that digital technologies are mainly directed toward solving, and the relative newness of all our tools.) I became aware of this belief by working with others - before working on big teams of people and watching others go through what I struggled with as a younger developer, I couldn’t confirm the reality of my difficulty. Validating and understanding this belief empowers me to observe it in other people and work to provide that confirmation to my teams early and often - you’re not crazy, git is hard.
A belief I could probably espouse more often is that the disagreeable feeling of difficulty is not evidence of wrongdoing in the world, it’s evidence of the application of energy. When a project is confusing, burdened by conflict, or stalled because of dependencies - it’s unnecessary to attribute those things to some hidden foolishness even though they bum me out. Those things happen when human beings apply energy to things. They’re ugly and stressful, but to say they’re ‘wrong’ is missing the point.
These beliefs only form and change over a long period of time and aren’t greatly affected by a single success, a single failure, or a single act of support from a colleague. I don’t know how exactly experience compounds itself into belief, but carefully observing that process over a long period of time is something I highly recommend. If you can be a scholar of your own baseline responses to difficulty, you can ultimately graduate into scholarship of others’ difficulties and responses, and that’s an essential aptitude for a team lead to deliver. This study is not coupled to a management style or a technology, and it’s an example of something we cultivate in our company culture to the benefit of all our partners.