When we want to change behavior, it’s tempting to “create an incentive.”
That new incentive then competes with every other incentive. The richer the environment, the more distractions there are.
Like, say the central Architecture team decrees a particular library the preferred choice for some string manipulation lots of us do. If there are eighteen different libraries that can do that thing, chances are good there’s another one I’m already familiar with, or one already included in my project, and it’s expedient to use one of those.
With increasing variety, each newly created incentive is weaker.
Yet disincentives get more powerful.
If you tell me not to use a particular library, because in the build I’m gonna get a bunch of audit warnings (maybe it’s not maintained anymore) — then I’m likely to use one of the other seventeen. I don’t want those warnings, and there are plenty of alternatives.
As our systems get richer, our options more abundant, our decisions more interesting: incentives get less useful, and disincentives more useful.
This explains why, when you want to change behavior, pushing for the what you want is less effective than removing obstacles.
If you want the team to deliver sooner, remove blockers. Give them the authority they need, and support them in gaining the knowledge. Help them get a pipeline in place so that deployment is easy. Help them get tests up so that it’s safe. Remove the fear, remove the pain, and existing motivation will do the rest.