Microservices encourage knowledge siloing

My motivation for developing QuickQ, a knowledge sharing platform, is to eliminate knowledge silos within growing teams. One of the most common sources of knowledge siloing is from microservices. I don't oppose microservices - once you're past a certain scale they have their place - but I have noticed they can isolate teams and reduce knowledge sharing. Specifically, I believe the service per team approach is an anti-pattern and leads to an increase of single failure points in your org.

Let's take infrastructure as an example: a common practice as your team grows is to assign a group of engineers to infra/devops and other internal tooling. Typically, services that wrap common developer tasks such as spinning up a new Kubernetes cluster or provisioning a database are deployed. These tools can allow for greater productivity but they can also encourage developers to rely on a less-sophisticated abstraction of an underlying tool instead of connecting their knowledge of the application requirements with the infrastructure that runs it. If your cluster service removes the ability to fine-tune and understand the underlying Kubernetes concepts, then this knowledge has been siloed into a single team that will always be fighting to stay ahead of the next incident.

The flip side of this approach is an organization that empowers developers at every level to dive deep into devops tooling and add functionality to your internal tools as needed by their services. But this only gets you so far: now instead of having a service per team, you're creating a platform per team, with each team contributing to the underlying infrastructure of their platforms but siloed from each other. Without a culture of collaboration your teams will inevitably work as islands, missing opportunity after opportunity to integrate and create a unified application. Instead, common requirements between teams will result in redundant work and wasted time.

Realtime communication tools such as Slack can help with the problem but only if there's a culture of knowledge sharing within the organization. Empower your product and engineering folks to make announcements and ask questions, and importantly, record the answers to these questions in a place that everyone can access. Engineers don't want to feel enclosed by a single service: they want to be empowered to create and contribute at any layer needed to make a beautiful product.

I created QuickQ, a knowledge sharing platform and Slack app, as a way to collect knowledge in the place where it's actually being shared: directly within your communication app. If the barrier to sharing knowledge becomes so low that as soon as a question is answered it gets recorded for future devs to search through and easily find, knowledge silos can be eliminated. It's free forever for up to five users so give it a try.

I don't think an application alone can fix knowledge siloing. It certainly requires a shift in culture and procedure. But so often valuable knowledge gets buried in the firehose that is your communication app. QuickQ can help prevent this and get your org started on the path to creating strong, interconnected engineering teams.