One of the biggest hurdles to successful software development is knowledge. Requirements are the knowledge we need to satisfy the customer. Process is the codified knowledge about how to get things done efficiently and predictably. Best Practises are the historic knowledge of what has worked well in the past. This is why software developers are among that group of people who truly deserve the title of “knowledge workers”.
As everyone goes about their daily tasks on a software team, they are processing, generating, and sharing knowledge constantly. Except when they aren’t. And that is often where the problems start.
If everyone on a software team had perfect access to all the knowledge in the team (everyone knew everything everyone else knew) the only potential sources for errors would be (1) bad knowledge, (2) incomplete knowledge, or (3) poor choices. There have been hundreds of books written about each of these topics. The whole requirements field is about addressing bad or incomplete knowledge. The design-patterns literature, best practices, and many development methodologies are all about improving the quality of the choices we make.
However, a more basic problem in a team is that we never have perfect knowledge sharing. It’s rare, on even the simplest of projects, that you can ask a basic question to everyone on the team and get exactly the same answer. If everyone isn’t working from the same knowledge, regardless of how good or bad that knowledge might be, how can we ever expect a project to run smoothly?
One of the greatest challenges on any software team is the basic issue of knowledge sharing. What do you share? How do you share it? Who do you share it with? The way a team approaches these questions will have a fundamental impact on the culture and effectiveness of their work. The success of a team is directly and unavoidably tied to their success at sharing knowledge.
Intuitively, most members of a software team already know this. They value knowledge sharing and quickly establish stand-up meetings, retrospectives, design reviews, Wiki pages, and lots of other tools to aid in sharing information around the team. These all help. However, I have noticed one particular behavior that effectively undermines all these positive activities. It is the dangerous assumption that everyone already knows what you know.
The thinking behind this assumption goes something like this:
I’m pretty sure this was mentioned yesterday in the stand-up meeting. And even if it wasn’t, it must be pretty obvious to everyone by now that we won’t have time to finish that last feature. If I mention it I’ll just waste everyone’s time and I’ll probably look stupid. I’m sure our team-lead is already on top of it.
The problem is, the person making this assumption is usually wrong. Many insights into bad project schedules, risky design decisions, poor testing plans, or misinterpreted requirements don’t usually occur to everyone at the same time. Eventually, as the project starts to hit the skids and begins going sideways, the entire team does become aware of the problem. But often a single person on the team has a clever insight that warns them of a problem long before it occurs to everyone else.
There are a few reasons these insights don’t get shared, resulting in suffering projects everywhere. The first reason is what researchers call the Confirmation Bias. In a nutshell, when we believe something to be true (“other people must see this problem because it’s so obvious”) we are more likely to see evidence that confirms our beliefs. If we think other people know what we know, we will find evidence that confirms our belief, even if it isn’t true.
The second reason is our personal pride or fear for our reputation. Even if we haven’t convinced ourselves that everyone else already knows what we know, we might be afraid to share in case we look foolish or end up irritating our team members. “I don’t know if the rest of the team is aware of this, but if they are I’ll look pretty stupid for bringing it up.”
Both of these reasons, and probably a few more, can keep us from sharing critical knowledge. Knowledge that, were it shared early enough, might be the key insight that prevents our project from failing.
So what is the solution? Fortunately it’s pretty simple. Share your knowledge shamelessly. If you have an insight, share it repeatedly until your team takes clear and obvious notice. Your project is too important to fail because you are afraid of looking silly.