Culture clash

 Culture is management’s boogeyman—a monster that can’t be controlled, an immoveable object that can’t be overcome. If you ever want to see managers become whiny, petulant infants, ask them to challenge an issue ingrained in the corporate culture.

When managers say, “That’s a cultural issue,” they mean, “There’s nothing I can do about it.” When managers say, “You’d have to change the culture,” they mean, “I’m wimping out on this issue.” Culture is a manager’s favorite excuse to maintain the status quo and avoid confronting change. That is not only lame—it is naïve and indefensible.

Culture as concept seems interwoven into the very fabric of our lives. What hope would anyone have to change such a thing? Yet corporate culture doesn’t arise in a vacuum. It is instilled by the people who founded the company and changes gradually as the people change. Therefore, you can affect culture, and it can change. You simply need to know how to do it, and stop being a wimp.

You see the whole culture

Countless books, articles, blogs, and commentaries discuss what drives and sustains culture. It basically comes down to expectations, modeling, and rewards.

Your parents, peers, neighbors, and friends expect you to behave a certain way. They model it for you. They correct or shun you when you fail to comply. They applaud and encourage you when you set the “right” example. This is how culture perpetuates itself.

Can you change culture? Sure—simply expect, model, and reward different behavior. Really, it’s that easy.

Ever notice how the culture of a group or organization changes when the leader changes? That’s what’s happening—the new leader expects, models, and rewards different behavior.

Eric Aside

The behaviors a new leader expects, models, and rewards aren’t necessarily the ones the leader intends. The leader may say one thing, but actually expect, model, and reward another. The old saying, “Do as I say, not as I do” is pretty ineffective at driving cultural change.

Back off, man. I’m a scientist.

Is there a science to driving behavioral change in organizations? Of course there is—it’s called Human Performance Technology (HPT). You’d think every manager would know about it, but few do.  Maybe they prefer whining and impotence.

The basis of HPT is B.F. Skinner’s model of operant conditioning. Basically, this model says that voluntary behavior breaks down into stimulus, response, and reinforcement. You receive a stimulus, like your manager telling you to start coding. You respond by coding. You receive reinforcement, like pizza.

Thomas Gilbert analyzed the types of stimulus, response, and reinforcement in his book on Human Competence, differentiating between the environment and the person.

• The environment refers to workplace influences, like expectations which stimulate a response (such as instructions and metrics), tools and processes that shape the response (such as build systems), and incentives that reinforce the response (such as bonuses and recognition).
• The person refers to individual influences, like knowledge to interpret a stimulus, capacity to respond, and motivation to receive the incentives. (If you’re not hungry, pizza isn’t an incentive. Hunger is the motivation.)

To drive behavioral change, you need to consider and potentially shift the environmental and individual elements of stimulus, response, and reinforcement, known as the “Six Boxes.”

	Stimulus	Response	Reinforcement
Environment	Expectations	Tools & Process	Incentives
Individual	Knowledge	Capacity	Motivation

Eric Aside

The concept of putting Gilbert’s six areas into plain language as “Six Boxes” comes from Carl Binder.

Environment

Expectations:  Suppose you want your software development team to focus more on unit testing, perhaps even adopt Test-driven development (TDD). From the environment side, you need to ensure that writing unit tests is expected by management and the team. It would be helpful to have metrics that indicate how much of the code has unit tests in place. However, that’s not enough.

Tools & Process:  The team will need to have a good unit testing framework in place—one that is easy to run, easy for developers to add tests to, and easy to use for measuring results. Of course, that’s not enough.

Incentives:  If group managers reward developers for checking in code quickly, with or without unit tests, developers will stop writing the unit tests. To drive unit testing, only developers who write thorough unit tests should be chosen for recognition and rewards. But that’s not enough.

Eric Aside

Which reward works best? Typically, it’s not salary. Salary can actually demotivate when people aren’t paid fairly. Also, recent studies show that salary doesn’t align well with what people truly desire when doing difficult work—autonomy, mastery, and purpose (check out Dan Pink’s talk on the subject).

Instead of more money, offer more responsibility and opportunity to improve, and tie people’s work to outcomes that matter. These rewards better target engineers’ motivations and also naturally lead to raises and promotions.

Individual

Knowledge:  Developers will need to know what the different kinds of unit tests are and how to write them well. They will need to know how to use the unit testing framework, how to get metrics on their progress, and what targets they are expected to reach. Now, we’re almost there.

Capacity:  Naturally, the developers will need to be capable of writing unit tests. Hopefully, in this particular case that’s not a problem. However, you might also expect your test team to unit test its automation. If your test team is using an automation tool, the team members may not be capable of scripting it or writing external code to test it. You might need to hire testers who have that capacity.

Motivation:  Finally, your developers need to care about meeting these new expectations and receiving the recognition and rewards you offer. If your developers are completely apathetic or entrenched, they won’t be motivated sufficiently to make the change.

Is it deliberate?

I’ve outlined a whole bunch of system thinking for a simple cultural change. You might say that’s overkill. However, look back. If any one of the six boxes isn’t properly addressed, the change won’t happen properly, if at all. “I know—we’ll just train everyone” isn’t enough.

The environment impacts everyone and thus is more potent than any individual. No amount of training will overcome the wrong expectations, tools, and incentives. However, clueless, incapable, and apathetic engineers are also quite debilitating.

Review all six boxes. In the unit testing example, you’ll see we need clear manager expectations, metrics, targets for those metrics, a unit testing framework, a change to rewards and recognition agreed upon by all the group managers, training for the team, and the right team members in place—both from a capacity and motivation perspective.

How do you think all that through in advance? Easy—know where you are today, know what you want to accomplish, and then go through the six boxes with that gap in mind.

You must avoid jumping to the first sexy solution (“I know—we’ll use that new tool!”). You must be deliberate about your goals. You must also be deliberate about measuring progress toward achieving your goals, not just making pretty charts.

As I covered in How do you measure yourself?, measuring lots of values and putting them on graphs achieves little. The numbers don’t have meaning and the metrics will be gamed. You must know what you want to accomplish and deliberately measure your desired end results.

I’m going to ask you a few questions

HPT also provides a clear framework for performance improvement in general. Before proposing a solution, HPT requires that you understand the problem, the desired result, and how to measure success. The next time someone runs into your office suggesting that the team adopt a new estimation method, patiently hear him out and then ask him a few questions.

• What are you trying to accomplish?
• How is it done today?
• How will you know when you’ve accomplished your goal?
• What should managers say and do to support this direction?
• What processes and tools will the team need?
• How will managers need to recognize effort and progress differently?
• How will the team learn about the new direction, tools, metrics, and targets?
• Are the right people in the right roles to accomplish your goal?
• Does the team care at all about this?

All together now

Remember, if you are serious about doing things differently, then you are working on changing the culture. This applies to big changes, like moving to a services model, and little changes, like using code review checklists. Of course, big changes take longer than small ones, which is why goals, metrics, and targets are so important.

Changing the culture is possible and even algorithmic. When you ask the right questions, focus on the result, and consider all six elements that drive behavior, you can move molehills as well as mountains.