The Importance of Internal Knowledge Sharing

Engineers have a lot to benefit from sharing knowledge internally. Here's a brief summary of why it's important and an example of how RightScale has tackled the problem.

“If you have knowledge, let others light their candles at it.”
- Margaret Fuller

Don't be this guy

As a software organization evolves, it invariably encounters the growing pains associated with sharing knowledge across an ever-increasing number of teams. Throw into the mix the myriad of factors contributing to structural volatility in a company - team reorganizations, employee onboarding and offboarding, hospitalizations - and it’s a wonder that knowledge sharing is so commonly deprioritized. We can’t really ask our key knowledge silos to straight-jacket their lives or stay with us forever. Instead, our only solution is to encourage engineers to become sources of knowledge, not sinks.

But let’s face it. Sharing knowledge takes time and engineers are busy people too. We work in environments where we’re incentivized to pursue the “biggest bang for our buck”, often preferring short-term benefit over long-term interests. I feel this is one reason knowledge sharing is so frequently deprioritized in companies; speaking practically, it requires an up-front cost to the one investing time and energy to share the knowledge while seeming to provide no immediate benefit to them. But there is significant benefit to the internal dissemination of knowledge within a company, both for the giver and the receiver.

Hard work vs. Soft work

Knowledge sharing is a kind of work I like to call soft work, as opposed to hard work. Hard work produces tangible, quantifiable results, while soft work focuses more on the intangible and unquantifiable tasks which are nonetheless key for a company’s long-term health. Both kinds of work are vital for success. Yet, having worked in seven different companies, I’ve observed again and again a strong bias for, and reward of, hard work, often at the expense of soft work.

"TOO MANY SECRETS" - Credit: Sneakers

Coding for a new feature is an example of hard work - it produces a result directly measurable against a company’s goals. On the other hand, soft work is exemplified by efforts such as reducing technical debt, increasing software test coverage, improving internal tools and development processes, and internal knowledge sharing. It takes a forward-thinking organization to appreciate the costs of ignoring soft work.


RightScale Case Study: API Developer Workshop

“Thou shalt share knowledge.” - Someone pretty damn smart

Over a year ago, our Engineering department underwent a major reorganization. We transitioned from forming teams around code-bases and instead formed them around products and features. As part of that change, new “infrastructure” teams were created to support the code infrastructure that “feature” teams would use. As a result, the team I was on which used to handle all API feature implementation became the maintainer of API infrastructure (those common code pieces that all API features utilize). Suddenly, developers on “feature” teams with no previous API development experience were responsible for implementing any new API calls required by their features. This resulted in a flood of questions to the API experts, including myself.

Your brain on sharing

To remedy this, a colleague and I organized a two-day API Development Workshop for “feature” teams to learn about developing resources in RightScale’s API. We invited all of engineering to the workshop and created a Wiki page to be a complete reference for API development. The workshop was recorded and a video later uploaded so that engineers unable to attend could still watch it. The workshop focused on hands-on API development, with each attendee creating a resource from scratch with basic CRUD (Create, Read, Update and Delete) operations.

Over the following months, we observed a sharp decrease in the number of questions directed at the API infrastructure team. When questions did come, almost invariably we could redirect the developer to the Wiki page we made and they would find their question answered there. Whenever a question couldn’t be answered by the Wiki page, it was trivial to add the missing information because we had already taken the time to make a place to put it.

Preparing for the workshop took about a day for two engineers. But the amount of time we saved, while impossible to measure exactly, has likely been on the order of weeks over the course of the past year. By taking that knowledge out of our heads and and putting it somewhere where others can access it, we’ve saved a lot of time.

So here’s the takeaway - if there are others who could conceivably benefit from a piece of knowledge currently stored only in your brain, there is no excuse for not sharing it with them. You’re only setting up an unnecessary dependency that will later siphon your own time from you.

So, go forth and share thy knowledge!