habits quality

Keystone habits in action

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.


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?

Life icons created by Flat Icons – Flaticon

quality stories support

Customer service – learnings from airline experience

Today I had to deal with customer service for a major airline, and it was such a negative experience that I feel compelled to write about it.

If your product offers customer service, there are some suitable lessons here.


Our problem was the interpretation of essential guidance by the CDC needed to travel into the USA. 

We had the latest guidance, but the airline operator didn’t, so we lost our flight.

  • Now think about software for a minute. If you are on a team that subscribes to continuous delivery, how is your support team made aware of new changes?
  • How often is the documentation that users and support rely on updated?
  • When you have conflicting information, do you train your support team to re-validate their assumptions?

In our case, the airline didn’t propagate regulation fast enough.

They didn’t train for edge cases and trained their staff to go with their assumptions rather than empowering them to verify the information.

The result was abismal customer experience and various unhappy flyers with lost flights complaining about an easily avoidable situation.


Our situation didn’t fit the usual support request that most users deal with, so we contacted the airline via phone to speak to a representative.

Here, we ran into an automated phone system that didn’t offer any of the options we were looking for, so we got routed to use WhatsApp.

Thinking I was going to chat with a representative, I got on WhatsApp, and to my surprise, I got another bot 🤖.

This bot didn’t provide an option to reach a representative.

I went on social media, and they routed me to a form, and guess where the form sent me? Another automation.

Automation in customer service is excellent for well-defined problems, but human interaction is required for edge cases.

  • When automating customer service, do you offer the option to speak to a human?

In our case, the automation didn’t help. 

The routing from one automated system to another made the experience worst.

In the end, the support experience just added to our grievances and set a bad reputation for the airline.

Thinking back to how this relates to software and the lesson is clear, Don’t let your support process mess up your reputation instead of helping it.

Icons made by Freepik from www.flaticon.com

management quality

Software validation

Today I paid someone to clean my house.

Since I am on my own with the kids this week, I just went outside for a while and returned once the cleaning person told me they were ready. 

I paid them, they left, and I began checking their work. 

To my surprise, the laundry room and the half bath were not cleaned, the other areas were done halfway, and the house looked “ok.”

You can think of it as having performed user acceptance testing on the cleaning job that resulted in a negative experience.  

This made me realize that when we default to UAT as our primary form of testing, it sucks, and our reputation suffers.

Based on my experience, I will not hire them again, but I thought about how I would feel if they had performed other validations.

Could I have changed my outlook on the results?

If I had the time, I could have validated her work after every room, or maybe sections of a room.  

I could have given her a checklist and had her check the items on the list. 

Imagine the checklist as the test-first approach where you already know what success looks like, and then you implement the work to make sure that success happens and your tests pass. 

A room check could be seen as an integration test, where I would ensure that all areas looked well together and not just individually.

The above tests could have quickly surfaced the missing areas and the places that needed an extra pass.

So when UAT happened, I would have seen more minor problems easier to digest, and I probably would now hold them to a high standard of quality and customer service.

In summary, test changes early, test often, mix your test types to include unit, functional, and QA. Have other people check your work and do all of this before it lands on your users.

You could be saving your company’s reputation.

Icons made by Freepik from www.flaticon.com