Comment by simonw
9 days ago
A previous employer hit the problem where there were a ton of legacy features that didn't have clear owners and so it wasn't clear where to route bug reports.
Their solution was to build a catalog of every feature and then assign EVERY one of them to an existing team.
Teams might end up responsible for features that they had never seen before and had no knowledge of... but that was fine, because every other team was in the same situation.
It worked great. Bugs got fixed. Teams figured it out.
I've often seen something similar happen in places with high turnover.
Team owner leaves or is let go and then their projects get randomly assigned to other people.
That's not terrible. What is terrible is when there is no mechanism for swapping or trading projects.
The truth is that accountability isn't the problem, its the lack of resources, prioritization, and ability to change things that make them burdensome. After a certain point you're just trying to solve the problem in the least annoying way possible.
It’s like the bystander effect but for code, lol.
Just pick someone and give them the task.
On complex codebases, I've seen this strategy absolutely decimate team moral.
A large tech company decided to stop having subteams responsible for particular features or areas of the code for one of their products. The result was developers having to spend inordinate amounts of time researching highly complex spec documents and reference manuals on a daily basis for even the smallest of fixes. It drove moral into the ground and developers started a mass exodus to other teams or tech companies.
After some changes of management for the team, the policy had to be reversed to stem the bleeding. Turns out that developers don't like permanently being in unfamiliar territory.
One thing I've learned from responding to emergencies is that you can't just yell "help" at a crowd, you have to pick out someone specific and say "You, dial 911."
We had someone collapse on campus and have a seizure. An entire group of people stood around this person as they wet themselves, nobody doing anything but watching. I picked out specific people from the group to help, told them what to do, and told everyone else to back away. There was even some guy who got pissed at me for telling him to leave the area, but he's exactly the kind of person you want out of the way.
Lesson here, be specific, be aggressive, and take charge when it's needed, because it's very unlikely that a bystander will do anything but watch.
I haven't had to do first aid training in while, but even the first time I had to as a teenager working in camps almost 20 years ago, this was a thing they drilled in our heads.
This is a top-down incentive problem. If teams are rewarded for making things work, fixing problems, and keeping the lights on they'll pick up ownership of orphaned projects.
If they're only rewarded for feature delivery then they won't, and they'll push back on being given any non-feature work like maintaining things.
Git blame -> graph of all employees , route from ex employees to successor or departmenthead
Just make sure you retain the org tree history.
I don't know how I feel about this. Ingenious perhaps. But then again, being assigned some absolute slop riddled with tech debt arbitrarily could be particularly cruel.
[dead]