We’re about 400 employees total and 100 employees in product or engineering roles, forming about a dozen teams, and in this setting it’s really, really hard to accumulate knowledge and keep it uniformly distributed among, say, all engineers. Tradition of tribal knowledge, where people would simply talk to each other to exchange information, make decisions and seal them, worked just about 20 months ago, when the company was one-fifth of that, and teams of teams were only beginning to emerge.1
Since then, a lot of engineers have joined the company, right in the middle of a major rearchitecture effort. Now we have:
The old guard still tends to operate in tribal mode. Quite literally, the engineers who were incredibly successful when the company was 40 people, by default choose to work the same way even though the company is now 400 people. Good: these engineers are aligned so well, they don’t need to argue or even talk much, they just do. Bad: engineers of the new guard cannot keep up. You probably have had this experience: you join a team, it’s so gelled you’re feeling lucky, but then people start talking, and you see how they make decisions in minutes, and nothing of what they are talking about makes sense to you.2
In an ideal world, when an engineer discovers knowledge, they broadcast it so that the others pick it up, and the others then actually pick it up. In reality, it’s a lot messier: people don’t have time, they don’t see value in sharing something, or they overshare, or they don’t follow, or they focus on their own stuff. The whole thing then drifts into misalignment. So it needs a dedicated effort to keep it afloat.
Do two things:
Pattern matching is hard and requires all engineers to constantly learn to see what piece of information is worth putting on a record. It cannot be done with policies (which are, by the way, an instrument to make pattern matching easier), and for sure there’s no Udemy course or anything like that which would teach how to see patterns in inherently noisy stream of events.
The biggest knowledge accumulation challenge of all times at scaling companies is whether a certain bit of information represents something valuable or not, and what is its “best before” date. Consider two dimensions:
In the beginning, you’ll see a lot of false positives: stuff residing in your knowledge base system of choice that has limited use, either in terms of reach or in terms of time. Evaluating every bit of knowledge on these dimensions is not a trivial task. It takes effort and skills. The more the org supports that through feedback and opportunities, the more likely it is to happen. In orgs where engineers are expected to only “deliver”, no documenting will take place, given that all engineers are hyperrational towards their incentives. In orgs where teamwork and enablement are valued as much as individual contribution, engineers will systematically optimize for doc skills.3
For having people train their pattern matching skills, a heuristic that I’ve seen most success with: welcome the false positives, but ask authors to categorize the information. When docs don’t fit together, it’s time to reevaluate what is worth keeping and what can be adjusted, merged, or deleted.
After that, documenting is easy, but writing in general doesn’t come easy to a lot of people.4
Besides, documenting skills are only rudimentary in most of the engineers for a reason: in the early days of a company, knowledge travels fast because everyone is in one room (alternatively, there’s one channel on Slack). In most established companies, knowledge travels slower, but there’s not a lot of it being generated on a daily basis. So it’s mostly about companies that change very fast — by scaling very fast, mostly. Not a lot of engineers, globally, have an opportunity in their careers to work in a company that scales or positively transforms rapidly.
We have a career ladder for engineers at Personio. Most of the criteria hint at enablement of peers; some of them are concrete and point at running the knowledge exchange at scale. This creates reasonable guidelines for engineers to avoid falling into the works-for-me local optimum. At this stage of the evolution, it makes a lot of sense to incentivize this for all engineers equally.
In the end, a few practical notes:
Des Traynor of Intercom has talked about “team → teams → teams of teams” evolution of a scaling organization in his talk “Why people are key to scaling your startup”. It’s an interesting talk that uncovers a lot of complexity that is natural to scaling companies but hardly visible until it hits you in the back at full speed. (up)
A good read on how this kind of systems works is Donella Meadows’s “Thinking in Systems: A Primer”. Two takeaways from the book: 1) a change won’t happen overnight, unless the feedback cycle is really, really tight (usually it isn’t), and 2) actors in the system matter less than the actual system, so it’s on the management to create incentives for engineers to optimize for teamwork and enablement of their peers and to tune down individual contribution a bit. (up)
I’m yet to discover a solid source of actionable advice for engineers on developing writing skills. Maybe one day at Egghead? (up)