You've said it in the sprint planning. You've said it in the 1:1. You've put it in the team wiki. And yet — the same thing keeps happening.
PRs without ticket references. Deployments without checklists. Steps skipped "just this once" because there was deadline pressure.
Sound familiar?
This isn't a knowledge problem. Your team knows the rule. This is a behavior problem. And behavior problems require a completely different approach than just explaining things better or louder.
The Three Levels Most Managers Go Through
Most engineering managers — especially in fast-moving startups — tend to escalate through the same pattern when trying to enforce team discipline:
Level 1 — Verbal instruction: You explain the rule, why it exists, what benefit it brings. You do this in team meetings, in Slack, maybe even in a nicely formatted Confluence page.
Level 2 — Micromanagement: When level 1 doesn't stick, you start observing more closely. You remind people in code reviews. You bring it up again in standups. You personally check that things are done.
Level 3 — System enforcement: You build the guardrail. The pipeline rejects PRs without Jira codes. The checklist is a required form. The system blocks the wrong behavior automatically.
Most managers spend too long in Level 2, burning themselves out, before getting to Level 3. And the worst part? Level 2 only works while you're watching.
Why Explaining Isn't Enough
Here's the uncomfortable truth: your team isn't ignoring you because they don't understand. They're ignoring you because the cost of non-compliance is zero until you enforce it.
Human brains are efficiency machines. We take the path of least resistance. If skipping the Jira code on a PR takes 5 seconds and saves mental overhead during a deadline crunch — and nothing happens — the brain logs that as: acceptable shortcut.
Your explanation created awareness. It did not create consequences. And without consequences, awareness alone fades fast.
There's also a cultural layer to this, particularly in startup environments. Teams that have been through multiple managers, multiple "initiatives of the month," learn something: instructions eventually fade. So they wait to see if this one is real. They're not being malicious. They're being rational based on past experience.
The WIIFM Problem
One of the biggest mistakes in process enforcement is framing everything around what benefits the manager or the organization.
"We need Jira codes so I can track velocity."
"We need this checklist so the audit is clean."
"We need this because compliance requires it."
Your team hears: this is overhead that helps the boss, not me.
WIIFM — What's In It For Me — is the real question every engineer is silently asking. Until you answer it from their perspective, you're asking people to add friction to their day for someone else's benefit.
Some reframes that actually land:
- Jira code on a PR = your work gets credited. If you use any engineering metrics tooling, unlinked PRs are invisible contributions. Their output disappears from the data.
- Linked PRs = faster code reviews. Reviewers understand context immediately. Fewer back-and-forth questions. Less time blocked waiting for review.
- Audit trail = protection during incidents. When something breaks in production, the person with clean, linked commit history is the one who can clearly show what they were working on and what was in scope.
But here's the thing — even if you nail the WIIFM framing, it still might not be enough. Because WIIFM changes motivation. It doesn't change habits. And habits need systems.
Six Behavior Frameworks That Actually Explain What's Happening
After going through this cycle enough times, it's worth understanding the underlying mechanics. These frameworks explain why teams behave the way they do — and more importantly, what to do about it.
1. BJ Fogg's Behavior Model
Fogg's model says behavior only happens when three things converge at the same moment: Motivation + Ability + Prompt.
Most managers nail motivation (explaining why) but completely miss the prompt. You explain the Jira code rule in a Monday meeting. Three days later, an engineer is pushing a hotfix at 11pm under deadline pressure. The motivation has faded. The prompt isn't there. The behavior doesn't happen.
What to do: Put the prompt at the exact moment the behavior needs to occur. A PR template with a mandatory Jira field triggers at the right moment — when the PR is being opened, not three days earlier in a meeting.
2. Nudge Theory
From Thaler and Sunstein: you don't need to force behavior if you design the environment so the desired behavior is the default.
Most process enforcement is designed as a wall — do the wrong thing and something blocks you. But walls require constant maintenance and create resentment. Nudges work differently — they make the right behavior the easiest behavior.
What to do: A PR template that pre-fills the Jira ticket field with a placeholder makes filling it in take 5 seconds. Leaving it blank takes more effort. You've flipped the friction. The wall (pipeline rejection) is the backup, not the primary mechanism.
3. The Consequences Model
This one is simple but often ignored: behavior that has no immediate consequence doesn't change.
The consequence needs to be three things: immediate, consistent, and certain. Not severe — just unavoidable.
A verbal reminder in a 1:1 next week is a delayed, inconsistent consequence. A pipeline that rejects a PR right now, in front of the team, before they can move on, is an immediate and certain consequence. The immediacy is what makes it register.
What to do: Automate the consequence. Don't rely on yourself to catch it and bring it up later. The system should be the one saying no — not you.
4. Renting vs. Owning Behavior
This is the most important distinction for busy engineering managers.
When you are the enforcement mechanism, you're renting behavior. The team complies because you're watching. The moment you're heads-down on a hiring cycle, or in back-to-back stakeholder meetings, or on leave — behavior reverts. You were the rule, not the system.
Owned behavior means the team follows the rule when you're not there. You don't get that from verbal instructions. You get it from consistent system enforcement over time, until the system becomes the authority — not the manager.
What to do: Ask yourself: "Would this process survive a 2-week vacation without me?" If the answer is no, you have rented behavior. Build the system.
5. Edmondson's Peer Compliance Effect
Amy Edmondson's research on team dynamics shows something important: people calibrate their behavior to what they observe their peers doing — especially influential peers — not just what leaders say.
If your most senior or most respected engineer submits a PR without a Jira code and it gets merged (even once, even with good reason), every other engineer reads that as the real rule. Senior engineers can skip this under pressure. And now everyone starts finding their own version of "pressure."
What to do: Make enforcement hierarchy-blind. The pipeline should reject a senior engineer's PR the same way it rejects a junior's. Impersonal, automated enforcement removes the social dynamics from the equation. It's not about punishing the senior — it's about making the rule real for everyone equally.
6. Rule Erosion
Here's the one that managers cause themselves without realizing it.
Every exception you allow — even with a completely valid reason — sends a signal: this rule has conditions. Your team doesn't hear "the rule still applies, this was just an emergency." They hear: "I just need to find the right condition."
Over time, the rule erodes. Not because anyone is being defiant, but because you've taught them the rule is negotiable.
What to do: Separate the exception from the rule. A production incident happens and a hotfix needs to be merged fast — fine. But require a follow-up: the Jira link must be added within 24 hours, or a retroactive ticket created. The rule still applies. The timing is flexible. This closes the exit without blocking production, and preserves the integrity of the rule.
The Decision Framework: Which Tool For Which Problem
Not every situation calls for the same response. Here's a simple way to map your problem to the right framework:
| Your Problem | Start With |
|---|---|
| Team forgets the rule at execution time | Fogg Behavior Model + Nudge Theory |
| Team knows but doesn't bother | Consequences Model + Rule Erosion |
| Behavior improves when you're around, regresses when you're not | Renting vs Owning + Consequences Model |
| A senior engineer is setting the wrong example | Edmondson Peer Compliance |
In most real situations, you need Nudge + Consequences + Rule Erosion running together. The others help you diagnose what's really happening.
The Hardest Part: Protecting the System From Yourself
You can build a perfect pipeline. You can design the right nudges. You can get buy-in from the team.
And then you override the system once, with a good reason, under pressure.
That one override costs more than you think. The team noticed. And they'll use it as a reference point the next time they need an exception.
The real skill isn't building the enforcement system. It's having the discipline to protect it — including from your own judgment calls in the moment.
If you need exceptions to exist (and you will), formalize them. Make the exception process explicit and documented. "Hotfixes can merge without a Jira code IF a follow-up ticket is created within 24 hours" is a better rule than "no exceptions" that gets violated, because it's honest and it closes the gap.
The Bigger Picture
Process discipline in engineering teams isn't really about process. It's about trust and predictability.
When a team consistently does what they say they'll do — when the agreed process is actually followed — it creates a foundation where people can rely on each other, where metrics are trustworthy, and where quality compounds over time.
That foundation doesn't come from better explanations. It comes from systems that enforce the right behavior consistently, leaders who protect those systems, and enough time for the behavior to become habit.
The verbal instruction was never going to be enough. It was always going to end with a pipeline rejection. The question is just how long you spend in the middle before you get there.
Top comments (0)