VIII. We Will Not Allow Our Devs to Talk in Private

How much information do your key employees keep in their heads? If your answer is “a boatload,” then I’ve got some very bad news for you: Anything not written down and shared becomes inaccessible when they leave your company. Any conversations they’ve had, any decisions they’ve made, and any special knowledge about projects just disappear. To use a computing metaphor, a lot of your company’s data is stored exclusively in RAM.

A truly valuable company can continue to operate and thrive independently from its employees. On the flip side, if a company would fail with the loss of a single key employee, it’s hardly a business at all. That “company” can only survive until that person leaves. And no matter what, that person won’t stay forever. There will be a new opportunity, a legal issue, a family emergency, or a health problem. Unless there is a radical breakthrough in life expectancy, this is guaranteed.

Will your company outlast you? Will it outlast your engineers? Is your company more than just the people who work for you? If all your engineers quit or disappeared in the Rapture, what would be left?

Hopefully, all your servers and databases would still be up and running. All your data would be safe on hard drives. All your code would be available in repos. Maybe you have a well-maintained wiki. Is this enough for a brand-new team to come in and operate? Would they be able to build off what’s left?

If there was critical information that only existed in the minds of your team, success is unlikely. Onboarding is difficult enough for newbies when an existing team is in place, and it would be next to impossible if all the essential people and knowledge were gone. The new team would waste countless dev cycles reinventing the wheel or relearning old lessons. There would be clues in the codebase, but we could also expect the new team to relitigate old decisions because nobody would know why things were built in a particular way.

Now imagine this: What if all your team’s conversations were recorded and searchable? What if new team members could just read the transcripts of a previous newcomer’s onboarding process? What if an entirely new team could find and read all discussions related to a project’s decisions? The future of your product—and your business—wouldn’t be so dire.

In fact, even if your current team doesn’t disappear in the Rapture, capturing relevant conversations has huge benefits. Anyone you onboard will have infinitely more context at their disposal to figure things out. Anyone who quits won’t be taking institutional knowledge with them. Even within your company, devs can move between projects much more easily and get up to speed faster.

It’s a daunting task to force your teams to take detailed notes of every meeting (recording video and transcribing the dialogue would also work), upload them to a centralized place, and make them searchable. The good news is that you don’t need to go to these lengths.

Instead of having voice and video calls, just default to having meetings and conversations in chat.

To anyone who enjoys meetings because they’re fun and social, this might sound awful. Typing messages back and forth can make it harder to laugh and joke around. Others may not like it because when writing, you need to put more thought into how you communicate.

Some act as if it’s impossible to inject levity and fun into written communication. The written word has made people laugh and connect emotionally for centuries. This power did not arrive with the telephone or Webex. As a bonus, you can still share funny links, images, and video clips.

I have less sympathy for people who prefer to talk on the phone because it’s “easier” or “quicker.” I agree that writing can be more difficult. But that’s only because it takes more effort to structure your thoughts clearly and concisely.

It’s a mistake to avoid communicating clearly just because it takes more effort. Writing forces you to think about what you are saying before you say it. You can’t just wing it, and you can’t easily handwave over incomplete thoughts. Even if it takes more effort, this is not a bad thing. The effort pays for itself.

When people work for a company, their effort should be directed toward building the value of the company. The company pays money to the employee, and the employee generates value for the company. If your devs are generating institutional knowledge that only exists inside their heads, the company is only getting a fraction of the value. Worse, that value can disappear at any time. If your company’s value can disappear at any time, you don’t have a durable company.