One of the first companies I founded was built around university students. It was built on the premise that I could pay university students a little bit less in exchange for job security through their undergraduate career. I would also help them to make a worry-free transition to their first post-graduation job. They had no need to be stressed about finances or work while they were waiting for their first offer letter from a brand name company.

The very premise of that business model was that your student-employees are going to go away. That had to be a part of everything we did. We were lucky enough to partner with a highly-ranked university, teaching computer science and design. We taught and poached some very bright students. Bright students are meant to go places, which means they don’t really want to stay in any one place for too long. These are the kinds of people who leave high profile jobs at Fortune 100 companies to start the next big thing.

My students wound up doing interesting things at great places. They were on the Docs and Firebase teams at Google. They went to Facebook and Oculus. They went to Amazon, Microsoft, and Adobe. One even wound up on the compression team at YouTube, an impressive feat.

Teaching was great for my business model, because I received a steady supply of outstanding students. I would train them, and then the older students would pass the baton to the younger students. I didn’t have the luxury of holding on to students for more than three or four years. If I was going to build any sort of institutional knowledge, that had to be built into the DNA of our company.

Building Institutional Knowledge

Tribal knowledge is information that belongs to people inside of a company. It’s in your head, and it’s in my head. It is the accumulation of our wisdom and experience. It is our education from the school of hard knocks. Institutional knowledge is the collective knowledge and wisdom of members of the company, past and present, accessible in a form that is independent of those who learned the lessons.

Tribal knowledge gets passed from generation to generation in the way that knowledge has been passed down for most of human history: storytelling. If someone tells you the story, you learn the lesson. If someone leaves before they can share all of their stories, that knowledge is gone, forever.

Institutional knowledge, by contrast, stays around forever. It is the building block of scalable companies. It’s not a magic bullet, but it has many advantages over tribal knowledge.

In our first software company, there were a couple of great things we did to make sure that the tribal knowledge started to be integrated into institutional knowledge. We had traditions such as a weekly internal lecture series and “Free Food Fridays” to help ensure that more of the tribal knowledge got passed down quicker. We also had a series of software tools that we used to capture information and turn it into institutional knowledge.

Traditions Can Accelerate the Spreading of Tribal Knowledge

Some sort of passing of the baton is important to make sure that lessons learned don’t evaporate when your senior employees leave. Not all knowledge needs (or even should) be recorded in a retrieval system and deemed institutional knowledge. Many things, including elements of company culture, simply need to be passed from person to person.

We had our own internal lecture series. We would do lunches together on Fridays, and someone would give a presentation. The staff nicknamed them “Free Food Fridays”, because I was paying for their food. I was willing to pay for the food and a working lunch because it was the number one way to promulgate company culture. Not only was it a time to laugh and to enjoy good food, but it was definitely storytime.

We shared stories on every conceivable topic. We talked about great interviews and horrific interviews. We shared mistakes that we made, and we celebrated wins together. It was a forum for informal project postmortems, and it was a place where we could pick up on early warning signs that someone wasn’t feeling included, welcomed, or nurtured inside the company.

As a way to keep our older employees still engaged, we would let them lecture on topics that were interesting to them. We had lectures on mathematics, encryption, unique programming languages, and mathematical recreations. At times, the more senior employees would use it as a soapbox opportunity. “Hey, this is what you guys keep screwing up. This is what's making our life difficult in the company. Do these things that the old guys know how to do, and everyone will be happier.”

It was a remarkably productive time, and easily 100x more productive after we moved the venue from local restaurants to our conference room with a full catered meal. As our team grew, it became impossible to get everyone seated within earshot in a restaurant. Inside the office, all around the big whale table, and with catered food, we had a quiet, controlled environment.

Perhaps somewhat counterintuitively, catered lunch was easily a quarter of the cost of our dine-out lunches. That was probably the second best decision we ever made while running that company.

Knowledge Management

Knowledge management tools are where the rubber hits the road. You can have an oral culture where you pass information on as much as you want. Without written records, however, your company cannot advance from the Castle Age into the Imperial Age. No trebuchets for you.

We’ve built companies where that has worked very well. We’ve also built companies where knowledge management has been a complete disaster. When you only have two or three people, real-time knowledge sharing matters more than consolidated knowledge management, but both are necessary. There are seven mistakes that companies make when they try to introduce any knowledge sharing or management tool.

Mistake 1: Too Much Fiddling Around

We have made this mistake far too many times. Tools are cool! Product Hunt is an awesome website! We know. It’s great that software is eating the world and that the barrier to entry for creating a new software tool is so low. If we are not careful, however, we get wrapped up in the never-ending quest for something incrementally better. This leads to one problem:

A culture of fiddling with tools destroys your ability to get anything done with those tools.

It takes dedication to a single tool to be able to use it well. You have to have a critical mass of content and adoption in order for anybody to really use that tool. The single most destructive habit we had in any of our previous companies was to introduce a new tool every couple of months.

People are just getting used to the previous tool. Then you throw something new at them! It takes time for employees to learn a tool. It takes even more time for employees to integrate that tool into their workflow. If people don't know which tool provides the right information, they will resort to their own systems.

