Just-in-time knowlege sharing

In one of the previous blogs, we discussed the idea of a synchronous and non-blocking way for a code review. We pointed out knowledge sharing as an example of such a review model.

Now, we would like to elaborate on that one a little more.

How

In short words, Just-in-time (JIT) sessions are similar to meeting with your colleagues in front of a laptop and trying to introduce them to the work you have been working on lately. JIT sessions we do are almost always virtual. We started JIT sessions during the pandemic, and since then, the format has not changed thanks to its simplicity. The single session is up to 30 minutes long. The presenter is in control of who the session is for, what knowledge the attendees should have to gain the most out of the session, and the form (code sharing, brainstorming, Q&A, whiteboard drawings, etc.).

Why

When we kicked off the JITs for the first time, our motivation was very straightforward - we wanted to share our small findings that we usually talked about in the kitchen or hallway and get some feedback. We were looking for an informal meeting that does not require spending much time on preparations (in opposition to other virtual formats we had established at that moment).

In time, we found many more benefits and explored more applications of this format:

• Short sessions are an alternative to more formal knowledge-sharing sessions.
• The simple form encourages more developers to share and tell what things they do on a daily basis.
• JIT meetings have proven to be helpful tool for gathering feedback early on your ideas.

Now, we would like to share a couple of recommendations for a quick start for the company and for presenters:

Quick-start - presenters

• Time is of the essence. Don't wait for a special moment. Just give it a try. You don't need to prepare much. Talk about what you are currently doing in your project.
  • Depending on the talk type, we prepare between 5-60 min. If this is a live coding session, 5 minutes is enough to have an agenda for things you want to show (it is usually good to have a note on the side to keep in timing). With ideas or summaries, when some graphics are required, we spend a bit more time (but never more than 1h).
• Start small, e.g., just in your team. When you are ready, try your department or company meetings. A good time would be a 15-20 min slot right after your daily. Demo a solution you were working at to your team.
• Make it natural and bring the tools you are used to work with. Do not spend much time on preparations. Treat this meeting as you would if you were to introduce your colleague to the project.
• Don't bring PowerPoint presentations (we even forbid it at the beginning to distinguish this session from other more formal meetings).
• Instead, prepare your IDE (make sure font will be visible to others), notes (e.g., in Markdown format), or some whiteboard tool (Miro works quite well).
• Make it clear what knowledge is needed to benefit from the meeting and to whom you are addressing your speech. You may use hashtags like #docker-basics, #operational-bash, or #advanced-ReactJS.
• Remember that as the presenter, you also want to benefit from the meeting. You share your knowledge, but in return, you want to get feedback and questions that will help you improve your idea.
• Try to leave some space for discussion. We usually try to fit in 15 min to leave the place for conversation and questions (which sometimes leads to 1h+ meetings and vivid discussions, which help to build even better solutions).
• Coupe of examples for a JIT:
  • Just before starting some small project (e.g., tool/library that will help your project to do XYZ). Gather your idea, prepare a few points on what you want to achieve and what problems you want to solve.
  • When you researched a new technology/library/framework. Share your insights and findings. Give the context of your project/problem you are looking for a solution for.
  • After something went wrong or unexpected. Try to prepare some conclusions.

Quick-start - company

• Start with a constant time window (e.g., every Tuesday at 14:00).
• Do not let queue talks. Some simple (but not too many!) rules, like no slot reservation, are okay.
• Create a dedicated channel (or use an existing one) for announcing the topic the morning or day before the session. The first one wins. If you find there are more people who want to present, create more slots.
• Generally, one slot = one talk. Do not stack. Many JITs end up with a discussion (the prize for the presenter - they get questions and feedback there).
• If you have other, more formal knowledge-sharing sessions, do not let PowerPoint presentations. Simple drawings, an IDE, a console, and a whiteboard are all what presenters need.
• Recordings - this is a tricky one. As far as we observed, it is a controversial area. On the one hand, recording allows people who were unable to attend the meeting to watch the recording at any time and ask questions. On the other hand, we have observed that the recording function prevents many people from asking questions and participating in the discussion.
• Generally, we do not recommend imposing the form of the meeting. Let the presenters decide which format they feel most comfortable with. A good balance could be recording sessions and taking questions/feedback after recording has stopped. Another way is to leave notes and key takeaways in some common source like Confluence or GitHub repo README.
• Do not kid yourself. This format, like many others, must have several precursors to be successful. Help them organise meetings and encourage people to participate. If it succeeds, it will be like a good YT video - it will start getting thumbs-up on its own.

TL;DR

Just-in-time (JIT) knowledge-sharing sessions are low-effort meetings that are easy to adopt in the team or companywide. The essence is to share your recent (even daily) work or findings with a wider group of engineers. Don't bring any presentation. Most of the sessions are live screen sharing. There is also an additional prize for the presenters - discussion, feedback, and questions that might use the company's brainpower to create better solutions.