Knowledge sharing has always been extremely important for Engineering at GraphAware. Whether it is techniques, tools or technology, lessons learned from our consulting engagements, or experience in general, sharing sparks conversation, creativity and discovery of different or better ways to do things.
In this post, I describe how our knowledge sharing mechanism has evolved and why, and what we do today (and why).
Evolution
When GraphAware had way fewer engineers and we were primarily focused on graph consulting, the need for an organised way to share knowledge was non-existent. It just happened via Slack and informal conversations, powered by curiosity and the excitement of having done or learned something new and wanting to share it.
As we grew, our consultants began to work on various engagements, the volume of messages grew and it was apparent that the informal conversations weren’t enough. However, we wanted to keep the spirit of active participation and collaboration and stay away from solely passive means such as passing around documents.
We started two programs, both organised and run by one person. The first were formal Knowledge Sharing sessions where we would collect topics, schedule an hour or so, and the person presenting would arrive with material and share with the audience- all engineers.
The second format was a Fireside Chat, primarily used to pick the brains of people that had deep experience in certain areas. Our Chief Scientist, Alessandro, was a popular guest. He would explain his application of community detection methods for example, and the audience (still all engineers) would ask questions or show what they’d tried or what they were puzzled about. We’d always emerge from these sessions with a sense of “ah!” and knowing more than we did when we arrived.
However, we continued to grow, and it wasn’t long before we began to work on our own product, Hume, and skills in the engineering team were suddenly more diverse than they’d been before. A good thing, but also now a problem because every knowledge sharing or fireside chat was not relevant to a set of people. Secondly, the one organiser just wasn’t scalable anymore (I know because it was me :-D)
Communities
This initiative was born early last year. The Spotify model sparked a “what if” in my mind and an idea began to develop – self organised groups of people that share common interests. Of course we’re a graph company, so Miro, our resident Graph Specialised Anthropologist, came up with the name “Community” to represent these groups.
A community is a collection of highly engaged individuals that frequently meet to share knowledge around a topic of interest. For example, some communities that are running currently include Kotlin, Java, Web Development, Cloud Native Patterns book club, Accounting & Finance, Hume and the popular long-running Neo4j community.
How they work
Not being the organiser (a.k.a. bottleneck) was important to me. Ensuring that communities are refreshed, relevant and inclusive are equally important. So every quarter, we run a Community Election. Anyone at GraphAware is free to propose a new community, or carry on an existing one.
Every community must have an owner – the owner is responsible for ensuring that the content stays relevant and that all members of the community participate actively i.e. no silent listeners, no “single teacher” mode.
During the election, candidate owners for each community have 30 seconds to pitch, and then an owner is elected – we usually concede to newer members of the team or those that haven’t been owners before. Membership is open to anyone in the company, and within the hour or so, most communities have established their membership. Those with no takers are removed; old communities are sometimes paused and they re-emerge in subsequent quarters, shiny and refreshed.
Thursday is designated Community Day at GraphAware. It has a different “feel” to it as throughout the day, various people in GraphAware convene in various communities. The duration of each community is either 30 or 45 minutes, so the day is quite packed with people hopping from community to community. Communities are typically hands-on, and the topic for the week is chosen usually by the entire community, gently nudged along by the owner. Sometimes, there’s a little prep or homework to be done before the next community. A good example of this is reading a chapter before the next Cloud Native Patterns session.
Outcome
We’re learning and sharing! The decentralised mechanism involves more and more people in roles of responsibility, making choices and taking decisions. Our engineers get to run communities around topics they care about, not having to ask or wait for a central organiser to put together a schedule or a plan.
Community owners develop a variety of skills such as organisation, time and group management, collaboration and communication at various levels. Since members can drop out whenever they feel the community isn’t interesting anymore, it’s on the owner to also gauge interest and adapt accordingly.
Our culture of psychological safety is reinforced as well – one does not have to be the smartest person in the group to step up and run one of the sessions. No question is considered a stupid question, and indeed we always have alternate views provided and actively discussed.
Conclusion
What started off within Engineering a year ago has now caught on and we have an awesome mix of people from all teams. We find accounting, sales and marketing folks in the Hume community and Hume folks in the accounting community, the widest cross-section probably in the insights engine community.
These communities are really the bridges across various functions in GraphAware – they offer a common place and time to meet, share and have some fun. For now, they serve us well, however we don’t rule out further evolution as time goes by!
