Responsibility and Natural Consequences

In the previous article, I touched on the responsibility concern of NVC (Nonviolent Communication). If we don’t blame people for their mistakes, don’t we risk losing control over results? Don’t we affect accountability? We aim to promote mature responsibility — but what should we do if that approach doesn’t work? I want to expand this topic with a practical solution.

Let me ask this sharply: 

How do we deal with abusive behavior?

“We need clearer commit messages to provide visibility for the whole team,” the product manager said.

“Oh, this is a nice idea,” Shmuel answered, while continuing to write commit messages like “fix,” “fix2,” “final fix,” and “one more attempt.” He knows he won’t be blamed or punished, so he changes nothing.

Some people may indeed misunderstand or misuse a nonviolent environment as a license to avoid responsibility. However, NVC doesn’t mean letting go of boundaries, expectations, or consequences. It means we communicate with honesty and empathy – while still addressing the impact of actions and making clear requests for change.

Apply your boundaries with the “Natural Consequences” principle

The Natural Consequences principle teaches that punishment is ineffective when disconnected from the behavior. We aim to express the cause-and-effect relationship clearly.

The classic example is a person who wakes up late. They miss the free parking spot near the office; they also arrive after the morning standup where the team finalized the Secret Santa pairings, so no one was assigned to them. It’s not a punishment; it’s simply the natural result of showing up late.

It works well in children’s education. When a child refuses to tidy up their toys after playtime, saying “If you don’t clean, you won’t get candy” is a punishment; the consequence is not naturally related to the action. However, saying “We won’t have space to play the next game unless this one is cleaned up first” is just an explanation of what happens.

We aim to promote internal motivation rather than fear of punishment.

This also works well in software development — when a developer pushes a feature to production without a peer review, a critical bug slips through, affecting users. They now have to spend their evening rolling back the deployment and fixing the issue. No punishment; the system and process itself enforced the consequence.

However, we are talking about responsibility; we can’t allow situations like this, and we have to enforce code reviews. How to do this naturally?

Proxying Natural Consequences

When we can’t allow the natural effect because it’s too disruptive, the Natural Consequences principle prompts us to proxy the result. Let’s see an example of how it works:

A child doesn’t want to brush their teeth. If we stick to the natural effect, this will result in cavities and a rotten tooth, accompanied by pain. This works excellently, but we can’t allow this — when we get there, it’s too late and too disruptive. If we say, “If you don’t brush your teeth, you won’t get your pocket money,” it may work but it is rooted in punishment and fear. We don’t want that. Instead, we simulate the impact: “If your teeth aren’t clean, you won’t get chocolate.” It’s a proxy for the natural result, adapted for a child’s immediate understanding: this happens to one who misuses their mouth.

Now, let’s apply it to software development.

Although these examples come from parenting, the underlying principle — that people learn best from clear, real consequences — applies equally in professional environments.

Remember our Shmuel, who writes vague or cryptic commit messages like “fix” and “stuff”?

Months later, during a critical bug investigation, no one could figure out where and why a change was made. Teammates waste time trying to understand the context. And that’s without even mentioning the struggles during rebases or cherry-picks.

This is the true consequence, which works perfectly but which we cannot allow — it might cost weeks, usually under pressure.

To encourage Shmuel to improve, we can startle him:

• “If you don’t write better commits, you’re off the project.”
• “You won’t get your quarterly bonus.” 

Well, this might work… somehow.

Now, let’s talk to Shmuel by simulating the natural consequence:

• “Commits without clear messages won’t be merged.”
  • We don’t punish; we express the need for maintainable history and a codebase that matches our standards.
• “During post-mortems, you’ll be the one who has to walk the team through your commits.”
  • We turn a passive habit into an active learning moment. Again, no punishment — just exposure that bad commit messages are useless under pressure.
• “We generate changelogs from commits; if yours are unclear, they won’t be properly represented in release notes.”
  • The developer now sees their messages as the interface to the outside world; we also appeal to their ego.

Not everything can be forgiven

We aim to improve communication and reach results together; however, this doesn’t mean we are weak and concede to everything.

Boundaries protect the entire team, not just discipline individual behavior.

If nothing helps and the employee continues with disruptive actions like bypassing security policies or making unapproved releases, they may find themselves outside of the project and even outside of the company. Ending cooperation isn’t a form of punishment — it’s a recognition that mutual trust is essential for teamwork. Without trust, collaboration breaks down.