I remember an unpleasant situation I witnessed a few years back at my day job. There was a technical lead on a project adjacent to mine and for one reason or another, his project manager decided to give his role (the tech lead role) to another team member.

The manager discussed this decision with the tech lead first, the lead seemingly had no objections, and so the manager announced the decision to everyone.

That’s when some Game of Thrones-level intrigues had begun.

The former tech lead started to actively sabotage the transitioning process and slander the new lead. He was trying to get support from people outside their team, by showing how bad technical decisions of the new lead were. He even went to the higher ups saying that the project manager treated him unfairly by taking the role away from him.

How do I know all this? I was that "support from the outside of their team" he tried to recruit.

Now. I don’t want this to sound one-sided. The former lead had some fair criticisms with regards to the technical decisions. My point is — he should have discussed these criticisms with the new lead and the project manager first (which he didn’t). And, more importantly, he should have raised his objections at the very beginning, before agreeing to the transition, which he didn’t do either.

No one likes such behavior.

Again, the problem isn’t the criticisms or disagreement per se, it’s how they are being surfaced. If you don’t like something — say it directly to the person whose ideas you don’t like, and do that as soon as possible. If you voiced your disagreement and the decision is made nonetheless, execute that decision as if it was your own. Sabotage is the least helpful thing in this situation, especially in the long run.

Interestingly enough, there some parallels you could make with code behavior, there’s even a principle in software development that addresses this problem.

This principle is called Fail Fast. In my Unit Testing book, I described it as a good alternative to integration testing.

The main idea is that if you call a method, this method should either:

The last thing you want a method to do is take on a request, execute it half-way through and then call it a day. It should either execute it in full or notify the caller that it’s impossible to do so.

Compare this to the situation with the former lead. He should have "failed fast" by clearly stating his disagreement with the decision. What he did instead is he "failed silently" and then caused a lot more problems down the road.

There’s another principle called Design by Contract that elaborates on the Fail Fast principle further and formalizes two parts where a method can (and should) fail:

It may look counterintuitive, but failing fast increases code stability in the long run. When your code stops executing in light of any issue, you can rest assured that as long as such code is still running, it most likely does its job correctly.

The same is true of people. If you always raise your objections early, your colleagues may not like it at first, but as the time goes, they will gain trust in your judgment. A person who voices their concerns politely, but firmly is of great value to any team.

A real-life example of a postcondition would be taking on a task with a particular deadline, and raising alarms as soon as you realize this deadline can’t be possibly met. Dragging on with the task and hoping for the problem to disappear on its own is never a good strategy.