I used to work with a software developer named Stephan. Stephan was territorial about his knowledge. If I asked him a question, I could almost see the wheels turning in his head: “If I give Karl the full answer to his question, he’ll know as much as I do about that topic. That’s not acceptable, so I’ll give him half of the answer and see if he goes away.” If I came back later seeking a more complete response, I might get half of the remaining answer. In this way, I asymptotically approached getting the complete answer to my question.
Extracting information bit by bit from Stephan was annoying. The information I sought was never confidential. We both worked at the same company, so we should have been aligned toward our joint success. Stephan apparently didn’t agree with me that freely sharing knowledge with your colleagues is a characteristic of a healthy software culture.
Knowledge isn’t like other commodities. If I have three dollars and give you one of them, now I have only two dollars. Money is zero-sum in the sense that I must lose some of it for you to gain something in this transaction. In contrast, if I give you some of my knowledge, I still possess all the knowledge myself. I can share it with other people, as can you. Everyone touched by this expanding circle of knowledge benefits.
The Knowledge Hog
Some people hoard information out of insecurity. They fear that if they share some of their precious hard-won knowledge with others, those other people become more competitive with them. Perhaps that’s true, but it’s flattering for someone to ask for your help. The requester is acknowledging your superior experience and insights. Rarely, someone might ask you for information because don’t want to take the time to figure it out themselves. You don’t have to do someone else’s work for them, but you should remember that you and your teammates are all working toward the same ends.
Other people carefully protect their knowledge as a form of job security. If no one else knows what they know, the company can’t possibly fire them, because too much institutional knowledge would go out the door. Maybe they think they should get a raise because they’re the sole holder of so much important information. People who conceal organizational knowledge pose too much risk. They create an informational bottleneck that can impede other people’s work. My colleague Jim Brosseau aptly refers to knowledge hoarding as technical ransom.
Rectifying Ignorance
A healthy organization fosters a culture of knowledge exchange and continuous learning. Sharing knowledge enhances everyone’s performance, so management rewards people who freely pass along what they know, not those who keep it to themselves. In a learning organization, team members feel that it’s psychologically safe to ask questions. We’re all ignorant about most of the knowledge in the universe, so let’s learn from our colleagues when the opportunity arises.
Experienced members of an organization can share their expertise in many ways. The most obvious method is simply to answer questions. But more than just answering questions, experts should invite the questions. They should appear approachable to fellow employees, particularly novices, and be thoughtful and patient when someone picks their brains. Beyond simply transferring information, experts can convey insights about how to apply the knowledge to specific situations.
Some organizations use formal mentoring programs to get new team members up to speed quickly. When I began my professional career as a research chemist, I was the first guinea pig for a new mentoring program. My mentor was a scientist in the group I had joined, but he wasn’t in my reporting chain. He helped me get rolling in an unfamiliar technology area. A mentoring or “buddy” program reduces the learning curve for new team members and starts building relationships with them immediately.
Scaling Up Knowledge Transfer
One-on-one communications are effective, but they don’t scale well. Experienced, talented people are much in demand, both for their project work and for the expertise they can share. To cultivate a knowledge-sharing culture, consider techniques to leverage information more efficiently than one-on-one time spent together. Here are several possibilities.
Technical Talks
My software development team once decided to work through the many excellent programming examples in Steve McConnell’s classic book Code Complete. We took turns studying a particular section and then describing it to the group in a lunch-and-learn session. These informal group learning experiences efficiently disseminated good programming practices across the group. They facilitated a shared understanding of techniques and a common vocabulary.
Presentations and Training
Formal technical presentations and training courses are good ways to communicate institutional knowledge across an organization. I developed several training courses when I worked at Kodak and delivered them many times. If you set up an internal training program, line up enough qualified instructors so that one individual doesn’t have to teach the same courses all the time.
Documentation
Written knowledge spans the spectrum from specific project or application documentation to broadly applicable technical guides, tutorials, FAQs, Wikis, and tip sheets. Someone must write this documentation, which means they aren’t spending that time creating other project deliverables. Written documentation is a highly leverageable organizational asset, provided that team members turn to it as a useful resource.
I’ve known people who preferred to rediscover knowledge on their own rather than seek it from existing documentation. Once someone has invested the time to create relevant and useful documentation, it’s a lot quicker to read it than to reconstruct the same information. All organization members should be able to update such documents to keep them valuable as current sources of pooled experience.
Deliverable Templates and Examples
When I worked in a large product development organization, our process improvement group built an extensive online catalog containing high-quality templates and examples of many project deliverables. We scoured company software departments for good requirements specifications, design documents, project plans, process descriptions, and other items. This “good practices” collection provided a valuable jump-start whenever any software practitioner in the company needed to create some new project artifact.
Technical Peer Reviews
Peer reviews of software work products serve as an informal mechanism for exchanging technical knowledge. They’re a great way to look over other people’s shoulders and to let them peek over yours. I’ve learned something from every review I’ve participated in, whether as a reviewer or as the author of the item being reviewed. The technique of pair programming, in which two people write code together, provides a form of instantaneous peer review, as well as exchanging knowledge between the programmers.
Discussion Groups
Rather than trying to locate exactly the right person when you have a question, you might post the question to a discussion group or group chat tool within your company. Exposing your lack of knowledge to a large community can be awkward. That’s why it’s valuable to grow a culture that invites questioning and rewards those who assist. Ignorance is not a tragedy, but an unwillingness to solicit help is.
Discussion participants can offer multiple perspectives on your question quickly. The posted responses are available to everyone in the discussion, which further disseminates the knowledge. You probably weren’t the only person who didn’t know the answer to that specific question, so good for you for asking.
A Healthy Information Culture
Everyone has something to teach—and to learn. You don’t need to be the world’s expert on some topic to be helpful. You just need some useful block of knowledge and the willingness to share it. In the world of technology, if you’re one week ahead of the next person in some area, you’re a wizard. Someone else will doubtless be ahead of you in other areas, so take advantage of their trailblazing. People in a healthy learning culture share what they know and also acknowledge that someone else might know a better way.
===============
This article is adapted from Software Development Pearls: Lessons from Fifty Years of Software Experience by Karl Wiegers. Karl is the Principal Consultant at Process Impact and the author of numerous other books, including Software Requirements, More About Software Requirements, The Thoughtless Design of Everyday Things, and Successful Business Analysis Consulting. You can reach Karl at tinyurl.com/sdpearls.
Author: Karl Wiegers
Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 13 books, including Software Development Pearls (from which this article is adapted), The Thoughtless Design of Everyday Things, Software Requirements, More About Software Requirements, and Successful Business Analysis Consulting. Karl has also written many articles on software development, design, project management, chemistry, military history, consulting, and self-help, as well as 18 songs. You can reach Karl at tinyurl.com/sdpearls.