This content originally appeared on DEV Community and was authored by BekahHW
Back in 2020, when the pandemic hit, I lost my first tech job. It was the same day I picked up my kids’ books from school, expecting a three-week break. They never returned that year. Somehow, I found myself interviewing for a DevOps position - at the time I didn’t even know what DevOps was. After the first interview, the interviewer told me to read The Phoenix Project and then she’d give me a second interview.
In the book, Brent is the go-to Ops Engineer, the one with all the answers, putting out fires, and saving the day. The problem? Brent is a bottleneck, not a multiplier.
The Hidden Cost of Siloed Knowledge
When knowledge is siloed, we put our teams at risk. What happens to your team when someone goes on vacation? Needs to take some time off? Or even worse, leaves the company? The impact can be stifling and even paralyzing. The hidden cost of siloed knowledge can lead to a phenomenon known as "knowledge hoarding," where team members, whether intentionally or not, become protective of their expertise and don’t share it with others. More costs of siloed knowledge include:
- Single Points of Failure: Key expertise is held by a few, creating dependency.
- Redundant Efforts: Without shared knowledge, teams may unknowingly duplicate work.
- Slow Onboarding: New team members struggle to piece together fragmented information.
If expertise is spread throughout your team and you don’t rely on any single person, you improve your team’s stability and to achieve success. The cost of siloed knowledge is a lot steeper than we realize.
Siloed knowledge leads to optimizing locally, but sub-optimizing globally. What does that mean? It means that teams start to become hyper-efficient in their own bubbles, but the organization as a whole starts to suffer. You’ll see your top engineers reinventing the wheel in different corners of the company, doing redundant work in isolation. And when you bring new people onto the team, there’s no clear path for knowledge sharing with slow onboarding as they try to put together fragmented knowledge. This isn’t a minor inconvenience - you pay for this in time, morale, and missed opportunities.
In the context of developer culture, this problem can be particularly damaging, leading to inconsistent practices across teams and impeding the development of a cohesive engineering culture. Developers thrive when information flows freely, collaboration is valued, and when everyone has access to the knowledge they need to exceed. Even within small, agile teams like the ‘two-pizza teams’ popularized by Amazon (teams small enough to be fed by two pizzas), knowledge silos can form if deliberate steps aren’t taken to encourage sharing.
Shared Ownership: not about blame, about empowerment
I know some people start to get nervous when we talk about shared ownership. You might think this means shifting blame around when things go wrong. But that’s missing the point. It’s not about pointing fingers. It’s about embracing a team responsibility to contribute, learn, and grow. It’s about creating an environment where everyone feels responsible for the success of the project, not just their own tasks.
When we embrace shared ownership, we’re acknowledging that everyone’s insights and ideas matter and that they have the power to make an impact on the project.
In a two-pizza team structure, shared ownership isn't just beneficial—it’s necessary. Small teams are designed to be autonomous, fast-moving, and highly collaborative. When everyone on the team has a comprehensive understanding of the project, everyone can make better decisions, avoid duplicating efforts, and maintain high standards across all parts of development. This type of collaboration requires a culture where expertise is shared openly and where the success of the team is prioritized over the individual.
The CODEOWNERS File: A Tool for Knowledge Sharing
This is where a CODEOWNERS file can help teams get started. If you know what a CODEOWNERS file is, you might think of it as a way to assign responsibility for review of a particular codebase on GitHub. But I think a better way to think about it is as a map of expertise - a file that outlines the go-to people for different parts of the codebase.
I want to take a minute to flip the idea that it’s restricting access or creating gatekeepers, and ask you to think of it as a way to highlight expertise and encourage collaboration. When the pull request comes in, the right people get notified automatically. This also means that when someone has a question, they know exactly who to reach out to.
As part of this, it’s important to remember that a CODEOWNERS file isn’t meant to be a static document. It should change as your team grows and as people develop new areas of expertise. Think of it as a living document representing your team’s collective knowledge.
Building a Culture of Shared Knowledge and Learning
Don’t get me wrong: a codeowners file won’t solve all your problems. It’s a tool, and like any tool, its effectiveness depends on how you use it. The real goal should be to build a culture of shared knowledge and continuous learning.
Let’s shift our mindset from a culture of ownership to a culture of expertise.
Ownership implies exclusivity. “This is my code, my project, my responsibility.” This mentality can create barriers and discourage collaboration.
Expertise, on the other hand, is something to be shared and celebrated. Focusing on expertise encourages the mindset of having a deep knowledge and a willingness to help others understand it as well.
When we build a culture of expertise, we also shift the value, not from how indispensable you are, but how much you elevate the whole team. You’re not a code “guardian.” You’re a multiplier. And we all want multipliers on our teams and in our organizations.
The OpenSauced Solution: pizza-cli codeowners
So what can you do today? At OpenSauced, we’ve developed a codeowners command for our pizza-cli to do the heavy lifting of analyzing your git history, generating a CODEOWNERS file, and keeping it up to date automatically. This means you don’t have to guess who to contact if you have a question about a particular file. (I talk more about this in The Problem of Knowledge Debt in Tech.)
For each file in your codebase, the pizza-cli + GitHub Action assigns up to three “owners.” Why three? Three creates a balance between clear accountability and shared knowledge by not limiting to a single owner. At the same time, you're also not diluting responsibility across too many people.
Remember, this isn’t about creating boundaries or “exclusive” territories. It’s about surfacing expertise within your team, starting conversations, and learning from each other.
Start Small, Think Big
Head over to the pizza-cli and give it a try. You can start small-test it with a single project or team and start the conversation about code ownership and expertise.
Tools like the pizza-cli are just the beginning. The goal is a knowledge-rich developer culture where everyone thrives.
Tools like the pizza-cli can be helping in making sure that no one person becomes a bottleneck.
Creating a developer culture of shared knowledge and continuous learning is an ongoing process, but it’s worth the investment. Let’s build teams that elevate each other, embrace expertise, and grow together.
This content originally appeared on DEV Community and was authored by BekahHW
BekahHW | Sciencx (2024-09-24T16:36:48+00:00) Building a culture of shared ownership. Retrieved from https://www.scien.cx/2024/09/24/building-a-culture-of-shared-ownership/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.