Share Shamelessly

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.

Advertisements

9 thoughts on “Share Shamelessly

  1. I think you are leaving out a couple important sections here.

    First, how does a manager ensure their team shares shamelessly? How do you foster this feeling in other?

    Second, how does a manager handle a situtation where an employee’s shameless sharing is ‘put down’ by another employee? Once this happens once, I can envision a slippery slope where suddenly less and less people share. Fixing this situation will be critical.

    • You’ve raised a number of really important points Greg. I try to keep my posts around 500 words and that keeps me from discussing many interesting topics. I’m glad you brought these points up. I agree that there is lots that a manager (and team) needs to do if they want to create an environment where information sharing happens freely and continually.

      One way to encourage people to share is to call on them explicitly to share their opinion or ideas. I’ve done this in team huddles and other scenarios and it can work very well. Just make sure you know your team members well enough so that you don’t put someone uncomfortably in the spotlight. You can also invite people to share with you individually in a one-to-one meeting. This can help build their confidence as they learn someone is listening.

      As for put-downs and other negative behaviours, those need to be handled immediately. It is critical that people willing to share ideas know the team will support them when they have the courage to speak up. Because you are absolutely correct – things can go downhill quickly if negative comments aren’t corrected.

      • Something I have experienced lately is one of these put down scenarios. As I was thinking out loud during a meeting with a few people, a co-worker shot down my idea mid sentence and essentially called it stupid. Frustrating to be sure. Demoralizing, you bet. Was I dismayed? No. Experience has taught me that I have a lot to offer even if that idea wasn’t my greatest. But I have a few years of experience behind me.

        Something a manager can do is follow up on people’s seemingly innocuous ideas and see if they have merit. This can lead to self confidence in the other person because their ideas are being taken seriously. Whether or not the idea gets used or has merit isn’t relevant. The individual has a voice which is important if you want people to feel like they belong.

      • Thanks for sharing that experience. I know you’ve been at this long enough to quickly get past something like that. You are right that a good manager will identify those situations and follow-up to ensure the person who took the time to share their idea realizes they were doing the right thing.

    • Nice questions, Greg, and I completely agree with you.

      I suggest that the lead must … lead by example. That is, take the opportunity at daily stand up meetings to repeat things ad nauseum. And then repeat them again.

  2. Cliff, the link that discusses Confirmation Bias was a very interesting little read. In particular, I liked this quote:

    Attempts to teach critical thinking can be counter-productive if confirmation biases are not addressed, since by applying logical thinking only to one side of an argument, thinkers can become “actively closed-minded”.

  3. Thanks for the post Cliff.

    One question that came to my mind, although I don’t have any real experience is, how do you decide what to share, I mean can’t it also be problematic if you share to much unnecessary stuff and hinder people from getting any real work done because to many other co workers are shareing knowledge all the time.

    • Sure Adrian, there is always that risk. But in my experience, people tend to manage that one pretty well on their own. If someone is proving too distracting in a meeting or around the office, they usually find out pretty quick. If they don’t get the message, you have a rather different problem: the irritating co-worker. Dilbert has lots to say about that 🙂

      More seriously, a manager could certainly step in and help this person see their actions as distracting. Suggestions about writing their ideas down and saving them for the next brainstorming session, or keeping off-topic messages to a particular mailing-list or Wiki page, might be worth considering.

  4. Pingback: 2010 Blog-Stats in review « Leading Software

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s