Send to HN

TL;DR

Don’t hoard knowledge. If you know something that would benefit others then share it freely and make it accessible. Sharing is caring.

Why you hating on Tribal Knowledge, Kev?

“Knowledge is power“

Francis Bacon

I agree, Francis, but when your siloed knowledge turns into a bottleneck for your coworkers that ain’t cool.

I’m wary of two different sources of tribal knowledge:

  1. The individual contributer
    1. If a single person is responsible for building or maintaining a system then that person will turn into a bottleneck when the sh** hits the fan. Looking’ at you, Brent from The Phoenix Project.
    2. When an employee resigns, they often leave without proper knowledge transfer and teams are left to pick up the pieces. Lookin’ at you, Newman from Jurassic Park 🦖.
      • This is especially common with the tech industry’s high rate of employee turnover.
  2. The team or department
    1. When a team or department has too much tribal knowledge then cross-team/department dependencies block work from progressing smoothly.
    2. There’s also risk of teams duplicating effort when working on the same problem without realizing it.

How to be anti-Tribal-Knowledge

Write accessible documentation

A few years ago, I found myself being a bottleneck in a complicated software configuration/delivery process. There were so many undocumented steps that it became impossible for my team members to finish certain tasks without asking me questions –which took a lot of my precious time.

Long story short, I went on a mission to document the algorithms in my head in a clear, concise way. After a bunch of iterations, my coworkers stopped asking for my help and I was free 🐦.

“The docs will set you free“

Kevin LeStarge, lol

Caveat:

It is possible to get carried away and document too much to the point that your docs become noise without much value. Use your best judgement when deciding if something is documentation-worthy. A good rule of thumb is if you need to explain something a second time then it should be written down.

Caveat #2:

“A comment [in the code] is a lie waiting to happen“

Josh Susser

Confluence and ReadMe docs are the same as code comments in this regard: they’ll quickly get outdated. Thus, it’s important for your team to develop a culture of “leaving it better than you found it“.

If the doc is wrong, either fix it, delete it, or at least leave a comment letting future readers know that it’s outdated.

Automate if possible

What’s better than clear instructions describing a manual process? An automated process of course 🤖!

Write a script for it, build it into your CI/CD pipeline, build a self-service web app, etc. Your usecase will dictate the software you need to build. Computers will outperform any human as long as the instructions are written correctly.

Review each other’s code

Code reviews will increase the quality of your code but will also give visibility to an inherently siloed part of the code base: the new stuff you just wrote. Read more about my love affair with code reviews.

Demo your stuff

Demos, live or recorded, can be a great way to spread knowledge around –especially if you don’t like writing things down.

Sprint demo and product/tech review meetings are a great place to share demos. But also don’t hesitate to drop a screen recording in your team’s communication channel right now if you think it will benefit people.

Destroy all zombie code

How is zombie code 🧟‍♂️ 🧟‍♀️ (never executed code) related to Tribal Knowledge?

Because:

  1. It usually requires Tribal Knowledge just to know which code is zombie code.
  2. We don’t know why the code is a zombie. Is it because the code isn’t finished yet? Was the feature ultimately abandoned? Does it contain bugs? That’s all Tribal Knowledge.

Please, do your part in the detection and deletion of zombie code.

But what about “ownership“?

In my head at least, there is a dichotomy of being anti-Tribal-Knowledge (pro-Institutional-Knowledge) and being pro-Ownership (pro-specialization).

Here’s how I sometimes think about this relationship:

Because if everyone is responsible for everything, then no one is responsible for anything.

Here are some examples where I’ve seen a lack of ownership hinder my team:

  • When too many devs own a repo, standards and patterns go out the window and the result can be a messy codebase.
  • A first-to-know (FTK) alert triggering or a high priority ticket pops up: everyone hopes someone else will respond (classic case of the Bystander Effect or the Volunteer’s Dilemma).
  • When tickets are tightly coupled (part 1 and part 2, frontend and backend, etc) and two or more devs pick up these tickets in parallel but don’t communicate with each other. This leads to re-work because the resulting code doesn’t mesh well.

However, I’m pretty sure I’m thinking about this in the wrong way. This is a false dichotomy. Just because you are “anti-Tribal-Knowledge“ doesn’t mean you shouldn’t have a proud sense of ownership.

How to keep a strong sense of Ownership

I’m no expert, but here are some ideas I’ve been playing around with that seem to help:

  • Assign Codeowners for repos. This gives a select few individuals the final say on whether or not code can be merged –encouraging ownership and a consistent code style.
  • Identify team member specialties/areas of focus and assign them related tasks. This especially makes sense for large teams.
  • Encourage collaboration and transparency especially when blocked or working in-parallel on the same feature.

Conclusion

It’s impossible and impractical to eliminate all Tribal Knowledge –we all work in silos to some degree.

However, if we’re cognizant of our siloed knowledge and strive to teach and learn from one another while keeping our sense of ownership, then our work will result in rainbows and ponies from now on 🌈 🐴 🤗.

Read More