What's Good for the JR is Good for the SR

I’ve often found that it’s a good idea to share diagrams and documentation widely. I try my best to share whenever I create documentation. That said the team gets busy, and sometimes it feels like I’m adding noise to the team chat if I share out absolutely everything. This has led to me being more selective over time. I recently had a reminder that I should be sharing things more broadly.

I was working with my team’s JR engineer. I first went over the Model View Controller architecture that is often used in ASP.NET. I then extended the diagram that I was drawing in Obsidian to be more specific about LoopNet’s web architecture. This ended up breaking down quite a bit of what the JR needed to get his story done.

Since it was a diagram that started primarily to explain the MVC pattern, I didn’t think many members of my team would find it that useful. I didn’t share this out in our chat on Teams. It turns out that I was mistaken.

My team often has quick review sessions. During these short meetings we spend some time gathered together to discuss the technical design of the work we’re about to take on, and we use it as a time to baton pass to QA. The JR started presenting how he was going to take on the story we discussed and showed the diagram I had drawn for him.

That led one of our SR engineers to have an epiphany. He had been having trouble determining where he needed to plug in an event he was implementing for the LoopNet search result page. Once he saw the diagram, he instantly recognized where he need to plug in his new event logging code.

Had I shared the diagram in our team chat when I made it, I might have saved one of the engineers on my team some fruitless searching. I think it goes to show how disseminating information broadly can be advantageous, and that you shouldn’t just assume that a diagram designed for a JR engineer will have nothing for the SR engineers.

I recently posted something along these lines to LinkedIn, and was asked how to facilitate these kind of discussions. I suppose I have a little bit of advice:

1. Have a private chat that has every direct team member. This can be a great place for directly conversing about issues, posting documentation, and announcing work that is interjected into your teams work stream.
2. Have a open channel for the team that others outside of the team can access to get a hold of the team. This can also be a great place for more regular information sharing. My team for example posts all of our PRs to our public facing channel so that people who interface with us can see the work we’re doing as we’re doing it.
3. Beyond having documentation for features, have an area of the wiki that provides structured notes for the team. For example we have a wiki page that provides a list of deliverables for each sprint to track what we’re releasing.