Sustainable Growth and Tech. Debt
Any technology-driven organisation that has successfully grown over a long time, would have done so by a mix of visionary leadership, luck and rapidly developing solutions for real-world problems. They would have, along the way, made technical concessions in the solutions they devised. They would have pivoted from experiments and products brought to market. They would have made decisions without knowing what the future holds, decisions motivated by growth, speed or plain survival.
But, if they were successful, they will eventually reach or have reached a point where the organisation will need to focus on a different kind of speed, a different kind of agility. The motivations would now change to Quality, Stability, Security; all things which were never the primary focus in the long history of the organisation’s engineering culture.
In this dichotomy lies the conflict of an old but successful engineering team unable to fuel sustained growth with stability, stuck with the old culture and practice which seems out of place and ripe for disruption.
This might be a example of how teams get misaligned to the market over time. If you find yourself in such a team, you may wonder: What now? How can I bring Quality into focus?
Houston, we have a problem!
The first step towards any solution is to realize and diagnose that there is a problem. It is imperative that you spot the red flags in your organisation, that you see the obvious signs littered around the codebases, delayed features and piling bug reports. You may find yourself with the following symptoms:
- The quality of code is constantly deteriorating, even when engineers spot obvious issues, they can never find a “good” solution.
- There is constant talk of the “Ideal World Solution” but those solutions never see the light of day.
- Technical solutions are driven by deadlines rather than the best practice and the right design for the given problem.
- Even when there is work on greenfield projects and domains, quality and reliability does not improve.
- The product is constantly buggy, and a lot of unacceptable holes in features are accepted as status quo.
- People love to hack solutions together for faster delivery. There are meetings where engineers give two estimates, one to “do it right” and one with a “hacky but fast” solution.
If you have seen a majority of these in your team, you should pick up the phone and yell, “Houston! we have a problem!”.
Ground Rules
There is no silver bullet, but there are ways to cope, and drive change in a team which might seem tangled with the “old ways”. Let’s make a few assumptions here before we go on to solve anything:
- There are no bad actors — let us assume, we are dealing with people who want to excel; there is no obvious intent of disruption, misalignment with common goals.
- People are open to reason — people can be resistant to change, but as long as they are open to logical and sound reason, there is hope.
Lets Change!
Blaming engineering teams and individual developers’ lack of skill is an easy out for leaders. But we need to realize that the reason we are in this situation is in large part due to the incentives and culture developed over the years. Five years ago when the co-founders incentivized people to “hack together a solution overnight that works 70% of the time” they had very different priorities, they were driven by speed and survival. But the habits, practices and the culture they developed are still hanging around.
It is important to realize that the culture that took years to form, will take a gradual and firm approach to change, we need a strategy that tackles this problem on three fronts:
- Incentivise
- Learn
- Checks & Balances
Incentivise
Incentivising your engineers to deliver fast without regards to the quality may be the root cause of most of your problems, and as such the first steps towards a positive change, is to calibrate that incentive for your team.
Use public and formal forums to explicitly state and document that quality is important. Incentivise the champions of quality, and encourage the team to shift gears and change their habits. For example, career development plans and competency matrices should be realigned to reflect that the first and foremost priority for any engineering team is to deliver quality, reliable and secure code.
You need to make it evident that the organisation has gone through changes and the incentives have now shifted, the expectations from engineers are no longer what they are used to be. Give your team time to adjust but be firm with the incentives.
Learn
Learning is the only real way to form “better” habits. If old habits die hard, then we better get started with making new habits now!
Learning may come in many shapes and sizes. Your team can learn from peers, online resources, seminars and conferences, even take up formal courses at university. But irrespective of which form of learning you want your team to embark on, realise that all forms of learning take time. You need to make it as easy as possible for your team to learn, and remove any time pressures that might have worked against their desire to learn in the past.
We also need a “culture” of learning, where people can readily admit to making mistakes and are open to learning new things from their peers. One such mode of learning is to engage in honest and in-depth code reviews. There should be a lot of teachable moments during code reviews. People should come out of tedious and long code reviews thinking, “That was hard!, But, I learnt something today”.
Checks & Balances
I am sure that we all agree: trust is the pillar on which any organisation stands. But we still need Checks and Balances. Placing checks should not be seen as mistrust in capability rather as the guard rail that steer everyone to one aligned purpose.
Affecting any real change in quality is a hard thing, especially if you have legacy tech debt to deal with. It will need real measurement and conscious push towards things people may not be in the habit of doing. It is human tendency to do things that are easy, but a lot of times, when working with a lot of tech debt, doing the right thing may be counter-intuitive and hard. We need checks as a constant reminder that times have changed and we need to change with them.
Introducing a code coverage tool, code smell tests, minimum test coverage requirements, locking up horribly tangled legacy code to facilitate breaking the monolith, and stricter code reviews are all checks, which allow us to mould our team’s behaviour and monitor their progress over time.
Conclusion
A successful engineering team is a rare and valuable asset. Especially if that team has years of valuable knowledge, loyalty and drive to make your organisation better. Aligning and realigning teams may be a hard and time-consuming thing to do, but there is no substitute to it. On the bright side, this may be the change that catapults your organisation into the next phase of growth!