If you're always changing systems and tools, your employees won't feel secure putting any data in any tool. After all, the boss is just going to find something better in a few weeks and abandon this one. This spells death for any tool.

You may have enthusiastic staff members who go to a lot of trouble to write up a bunch of documentation and put it in a local wiki – or whatever the flavor of the week is for you. If your other staff members have already been conditioned not to rely on your ever-changing repertoire of tools, they will never use this new tool, and you will lose the cooperation of the very people you need to drive adoption of the tool.

Mistake 2: Not Integrating the Tool Fully

Even in very small startups, there are network effects. The more people are using a tool, the more people will read content in that tool. The more people read content in that tool, the more people will write content in that tool. The more the tool is embedded into the workflow of employees, the more it will stay embedded.

As tools become deeply entrenched, these exchanges become more common:

“I have a question for you about X.”

“Did you check the company wiki for X? Because I wrote the answer to that question there.”

Or my favorite:

“I noticed X wasn’t in the wiki. Can you teach me, and I’ll write it up?”

It’s a beautiful thing when data lives in the tools, when processes’ critical steps are tracked in the tools, and when status reports are merely a button click away.

None of that happens until people are living in the the tools you choose.

Mistake 3: Picking the Wrong Tool

Of course, those things are only possible when you pick the right tool. You’ve already committed to fiddle less and integrate more, but you aren’t going to be able to avoid the siren call of new tools quite yet. That’s fine. Let’s learn a simple taxonomy of tools so you can name the problem more accurately.

There are two types of knowledge tools that you will want to be concerned about. There are static tools, and there are flowing tools.

In static tools, you put knowledge in, and you can find it later. You can search for it. It's there. Wikis. Spreadsheets. Databases. Enterprise Resource Management tools. Customer Relation Management systems. A company address book. These aren’t static in the sense that they are fixed and unchanging – far from it – but merely in the sense that they have some sort of roughly static data structure that we can map to when we are thinking about the tool.

Address books have entries, with names, and a general set of data associated with those entries. Kanban boards like Trello have stacks and cards, associated with whatever data belongs to any given board structure. CRM tools have leads and clients in various stages of nurture and education.

Flowing tools are like a stream where the data is always passing by. In the postmodern era of massive data collection, we save everything from the stream for search and analysis. We build massive data warehouses or data lakes and pray that someone will come and analyze our data for us to unlock massive insights.

But, we’re not there yet. While we can infer some structure from data through semantic processing and natural language processing, this isn’t something that is going on for you, in your company, right now. That’s the domain of the future.

As such, flowing tools are like a firehose (or stream). Data keeps coming, only lightly structured, if that. Twitter and Slack are the biggest example of this. It's a flow of information and you dip into the stream a little bit. You're not there all the time. If you try to be, then you, too, can suffer from Slack-induced Post Traumatic Stress Disorder.

A never ending flow of unfiltered information is unequivocally bad for the human brain. We need periods of downtime to filter, sort, and discard information. When choosing flowing tools for your company, be careful that these tools 1) supplement human interaction, not replace it, 2) have settings that allow users to enforce downtime requirements, and 3) do not force users to search in order to get value out of the tool.

In our companies, we opt more and more for tools like voice and video conferencing, instead of text chat. We also enforce strong etiquette rules about expected response time for different forms of communication.

Mistake 4: Not Having a System For Introducing New Tools

When you’re building a company or an organization from scratch, you find the most energetic, forward thinking people you can. They excitedly put all of their energy into providing you with solutions to your problems. They take initiative.

They spin up Slack instances. This is a problem.

You can't simply say, “Oh, I put up a Slack instance for everybody! Sign on! I invited you!” after you reach a certain size and after a certain amount of time passes. (This is why tools like Slack get adopted at the team level in companies more readily.) You need a plan. You are doing things that interrupt people’s workflow.

This is when we return to the era of “RFCs”.

A QUICK ASIDE ON RFCS

Back in the early days of the Internet, bright engineers would circulate proposals for new technologies. These proposals would make their way around the fledgling inter-tubes for others to discuss and debate. These proposals were called “RFCs” or “Request for Comment” documents. Someone had what they thought was a brilliant idea, and they wanted to make sure that the other people who had a choice in how they were using their energy were willing to get on board with these new ideas.

If you’re going to have a plan, you have to have success criteria. You will want Key Performance Indicators (KPIs). You will want a plan for what you do if things succeed, and what you will do if things fail. These KPIs don’t have to be difficult to track. Let’s say you are adopting GSuite. You have access to a whole set of statistics about user utilization of the tool. You can see who is using which tool.

The value isn’t necessarily in the plan. The value is in communicating that you have a plan to the other stakeholders. As knowledge workers, we love it when we can focus on our work, and when the rest of the world is in a predictable state around us. Having a plan and communicating the plan generates confidence. It also allows people to determine how much time and energy they will invest in integrating the new tool into their workflow.

