Shared Responsibility: Teamwork!

I'm kinda hurting here, looking to know that I'm not alone in this...

Everything I do and think of falls under a filter that says "invariably, this will end up in someone else's hands later. Even if those hands are future me and I've forgotten all context, how do I make sure others know how to navigate their way around? Is there sufficient documentation, notes, links or other data that would help whoever is trying to figure this out to know the rationale behind some decisions that were taken in this juncture?"

I lead by example. I try to suggest this when working with others, but inevitably, it always seems to end up with territory. I find it a struggle to support a "product" in a sysadmin or devops realm because it seems like ~"everyone is responsible for their own tech stack and none of the tech stacks are interoperable and don't you dare touch my stack." Then people get typecasted into certain roles and they are just expected to fulfill that role for life. Your performance as a whole is comparative to how well do you adhere to a multi-step process intended for multi-teams of people but you're a team of 1 performing like a full blown managed service.

I don't agree to this because my role is always changing and I am always trying to evolve to become better. I don't aspire to be the guy that pulls the overengineered lever when you ask me to because that's my job. I'm going to eventually build a bot to do that for me and I'm going to go find something else to automate. I'm also going to work on and lean into my team members when part of a team. I hope they do the same because I would support them all the same, regardless if I like or dislike, agree or disagree with them.

I just wanted to make this in an expression against my frustrations over this idea of "code as territory" as I'm going to call it. It appears in an environment where someone becomes responsible for supporting a tool or product they created and are the only one supporting that software. I don't like it because it's a single point of failure in the business and operations. As such, I combat this with documentation or at least breadcrumbs so that someone wtih a similar level of context into the problem and solution space and the tools used to achieve the desired outcome can enter into any line of work I do and pickup where I left off.

I aim to be a team player. That means when I need code to be reviewed, I submit the pull request with details on what needs to be reviewed. If someone needs code reviewed, I step up and review with them and try to provide the most helpful advice I can give. I know some people take this as their opportunity to take out their frustrations out in the review process, but I just disagree with that perspective. I've learned so much and caught so many issues in the review process. Often times requirements weren't communicated or interpreted correctly. All of this can be mitigated with a peer review.

If you've overcome this challenge of "code as territory" at your organization, how did you get past it? Drop a comment below on what tips I and others can follow on how to escape this kind of environment?