Hey managers – this is why we don’t believe you when you say that you “care about quality”

Let’s start this with a short exercise:
Think of all the places you’ve worked at, where you heard “we care about code quality”, “we’re willing to invest the time to achieve high quality”, “we want to tackle tech debt”, or similar.

Now think of all the places you’ve worked at where you’ve felt like people actually cared about code quality, tech debt etc.
What’s the relationship between these two groups?

Naively, we may guess that they are the exact same group.
In practice, for me, the first group consists of 4-5 workplaces, and the second one of 1 workplace.
I think that this is a pretty representative result.

This begs the question: Why is it that we hear from our CTOs, directors, CEOs about their “commitment” to quality, but we so rarely see the results?
Are they all liars?

In my experience, no. I believe these people when they say that they do want that rainbows and unicorns utopia.
I also think that they don’t understand how to change the culture of their organization.
Let me explain:

What is culture, anyway?

Culture is how an organization behaves. It’s “how we do things ’round here”.
Some examples are:

• “we pair program”.
• “we don’t write automated tests”.
• “we don’t deploy on a Friday”.
• “we work overtime to meet deadlines”.
• “developers only do the coding; after that, it’s ops’s responsibility”.

The majority of these “rules” aren’t written anywhere. But still everyone knows them.

Equally as important, is what culture is not.
Culture is not what is printed on posters, press releases, or talked about at company all-hands.
For example, a company says it “enjoys a reputation for fairness and honesty”. In reality, it committed one of the biggest frauds in history.
Or, a company who’s motto is was “don’t be evil” turns out to do some.. pretty evil things.

From the above, it’s clear to see where our well-intentioned managers are going wrong. They’re trying to change how we do things (== culture) by talking.
But that’s precisely what culture is not. it’s what we do, not what we say.

How does culture get set?

If culture is not set by what the top brass say, then how is it determined?
there are a few elements that impact culture:

1. Incentives

Meaning: which types of behaviours get rewarded, and which get “punished” (or received negatively).
This also includes priorities – what are employees incentivised to prioritise?
Some examples:

• At Enron, management said that they’re committed to a high ethical standard. But employees who stepped on their customers, colleagues, and ethics, were hailed as “top earners”.
• To the contrary, employees who did not “play dirty” were disciplined for not generating enough profits.

This behaviour taught employees what’s the expected way to do business.

• At a software company, a CTO declares that they want to invest in automated testing.
• However, they don’t prioritise a project for building a testing framework for their product. They don’t push back deadlines to allow testing activities.
• When Pull requests with untested code were merged, the CTO did not comment on it.
• When a project was running late, the CTO called for a meeting to discuss the situation.

This behaviour showed the developers what’s the importance of testing.

2. Established practice

“That’s how we do it because that’s the way we’ve always done it”.
When we enter a new organization, we tend to follow the lead of the more tenured folk.
We do things in the same way that they do it. This is especially true for more junior employees, who may not have previous experience to compare against.

This is illustrated by the monkeys’ parable:

4 monkeys in a room. In the center of the room is a tall pole with a bunch of bananas suspended from the top.
One of the four monkeys scampers up the pole and grabs the bananas. Just as he does, he is hit with a torrent of cold water from an overhead shower. He runs like hell back down the pole without the bananas.
Eventually, the other three try it with the same outcome. Finally, they just sit and don’t even try again. To hell with the damn bananas.
But then, they remove one of the four monkeys and replace him with a new one. The new monkey enters the room, spots the bananas and decides to go for it. Just as he is about to scamper up the pole, the other three reach out and drag him back down. After a while, he gets the message. There is something wrong, bad or evil that happens if you go after those bananas.
So, they kept replacing an existing monkey with a new one and each time, none of the new monkeys ever made it to the top. They each got the same message. Don’t climb that pole.
None of them knew exactly why they shouldn’t climb the pole, they just knew not to. They all respected the well established precedent. EVEN AFTER THE SHOWER WAS REMOVED!

