When I first heard the word “democratize,” I had no idea what it meant. So, for anyone like me, here’s a definition from a quick Google search:
What does it mean to democratize something?
to make (something) available to all people : to make it possible for all people to understand (something)A few years ago, I took over the reins of a DevOps team as a Technical Lead. I was brand new to the organization and eager to demonstrate my technical prowess—building infrastructure as code, writing continuous integration and continuous deployment (CI/CD) pipelines, and generally proving my worth as a seasoned DevOps Engineer.
After all, I was the Senior Engineer with buckets of experience doing this stuff. But it felt like I was blocked at the first hurdle.
Navigating a New Landscape
Every organization has its own way of working, and stepping into a new one often means facing challenges beyond just technical skills. Understanding the existing workflows, processes, and unwritten rules can be just as critical as writing your first line of code. That’s where I hit my first major obstacle.
The Organizational Process Chasm
Every new role comes with an organizational process chasm you have to cross before becoming fully productive. Some barriers are business-related, like obtaining the correct access rights. Others are technical, such as how a vendor’s documentation says to do something versus how it’s actually done in the organization due to additional controls—throw in a RACI matrix and least privilege models, and suddenly, tasks you’d expect to own as a DevOps engineer belong to another team. So, you submit a request and wait.
I encountered this process chasm quite severely. There was documentation scattered around the organization, but none of it focused on getting the job done in the DevOps space. My new team knew exactly what they were doing. They had all the necessary request tickets bookmarked, reference pipelines at the ready (even if not formally documented), and Terraform scripts they could build upon for the next project.
But none of this knowledge was written down. None of it was shareable in any reasonable fashion. I was fortunate to have a team willing to help—sharing bookmarks, screens, and walking me through everything. “This is the way!” they’d say, like seasoned Mandalorians guiding a lost initiate.
The Hidden Cost of Hoarded Knowledge
While this solved my knowledge gap, it came at a cost: the team’s time. Every time a new joiner arrived, they’d go through the same painful process. And it wasn’t just new team members—people from outside our team would also ask how-to questions about DevOps processes, but the knowledge was effectively locked away.
I’ve known people in my career who thrive on keeping knowledge hidden. Me? Not so much.
The Power of Democratization
I believe democratizing knowledge is how teams thrive. It’s the foundation of a high-performing DevOps culture. When knowledge is available to everyone, gaps are easier to fill when someone is unavailable. When other teams want to replicate what we’ve done, instead of jumping on a lengthy explainer call, we can share documentation and follow up with a shorter discussion if needed.
The benefits go beyond efficiency—the team starts to shine, and relationships across the organization strengthen. And trust me, there’s nothing more important in an organization than building relationships.
Share Knowledge, Not Just Documentation
I use the word knowledge here and try to avoid documentation deliberately. The key differentiation is that documentation did exist, but it was scattered across different websites, making it difficult to navigate. The knowledge we focused on was more about signposting—pointing people in the right direction to achieve their goals.
Rather than duplicating documentation, we aimed to provide guidance based on real-world experience, identifying knowledge gaps and filling them with concise, actionable explanations. The goal was never to create a War and Peace-length guide on something trivial, like choosing a domain name, but rather to offer short, effective insights that actually help people get the job done.
The Ripple Effect
Sharing knowledge has a way of catching on. As I mentioned in my recent blog post, when you openly share knowledge, others start to mirror that behavior. Teams that never contributed before start sharing. People who love to share (but didn’t realize they could) begin contributing. Before you know it, a culture of openness and collaboration takes root.
So, if you want to build a high-performing team, start by making knowledge accessible. It’s not just about making life easier—it’s about making your organization better.
Fun fact
We now have a internal document site based on AntoraDocs. The main URL?
HTGSD.html—or, as we like to call it: How To Get ‘S##t’ Done.
Since implementing this, onboarding has become significantly smoother, and knowledge gaps are easier to address. No more endless request tickets just to find out how to do basic tasks—everything is signposted, shared, and accessible to our team and anyone else in the organisation.
