Stay A While And Listen

When a team is small and they spend every day working together, it's easy for them to keep up with all of the various things that are happening. It doesn't matter whether it's changes to the domain, the underlying code that implements it or the processes that the team is following, it's all pretty easy to keep track of.

Small teams tend to become bigger teams though, with bigger dreams and more responsibilities, and when that happens all that delicious common knowledge tends to fragment.

But it doesn't have to.

Before Venturing Deeper Into The Labyrinth

Sometimes the problems that come about as a result of this lack of consensual reality are obvious and easy to see, like when two key teams that are involved in the rollout of a feature have a completely different understanding of what that process will look like or what the feature actually is.

However, sometimes the problems are more subtle and corruptive, like friction between different teams or even within the same team because of a different perception of the situation, inefficiencies in delivery as a result of duplication of work or even misunderstandings that lead to fundamentally incompatible solutions.

Working remotely, for all of the awesome benefits that it provides, exacerbates the problem because there is very little casual knowledge sharing and alignment.

That's not to say that the problem doesn't exist when everyone is sharing the same general physical location, it's just easier to avoid it without having to actually spend effort to do so.

So, it is important for everyone who is working in a similar area, or working on a similar thing, to have a solid shared understanding of what is happening, what is changing and why.

And I have at least one thing that can help with that.

Get People To Tell You What They Can

Regular knowledge sharing sessions.

Yeah, I know, not exactly rocket science.

There are a hundred different ways that you can run a knowledge sharing sessions, from a series of formal demonstrations or presentations all the way through to a focused dissection of a specific topic (i.e. a brown bag or lunch and learn).

Those sorts of sessions require preparation though and can be a bit onerous, especially to the people presenting who are often engineers who really don't want to present.

So, we've been doing something a little bit different.

We call it the Open Forum.

The idea is simple enough, a weekly chunk of time that everyone agrees to use for the purposes of knowledge sharing. For us, it's a thirty-minute period every Friday afternoon, right before we pivot into doing something social.

Throughout the week people add things into the agenda and then during the session they share their screen over Zoom and just...talk about the thing for a few minutes.

No preparation necessary or expected, though, in fairness, sometimes people do do a bit of preparation to get their thoughts together, and it's not unusual for an Open Forum topic to either have come from an internal blog post, or to pivot into one later.

The best part is that the topics themselves are so fluid and diverse.

It doesn't matter if the presenter is showing off a new feature that their team just delivered, sharing a design for some upcoming work or sharing some new personal productivity enhancement that they've started using, the Open Forum accepts all contributions.

There are some things to be careful of though.

There Are Unspeakable Horrors

The first thing to be careful about is to not turn the Open Forum into a big song and dance that requires a bunch of preparatory effort to even think about participating.

The whole point is that it's a lightweight yet structured way to share information and context. The moment you make that harder, you're going to lose a bunch of people who would otherwise be more than happy to share their delicious knowledge.

You can still have other demos that require more presentation, just don't conflate the two things and try to kill two birds with one stone, or you'll just end up killing a bunch of birds for no reason.

That doesn't mean that you should let people ramble incoherently though. Make sure you're making the most of the time you have available, or the attendees will get bored and stop attending, even if the content is technically useful.

The second thing to know is that even a casual knowledge sharing session like the Open Forum requires a facilitator.

That means that someone needs to be keeping an eye on the agenda ahead of time, drumming up interest, running the actual session and then maybe keeping a record somewhere so that people who missed out can absorb the information at a later date.

Eventually the Open Forum might become self-sustaining, with it being an integral part of the team culture, but that's probably going to take a while, if it even happens at all.

That's about it though, keep it light and easy and make sure a human is responsible for it happening and you're pretty much golden.

But They Can Be Conquered...For A Price

We've been running Open Forums weekly for over a year now and they've been pretty awesome, especially as the team has grown from a handful of engineers to a sizable group spread across four different domains.

From a purely selfish perspective, the consistent presence of the Open Forum has helped me to stay connected with things as I transition away from being an Engineering Manager.

It's more than that though.

Not only do the members of the team know more about what is going on, but we've even managed to attract some extended stakeholders as well, who rock up, absorb a bit of knowledge and generally connect with the people on the front lines.

And more context and connection never hurt anyone.