The Intellectual Violence anti-pattern
You’re the CTO of a cool new tech startup, and you are sitting in on a sprint planning meeting. Paul (the team lead) is discussing the latest functionality from the backlog that needs to be built in the next sprint.
“So here’s where we will need a web front-end to edit our customer database”, Paul is saying. “We should go with Steve’s suggestion and code the whole thing in React.”
Steve, the senior developer on the team, nods his head. “That’s right, Paul. React is the way to go.”
Then Bob, the newest hire on the team, raises his hand. “Are we sure we want to go with React? I don’t have any experience with it, and I’ve heard that it’s really difficult to use. Shouldn’t we go with something easier like Angular 2?”
The entire team flinches, and Steve gives Bob a withering gaze.
“If you spent a little more time coding instead of playing games, you would have mastered React by now”, Steve says, cutting into Bob. “Frankly, this does not give me confidence in your abilities at all. You’re just as bad as the rest of this team. I guess I’ll have to code the whole thing myself, as always.”
The room is dead quiet for a second. Then Paul clears his throat and says: “okay, let’s continue with the next user story….”
Developers, right? But hey, IT is a meritocracy based on knowledge, so in the end, these things always sort themselves out. Weak developers leave the team, and the strong stay on. Right?
Actually, no. What you’ve just witnessed is a toxic anti-pattern called Intellectual Violence, and if you don’t deal with it quickly, it will wreck your project.
What are the symptoms?
When a patient walks into a hospital with a fever, aching joints, and a red skin rash, a good doctor will immediately recognize these symptoms and realize that a chickenpox infection is likely.
Being a tech leader is no different. Technical organizations can also get sick from afflictions like anti-patterns. Each pattern comes with its own unique list of symptoms. A good leader will recognize these symptoms, quickly identify the anti-pattern, and start working on a cure.
Here are all the symptoms from the meeting that point to Intellectual Violence:
Notice how the entire team defers to Steve, even the lead developer. Steve has successfully pushed the team to adopt React, his favorite technology. When Bob makes a legitimate comment that React is hard to learn for new developers, the team flinches because they know what’s coming: Steve savagely cuts him down with criticism and contempt.
These two communication patterns, together with defensiveness and stonewalling, are so toxic that coaches refer to them as ‘The Four Horsemen’ because they usually predict a coming apocalypse. Steve has now completely poisoned the mood and intimidated Bob to stay silent.
Steve continues with: “You’re just as bad as the rest of this team.” He is now attacking everybody in the room in an attempt to reassert his intellectual superiority. And notice Steve’s final words: “I guess I’ll have to code the whole thing myself, as always.” He is already coding all React by himself because he has no confidence in the capabilities of his colleagues.
This is a disaster waiting to happen. With Steve first pushing for React, then hoarding his knowledge and doing everything himself, he is effectively setting the pace of the entire team. No matter how many people you add to the team, the project will only progress at the pace Steve can handle.
The four root causes of Intellectual Violence
Let’s take a closer look at the root causes of Intellectual Violence.
The number-one cause of intellectual violence is insecurity. You may find this hard to believe, but Steve is actually very insecure about his knowledge of React. He probably knows very little about it at all, and he keeps his lack of knowledge carefully hidden by masking it with defensiveness and an air of superiority.
Steve is in a culture that allows toxic communication. It’s very common for intellectually violent people to use all four horsemen in their defensive behavior: criticism, contempt, defensiveness, and stonewalling. Steve used two of them, criticism and contempt, to shut Bob down before he can expose the true depth of Steve’s knowledge.
Steve can get away with his behavior because the company lacks a process for mentoring and coaching that would distribute the knowledge of React over the entire team. Without this process, Steve is free to hoard his knowledge and use it to assert his superiority over the team.
And finally, Paul displays poor team leadership by letting Steve get away with it. Allowing team members to intimidate and bully other team members is completely unacceptable, and Paul should have zero tolerance for that kind of behavior.
How to fix Intellectual Violence
To fix Intellectual Violence, you’ll need to educate your team on a couple of principles:
First of all, teach your team about the Four Horsemen: Criticism, Contempt, Defensiveness, and Stonewalling. These communication styles are extremely toxic and have no place in a modern organization. You should institute a zero-tolerance policy to ensure that everybody treats their co-workers with the respect they deserve.
Second, educate your team about the Darkness Principle, which states that the information needed for the project to move forward is distributed over the entire team. Individual team members don’t have the full picture – they’re ‘in the dark’, so to speak, with the other team members holding the missing pieces of the puzzle.
You can encourage the team to share information by instituting a couple of policies:
You should introduce a training program to ensure that the entire team has the knowledge they need. Don’t focus only on the senior developers, but make sure everybody in the team receives the same training. By spreading the knowledge of React over the entire team, you ensure that the project progresses at the speed of the full team, not just Steve.
And finally, encourage knowledge sharing by organizing presentations and coaching sessions. Give the right example by presenting something unique that only you know, and share it with the team. Then challenge everyone to follow your example.
In my first job at a software company in 1995, we had ‘Tech Fridays’ where one of us would get on a stage and present a cool topic to the rest of the company. It was a great way to avoid islands of knowledge popping up in the organization.
What will you do to fight against intellectual violence?
Would you like to know more? I’ve created a series of blog posts that look at each anti-pattern in detail. Each post is loosely inspired by actual events that happened during my 20-year IT career.
Take a look: