Sharing knowledge mob-style
I promised to experiment and share those experiments here, together with the inevitable failures. I must admit I’m struggling to find new experiments each week. My experiments have resulted in several changes in my lifestyle, I need some time to settle into a routine first before I do more experiments in that area. That means my experiments will mostly be at work for now. I just started a new assignment, and usually I start off by observing the current state without changing things. I didn’t see much room to experiment there, except perhaps in the way I observe. However, something came up with one of my new teams that seemed to call for an experiment.
One team member has been digging into an IAM (Identity and Access Management) solution that we need to integrate into our code. He had reached a point where he wanted to shared his knowledge with the rest of the team. Someone suggested that he wrote a document or wiki page. I had a different suggestion.
I know that if I document something that I am knowledgeable about, it is hard to figure out what to put in and what to leave out. I dislike writing down obvious stuff, but what is obvious to me may not be obvious to someone else. The team was already experimenting with pairing, so I came up with a variation for this situation.
Mob-style knowledge sharing and documentation
- Whole team in a meeting room with a large screen and two laptops
- The expert is the Navigator: he explains how to set up and use the IAM solution.
- A volunteer is the Driver: (s)he uses the laptop connected to the large screen and follows the Navigator’s instructions
- Another volunteer is the Scribe: (s)he uses the other laptop, not connected to the large screen, to document the instructions
- The rest of the team listens and asks clarifying questions if needed
- Every 10 minutes or so, we swap roles, except for the Navigator.
I was very pleased with myself. I thought this way we would combine knowledge sharing with creating useful documentation. The expert couldn’t go too fast, else the Driver or Scribe wouldn’t be able to keep up. If his instructions were confusing, it would show up because the Driver wouldn’t know what to do. And the team gets a taste of mobbing at the same time. Perfect!…
Well, that’s what I thought.
First of all I want to give huge credit to the team: they went along with my suggestion. We had a one-hour session to share IAM knowledge. It wasn’t a disaster, because the team made it work. But it certainly didn’t work the way I thought it would.
So, where did I go wrong?
Assumptions. Too many assumptions.
I assumed this was about actively setting up and configuring an environment, maybe some programming, or at least a simulation of calling an API with a tool like Postman or SoapUI. There was only a little bit of that, mostly it was about explaining a data model.
I assumed most engineers would be happy to write documentation on the fly using a laptop. I forgot that it is quite difficult to type fast while listening to something unfamiliar that you first need to figure out and summarize. The Scribe preferred to write on paper; this did not work well for the team and a team member later proposed to do a screen recording — a much better idea!
I assumed the explanation would be fairly linear: install x, configure y, check z. Instead, there were questions that regularly led us off on a tangent. There were a few side discussions which we captured by drawing on a whiteboard.
Let it be
I’ve all too often been in a situation where my beautiful plan didn’t work out the way I expected. I now know: be prepared to throw it all out the window and go with the flow. Because I was open to change, and because the team came up with suggestions, we managed to have a decent knowledge sharing session. We didn’t cover the whole topic, but we did get a good understanding of the parts we covered. We found one aspect that was confusing during the session, so we know that part needs particular attention in our documentation.
What I liked best about this experiment is that I’ve seen my new team speak up and suggest changes to my plan. I love that. The last thing I want is people expecting me to know best and have all the answers. I don’t. I’m never as smart as a whole team together. So, I’m grateful that after just a few days they already dare to challenge my plans. It’s a great place to start our journey together and I’m proud to be a part of this team.