As consultants, we sometimes get a front-row seat to evaluating who sits on the team, if they are sitting in the right seat on the bus to move their organization forward, and if they are the type of member we would want on the team.
Everyone wants to build teams characterized by collaboration, positive contributions, and an iron-sharpening-iron mentality where no single team member is above the constructive criticism of another. This set of principles driving the team remains at the forefront, regardless of the level of seniority.
That's an idealistic viewpoint - the goal, certainly, but many teams do fall short.
On many teams, the reality is, "That's my code; I wrote it, and I don't want other people breaking it." This happens particularly often when a team member over-identifies with some part of the code, a particular tool, a data pipeline, or other aspects of the project. This attitude is evidence of a more toxic code/process/data possession that will not allow the team to move forward.
To address toxic code ownership, team leaders should evaluate and address the environment, facilitate team communication, use well-designed test suites, and implement regular code reviews.
Evaluate the Environment
When that attitude appears, we shouldn't instantly think it’s the problem. Before coming to that conclusion, we need to more holistically evaluate the team, the process, and the code - in other words, the environment.
All things being equal, it's good to hold people to a high standard of character. But if the environment is such that much of the development process is consumed by putting out the various fires that pop up daily, I can understand coming in with a more defensive posture.
When time is already spoken for daily, from the developer's point of view, no time is available to fix problems in established code. Hence, woe be to those who would muck about and potentially introduce problems that the harried developer, as the primary dev for that code, would be responsible for fixing. Touching the code is perceived as a threat.
Some people may bring this attitude even in a more constructive setting. In my experience, the environment can press people in this direction. The wildcard is really what happens when the environment changes. Do they get stuck there? Or can they learn to trust some surrounding changes and lean into a new team dynamic?
How to Eliminate Toxic Code Possession
As a team lead, what can you do to incrementally improve a team toward eliminating toxic code possession? I'd like to focus on three action points:
- Communication
- Test suites
- Regular code reviews
Competence and Communication
Competence should speak for itself, but many development teams don't emphasize communication during hiring. In teams where I have seen toxic possession, the communication factor is missing, and there is most often a single point of failure.
I'm not necessarily talking about soft skills here - really, it's about the developer's ability to efficiently communicate pertinent parts of the code. Can I, as the senior dev, provide a junior dev with some Cliffs Notes on the code's operation?
As that skill pervades the team makeup, there needs to be a place for sharing this kind of information. Sometimes sharing happens during new employee onboarding, but it really should continue past that stage.
How can your team handle the bus factor? What happens if a particular team member gets hit by a bus and is unavailable for an extended period? The team must have enough built-in redundancy to continue.
Building that redundancy is every team member’s job. Toxic code ownership loses its power when more members of the team know how that code/process works.
Test Suites
Teams that exhibit toxic possession have either non-existent or unhelpful test suites that don’t test the right outcomes. When applied consistently and rigorously, test suites are a strong antidote to toxic code possession.
Remember the threat the developer feels when new people come in and mess with the code? Now introduce a well-engineered test suite. If the code breaks, the tests should break and give developers a good idea of where the problem is.
A developer’s fundamental concern walking into a new project is that they don't know what they don't know. The test suite fixes that concern and reduces the likelihood that a problem sneaks through.
Code Reviews
Finally, code reviews are a place to put these concepts together.
When changes are open to review from the rest of the team, there are no "secret sauce" code changes - everybody gets to not only see changes, but discuss them, ask questions, and have general input. Pull requests are a great place to review the tests, make sure the needed new tests are present, and that the team is building that redundancy.
Toxic Possession to Constructive Collaboration
Moving a team from an environment of toxic possession to a more constructive posture takes time and consistent effort. It's worth it, though. Creating an environment where everyone can relax and lean into their strengths will yield healthy pride and satisfaction.