What is a keystone habit
According to The Power of Habit author Charles Duhigg, when there is a habit change, it can set off a chain reaction that has the ability to change your self-image.
It sounds simple, powerful, and appealing, so I wanted to try it out for my team.
The quality problem
At the time, we had lots of conversations around the quality of our product.
We released every other week, and every time we released a new version, we found ourselves staying late to fix bugs and spending the first week just worrying about the following incident.
We quickly got overwhelmed with all the places we could begin enhancing and would get stuck in endless debates about value, effort, and priority against other work.
When we least expected it, the next release was already here, and we had not made any progress on making our situation any better.
Trying out a keystone habit
When it came to us, we needed to start somewhere that we all agreed on, was easy to get started, and that would unlock many other enhancements along the way.
We chose to get good at automated testing.
In theory, our quality would improve, our confidence in deployment would increase, and we all agreed that automated testing had a low barrier of entry for all teams involved.
Results
It was surprisingly better than we expected. Here are a few items we unlocked.
Confidence in deployment — with increased automated tests, we stopped fearing deployments so much since we knew the code was under test.
Surfacing regressions quickly — since the tests run on every pull request, we quickly knew when regressions were introduced.
Lower reliance on QA teams — before our automated test suite, QA felt overwhelmed trying to test everything before every release.
After automated tests, QA could guide engineers on good testing practices and validate core use cases.
Maintainable code — to our surprise, automating unit tests drove us to write code in smaller, easy-to-test functions, with the resulting code being easier to understand, maintain, and enhance.
Enhanced product understanding — another side effect was the desire to understand better the different ways our code implementation could work, driving more conversations with our product counterparts to dig deeper around possible edge cases, business validations, and other business domain-specific items not initially apparent from the initial work descriptions.
What keystone habits will you introduce to your teams?
