Unstructured Knowledge Sharing

We have a handful of regularly scheduled meetings in place at Artsy devoted to knowledge sharing. But what about the unstructured ways in which we share knowledge? If structured sharing time demonstrates that a team is interested in spreading knowledge, unstructured sharing time demonstrates that spreading knowledge is the default mode for the team. Instead […]

We have a handful of regularly scheduled meetings in place at Artsy devoted to knowledge sharing.

But what about the unstructured ways in which we share knowledge? If structured sharing time demonstrates that a
team is interested in spreading knowledge, unstructured sharing time demonstrates that spreading knowledge is
the default mode for the team. Instead of the team forming habits of working in isolation or hoarding expertise,
they’ve formed habits of learning from and teaching each other.

Regularly scheduled meetings we have for knowledge sharing include:

  • Team-based knowledge share meetings
  • Open office hours for anyone to bring questions
  • Lunch & learns for presenting across all of Artsy engineering
  • Show & tell, where attendees bring recent learnings or explorations to demo to the group
  • Peer learning groups that are dedicated to learning a specific topic in development

As Ash mentioned in his article on knowledge shares, these are all great opportunities
for us to share knowledge. Learning is easy to de-prioritize in the face of shipping features, and scheduling these
meetings reinforces learning as a priority.

Recently Chris Pappas pointed out the incredible value we get out of one specific Slack channel:

This piqued my interest. What unstructured/unscheduled things do we do at Artsy to demonstrate our emphasis on
learning?

The #dev-help Slack Channel

We have many dev-specific channels set up in the Artsy Slack, but one in particular has become a massively
important knowledge-base for the entire team: the #dev-help channel.

This channel is a place for engineers to post when they’re stuck. All engineers watch the #dev-help channel (to
some degree) and offer support when they can. Each issue is threaded to avoid noise in the channel. When the
question is answered, it gets marked as “solved” by applying a ✅ reaction. Pavlos set up a Slack app
that auto-applies the ✅ reaction when someone says “solved” in the thread.

A question asked and answered in our #dev-help slack

The cumulative result of the questions asked and answered in this channel is an incredible knowledge base for all
engineers. When I run into a new issue, the first place I search is #dev-help. More often than not I find my exact
problem already solved.

This knowledge base is so important and powerful that it’s no longer only a place to ask for help. Engineers will
also share problems they’ve already solved in a new thread in the channel, in case someone else runs into the
problem. Usually we’ll tag these problems up front with [already solved] or similar, to make it obvious no one
should spend cycles trying to solve this problem.

An already-solved thread in our #dev-help slack

One other important thing to say about the #dev-help channel: as engineers it’s tempting to solve problems with new
and novel tooling, but in the case of #dev-help we found a way to use our existing tooling in a slightly different
way. Sometimes the best solution is one you already have. We could have investigated dedicated software like Stack
Overflow for Teams, or we could have built our own knowledge-base tool. Instead we put some rules around how we
would use a Slack channel, and gained a huge benefit at a fraction of the cost.

Internal Live-Streaming

Occasionally an Artsy engineer will broadcast that they’re taking on work that is ripe for knowledge-sharing, and
they’ll spin up a Zoom call for others to join. It might be something they know how to solve — like when
Roop spun up a call to walk through how he’d use Observable to explore search index
weighting. There might be more uncertainty to the problem, like when Pavlos started up a call to
investigate a CI build failure using git bisect. It might be somewhere in between, like when
Adam was doing some refactoring of our React Native navigation.

Sometimes this looks like a pairing or mobbing session, but sometimes it looks more like live-streaming. An
engineer is demonstrating by solving a real problem. If audience members can contribute, great — but they are also
welcome to tag along and learn.

Pairing

Yuki wrote on this blog about pair-programming at Artsy. Pairing isn’t an unusual practice
for development teams….but there is something notable in regards to knowledge-sharing.

We’re somewhere in the middle on the pairing frequency spectrum at Artsy. We don’t have dedicated pairs working on
problems together all day/every day. But we also don’t only pair when we’re stuck.

Pairing when you’re stuck is great, and it can help move you forward on a problem. If that’s the only time you
pair, though, you’re missing out on a massive learning opportunity.

Pairing to build a feature gives you exposure to an entire toolbox you might never have used before. How does your
pair approach a problem? How do they manage their time? What development tools do they use? What techniques do they
use for testing and debugging? How do they tighten their feedback loop? This is knowledge-sharing beyond the code
or the product you’re building — it’s knowledge-sharing of tools, skills, and habits.


What are the unstructured/unscheduled ways in which your team shares knowledge? Leave us a note in the comments!

Source: Artsy