April 1st, 2022
Information security and tech in general is a vast field and impostor syndrome is rampant. How do you learn all the hidden details, the tricks of the trade that "everybody knows"? Two methods that I've found to be incredibly valuable through time are running your own services and passively absorbing knowledge from the community.
This blog post covers the second part, whereby we surround ourselves by smart people, sit back, take a long sip of a nice cup of shut the fuck up, and listen. Behold, the power of Learning by Lurking!
Every field has its communities, as organizations break down into groups. This is in part due to the limits on communication within a given group (see e.g., Dunbar's Number and Brooks's Law), in other parts simple practicality. Different communities or groups may grow to significant size, but as far as information exchange goes, you likely still end up building trust relationships with only a subset thereof.
The resulting communities will all develop their own culture and protocols, which tend to have a self-reinforcing effect. (This can be both positive or negative: kind communities encourage kindness, and toxic communities attract toxic personalities.)
Now with an eye towards learning -- developing new skills, deepening your understanding of a given subject, or broadening your horizon beyond your immediate skills -- it is in your interest to immerse yourself in a group of subject matter experts. Sure, you can learn a lot about a topic by reading books, following tutorials on the web, studying via available online classes, or good old trial-and-error. And especially in tech there really is no substitute for actually doing it, writing the code, or running the service yourself. But there are limits to what you can learn this way.
Communities build up tribal knowledge, which includes solutions that are not obvious, undocumented, counter-intuitive, or built on assumptions and context not available to outsiders. (Good communities try to minimize reliance on tribal knowledge and document their environments, definitions, and procedures, but keeping software documentation reliably up to date is as of yet an unsolved problem, not to mention getting engineers to write documentation to begin with.) The hard lessons learned in every field are steeped in war stories and anecdotal background information.
Communities enrich this subject matter knowledge through diversity: diversity of background, of experiences, of knowledge, of expertise, or of cultural conventions and understanding. This diversity provides a richness of information that is not immediately measurable or even obviously tied to the progress of the team's efforts. Yet, the more diverse the group, the broader and deeper a learning environment it offers.
When you join a group -- an open source community, a new job, a team or cross-functional working group -- you can best learn the details by parking yourself in their primary communication channels, such as e.g., their mailing lists or IRC or Slack channels and lurk.
With time, you'll pick up background knowledge common to the group, its social norms, who are subject matter experts (and who are jerks), and likely learn a whole bunch of random things about various topics related -- and often unrelated -- to the field.
Lurking also has the notable advantage that it allows you engage the community on your terms and with as much time investment or intensity as you choose. Just mildly curious or have other high priorities? No problem, just ignore the discussions for a bit. Have some free time or you're completely enthralled with the topic? Dive right in and catch every single word. It's up to you!
A good rule of thumb for efficient lurking is to not be intimidated: Join channels or mailing lists liberally, sample the conversations, and if you get no value out of it, quietly leave again - no harm, no foul.
Filter mailing list traffic into a separate folder, and mute notifications in these channels, so as not to completely overwhelm you. Check the FAQ or other docs provided by the community, and take note of discussions or repeated topics that are not included in those documents.
Ask questions, too. Your viewpoint as a newcomer or outsider may often help identify gaps in documentation, flawed assumptions, or an overlooked requirement. And when you get an answer from outside the channel or found one yourself, share that, too, for you may save a fellow lurker endless frustration or simply nudge them to a solution.
In order to make it easy for people to join your group and ultimately turn them into active contributors, it's important to consciously support lurkers. Underlying these efforts are a strong bias to transparency and openness and engaging newcomers with assumed good intentions, able and willing to learn. You should consider questions an opportunity for you to improve your processes and documentation as well as to rethink your own assumptions. What made sense a few years ago may no longer be the right thing to do; the assumptions you based your service on may no longer hold or be adjusted.
Assume you have an audience larger than the people you directly interact with. There will be people who take note of what's being said in your chat, and mailing list archives are an extremely undervalued knowledge source, but they're only helpful if information is actually recorded there. Meaning: you actually have to keep the conversation in the open.
Resist the urge to try to "reduce noise" in a public channel by answering questions in private. "Let me DM you." is an anti-pattern that prohibits learning by lurking.
Use private channels sparingly, as they tend to create and reinforce "us" vs "them" boundaries and limit information sharing. Your team's random off-topic banter helps make you more approachable, shows others how you work, and often surfaces valuable documentation and links.
Follow up on unanswered questions, including your own. If you posted a question and later find out the answer, share it. Never hesitate to ask your question in the first place: as a senior person, this shows your team mates that you don't have all the answers either and that your group welcomes questions; as a junior person, this is the fastest way to unblock yourself. What's more, if you have this question, chances are several other people would like to find out the answer, too.
Take note of frequently asked questions and add them to your documentation. Even not so frequently asked questions should be documented, especially if they cover obscure edge cases.
Explain the obvious. It may not be quite so obvious to everybody, and in the process you may accidentally rubber duck debug a flawed process.
Should a question lead to the discovery of a bug or missed feature, capture the information in a ticket. In there, reproduce the issue, add the participants from the discussion as watchers, add a link to the chat or mailing list archives, and then cross-reference the ticket in the discussion. This helps lurkers discover answers and provides valuable context to developers working on the issue.
As you develop new products, service, guidelines, or whatever else your outputs are, share early, and share work in progress. Don't wait until every "i" is dotted and every "t" crossed; seek early feedback, and you will catch problems early. At the same time, you will begin to seed in your lurkers' primary communities what you are planning, allowing them to adapt.
Async Reigns Supreme
Supporting lurkers favors asynchronous communications, as they are by definition more passive than other participants. That means they may read your mailing list posts in digest mode, or only once a day, not immediately as every mail comes in. Lurkers in chat rooms may hang back and scroll through the discussion periodically, not context switch into every exchange of messages.
Asynchronous communication tends to: reduce information silos, because you don't have to "be there" or miss out; minimize rushed decisions, because people have time to think before they type; enable more easily a one-to-many information flow, thereby facilitating and maximizing knowledge sharing.
That's right: what's good for the lurkers is also good for everybody else. Just like all the great practices that enable remote work also made things better for anybody working in an office (if you remember what that was like and can believe that so many people just put up with that for so long), so does favoring transparency and following up on questions in the open improve all your team dynamics.
Developing ways to actively support and not just tolerate lurkers will also improve your basic onboarding process for new hires, can facilitate cross-team communications, open up your community to outsiders, attract more diverse people to join, and help keep you honest and your documentation up to date.
In the end, all you have to do is stick to two simple rules: "Be transparent." and "Keep discussions in public channels." And just like that, you'll enable the wonderful art of Learning by Lurking.
April 1st, 2022