A lot of companies do this grave mistake of hasty technology onboarding without proper milestones and training in place. This catapults the growth of tech debts and unsurprisingly enough we witness the engineering leadership the blame the Product and the Business for this situation as they had set-up unrealistic deadline for engineering. While there sure is truth in that without doubt, the pressure varies greatly depending on the maturity of the company (the room for conversation is usually much more mature and organized in enterprise companies than startups). But irrespective of the size and nature of the company, I tend to pick the unchartered path of working my way through to come up with communication techniques that helps alignment across board by building trust and transparency. In this blog post, I share my technique of having a Containerization Maturity Matrix (CMM) for my teams in their journey of modernizing their platform to Kubernetes.
CMM is about knowing where every team member stands in the utilization of the tech-ware to be adopted at the most granular level. Every team/pod can have this matrix to aid tracking things at pod level. The desired picture of how this matrix should look like is communicated to all teams and then it becomes much more easier to track and have conversations with the respective Engineering Managers or team members to reach the desired end goal. With every team reaching the desired end state, as an Engineering Leader you can then celebrate and move on to pick the next burning problem to solve.
I have employed this even in situations where when I walked in, Kubernetes is there in production environment but not in QA and/or Dev environments. Having a matrix like this helps to ensure that the technology adoption is not at surface level but has penetrated to the extent that the team has an appreciation for it.
Below are some of the key reasons for having it in place:
- It brings in transparency and thus boosts trust across board from a new developer joining the team to the non-tech executive leadership that gets a hang of engineering intensity.
- For team members it serves as a motivation for self-organization. Remember that Agile teams are self-organizing. It is the duty of engineering leadership to unlock team's agility by bringing in measurable metrics like this that matter.
- Where we don't get to see the right check marks, it is easy for an engineering leader to participate and understand the blockers. This is typical me at least and I further sit with the team in problem solving, should they need my help.
- It is a mini-map of sorts with milestones to achieve for complete adoption of Kubernetes.
- In my opinion, this is structured approach to problem solving that aids engineering management even in a chaotic environment; I have put this to use very many times in the past years in companies of different sizes.