(source: Competing for the future by Gary Hamel and C. K. Prahalad (1996))

Some human examples:

• “At my previous company, we wrote a test for every method. But here, we don’t write tests”.
• “Every morning, we give a status update to ourselves. We don’t know what purpose it serves”.
• “Every two weeks, we try to guess how much work we can do in the next two weeks.”

3. Ability

It may seem obvious, but employees can’t do things that they don’t know how to do, or maybe don’t even know about.
For example:

• A team can’t engage in continuous integration if they don’t know what that is.
• A developer can’t practice TDD if they weren’t trained in it.
• It’s hard to refactor when you don’t know the common code smells, and their fixes.

You may notice that these three factors are not isolated from each other. Each one influences the others. For example –

• Incentives lead to certain behaviours. These behaviours become established practice, even if the incentives are removed.
  (as seen in the monkeys’ parable – the (dis)incentive of the shower was removed, but the established practice remained)
• Our ability determines what practices we can, or can’t, establish.
• Inversely – even if we have the ability to do something, it may decay and deteriorate if it’s not the established practice. (for example – we become worse at TDD due to lack of practice).
• We may provide incentives that encourage employees to gain certain abilities. For example – provide free training.

In practice

Going back to my own experience – All those companies who talked about quality, but churned out bugs:
Can these situations be explained by the above theory? Let’s see.

1. Incentives

• When a feature was running late, developers faced questions and pressure.
• Testing or refactoring activities were cut to meet deadlines.
• Even when a “technical excellence” initiative was announced, teams were expected to deliver the same amount of features as they have done before.
• Developers who hurriedly fixed production bugs in a hacky way were praised for their quick problem fixing.

On the other hand –

• When a production bug occurred, the developer who caused it did not face any questions or pressure to learn from that experience, and make sure it doesn’t happen again.
• Teams who prioritised “technical excellence” activities faced pushback from “the business”, for “delaying features”.
• Developers who took time to write automated tests, or to improve code structure, were, at best, tolerated. But not praised.

2. Established practice

Many organizations I worked for adapted to the incentives described above. The resulting practices became the norm, never to be questioned:

• We don’t have time to write automated tests.
  (Corollary – we have no problem approving untested code to go into production)
• We don’t have time to refactor.
  (Corollary – we have no problem approving spaghetti code to go into production)
• We need a week of manual testing before releasing a new version.
• After every release, we release a series of patches, to fix bugs in production.
• We routinely work evenings and weekends to fix urgent bugs.

There have been several cases where I tried to challenge those established practices. I proposed writing automated tests, working in smaller batch sizes, and more.
In some cases I encountered skepticism, or even outright hostility.
Even when the reaction to my ideas has been positive, a change in behaviour didn’t necessarily follow:
“You do it like this, which is better. But I’m used to working like that“.
Old habits die hard.

3. Ability

I rarely worked with colleagues who practised TDD (or any form of automated testing), refactoring, etc. Even senior members of the team.
Hell, I’ve been a senior member of the team who didn’t practise TDD and refactoring.
Many of my colleagues were willing to try these things, but didn’t know where to start.

Some more examples –

• At a previous job, the organization was willing to prioritise automated testing. I was asked to lead a project to create an automated tests suite for the product.
  However, I had virtually no experience with automated tests, and ended up doing a pretty crappy job of it.
• Only a single organization I’ve ever worked for offered any training on automated testing or refactoring.

Conclusion

There are several interconnected factors that determine how an organization functions.
Counter to intuition, these are not related to what managers are saying. They’re related to what managers are doing – what behaviour they praise, what behaviour they raise questions and concerns over, what skills they teach, etc.
We respond to these factors, even as most of us aren’t consciously aware of them.

For employees, being unaware of these factors is no big deal.
For managers who try to affect change to their organization, this can make or break a “digital transformation” project.