One way you might think this is comparing it to a very, very miniature startup. Your co-workers or employee---those are your customers. Ultimately, their decisions rule the day. They will vote with their time, their effort, and their knowledge. Without those elements, your new tool is dead in the water.

Mistake 5: Not Having a Tool Evangelist

I love the term popularized by Steve Blank, ‘earlyvangelist’, a portmanteau of early and evangelist. You may have a plan in place, but people in the company still need to buy into the plan. They need to put their time, effort, and knowledge into the system in order for it to be useful.

Can we get people to use the new tool? Most importantly, whose responsibility is it to get people to use the tool? Surprisingly, most of the time choices about these tools are not being dictated from above. Most of the time, the tool choices spontaneously arise from strong personalities and a predilection for experimentation. It's very rarely, “We've decided that we're going to implement Salesforce company-wide and you are forced to use Salesforce.”

In our companies, we put the burden of new tool adoption on the person who proposes the tool. If the person making the proposal can get a critical mass of early adopters, then the tool thrives. There is one other positive benefit that comes from having the suggester write things up. Chronic tool switchers now have one more barrier to imposing their indecision on others.

Mistake 6: Thinking of Documentation as Static

This is a question of both refactoring and documenting.

Documentation is living. Changes have to a be a part of the workflow. Documenting evolving processes is a bit like documenting the process of developing a new technology. There’s this big unknown thing that you're grappling with. You've got a huge possibility space. What are we going to work on? Is this going to be hard or easy? What exactly are our goals here? What does “finished” look like?

One of the great things refactoring and documentation have going for them is that they are more linear, more predictable. In an industry where you often can't really provide an estimate, the “maintenance” tasks of paying down technical debt generally have much more predictable timelines. They’re safer choices, in that they’re very unlikely to just kind of balloon out into a huge nightmare.

The problem, though, is that you do those things to prevent disasters and to speed future development, but they don't drive sales, or get users, or any of those great things – at least not by themselves. They’re analogous to cost centers, if you look at technology development through an accountant’s lens. They need doing---but not too much.

The knowledge in your company is always changing and evolving. You can't approach this with the idea that “We’ll do this one big refactor and then we're done,” or, “Let’s document everything, and we’ll never need to do it again.” Instead, the way you have to approach it is in a bang-for-buck kind of mindset. You must think in terms of, “We have this much time available. Given that, what's the best way to get the maximum return on the time available?” You will get better outcomes focusing on the effort involved, rather than the final result. There is no final result. You’re never “done”.

Think about the last time you had to dive through an unlabeled filing cabinet or unlabeled set of boxes. Would it have taken effort to label all of the things before you put them in the cabinet or box? Of course so. Is an additional five seconds per item an acceptable cost for finding things easily in the future? Sometimes the answer is clearly “no”, but in business, sometimes the answer is a resounding “yes”. If the answer is “no”, don’t document those bits. Only do it when there’s a clear advantage to documenting something.

Mistake 7: Not Understanding Who Should Be Documenting Systems

It has been a big trend among entrepreneurs in the last 10 years or so to read books like The E-myth or Work The System. The argument is that if you only had solid “Standard Operating Procedures”, or SOPs, for everything, then you could hand all of those tasks over to someone else and be free.

That's true to a first approximation. Unfortunately, a lot of the beliefs surrounding this theory of documentation put the entrepreneur in the seat of authoring all of these SOPs. The myth is that you can hand off these tasks to someone in a low cost-of-living area and arbitrage for the win.

If your business is complex enough that there’s a meaningful difference between “senior” and “junior” employees, life is not that simple. If you are spending your time writing these procedures down as a founder, you're wasting your time. Particularly so the bigger and more high level your company has become. Could you imagine the president of GitHub or the founder of Uber writing down some SOP for a driver or an inspection agent?

Keeping your knowledge base updated – whether that be as simple as code comments or as complex as a network of wikis – should be a company-wide endeavor. Both line and management should be making contact with their knowledge repository in the course of their normal work day.

Ship of Theseus

The Ship of Theseus was a logical paradox the Greeks posed. In the story there was a famous ship. Over time it had every plank replaced, one or a few at a time. The question they posed was this: Now that every piece of the ship has been replaced, is it still the same ship?

Our companies in the postmodern era are in a similar place. Our companies must reinvent themselves, piece by piece over time. Companies that fail to do so wind up weighed down by legacy policies, procedures, and methods. A corollary for this from the programming world is the concept of technical debt. The idea is that I, as a programmer or an architect, made a decision that was expedient at the time to get something going. That decision is going to have consequences for me later unless I do something about it.

Our businesses sit in a marketplace that is constantly in motion. Our ship sits in the harbor aside Theseus’ ship. Over time, the planks in our ship may decide that they want to be somewhere else. They may fall off into retirement and declare, “I’m done here. I’ve had it carrying this load. It’s time to float off to the Bahamas.”

When that day comes, one of two things will happen. Either we will smile and bid those pieces a fond farewell, knowing we have prepared well, or we will find out we lost a piece of us critical to seaworthiness, and we will panic as the water starts pouring in.

(Originally written for Prime CTO)