I’ve joined WorkSafeBC DevOps department in February 2019 (almost three years ago). My mandate was to introduce and cultivate technical excellence by acting as the Software Development Practice Lead. In my mind, it reads as a sales job – try to sell the need for raising the bar on technical excellence. I knew it was going to be a challenging job. Fast forward to today, and looking back, I can gather some of my observations and impressions. How did the sales job go?
Some misconceptions about the resistance to technical excellence
Whenever I discuss the challenges of selling the need for technical excellence, I keep hearing incorrect opinions regarding why it is such an uphill battle. Basically, many people seem to think that the pushback is solely coming from the non-technical areas of the company. In my experience, nothing could be farther from the truth. During my tenure at WorkSafeBC (and in many of my previous jobs), executives, upper management, middle management, product owners, and Scrum Masters have always been in full support of introducing and cultivating technical excellence. I’ve never experienced anyone from those roles ever asking me to abandon my attempts to introduce and cultivate technical excellence.
Where is the resistance to technical excellence coming from?
Whenever we talk about introducing new principles, processes, and practices in support of cultivating heightened technical excellence, those new practices only affect teams who are creating and releasing software. It is not surprising that oftentimes the biggest push is coming from those departments.
Non-technical departments are never affected by the new practices dedicated to technical excellence; therefore, it doesn’t make much sense for those areas to push back on it. But because teams that are responsible for creating and releasing software are directly affected by the introduction of practices that pursue technical excellence, it is to be expected that they will raise all kinds of concerns.
What are some of those concerns?
Sticking to the winning strategy
There is a saying that if it ain’t broke, don’t fix it. Oftentimes we see teams that are delivering on a cadence and staying in the game. To some, that’s a good enough proof that there is no need to change the winning team. The fact that team members continue getting a paycheck and keep their position, to them means that insisting on introducing technical excellence is nothing but an academic exercise.
Change is perceived as a threat
Introducing change is often viewed as being potentially risky. There are always a few worrisome questions that people keep getting in the back of their head. Such as:
-
What if it turns out I cannot acquire the new skill as quickly as my peers?
-
What if I invest time in learning new skills but then there is a reorganization, so all that time ends up being a waste?
-
What if I agree to learn the new skill, but then I end up not having the time to do it?
How to fix the stalemate?
In my experience, the best way to make a breakthrough and avoid the above-described stalemate is to promote real time collaboration. The main advantage of real time collaboration is in the shifting of the focus from measuring and tracking individual team members performance, to focusing on the team performance as the smallest unit of measure. When the team is working together on preparing and delivering value, individual contributions meld into a more holistic way of working. That way, many of the above concerns simply melt away and disappear. Working together in real time is also the best opportunity for acquiring new knowledge and new skills. Simply by attending collaboration sessions, each team member upgrades their level of expertise, and it feels like fun doing so.
It is therefore highly recommended to provide the context and the conditions for full collaboration in real time. Doing that will enable teams to embrace and fully cultivate technical excellence without being concerned about any negative consequences.