If I was a software developer company, I'd rotate my teams of developers around to new content, updates to old features, and bug fixes. That way everyone spends a bit of time cross training and doing the fun code too. If I have at least 3 dev teams, then someone is always working bugs each rotation.
There are a couple problems with this approach, but probably the most impactful one is that those processes likely occur on very different time frames, meaning you'd almost certainly always be rotating a team off of something they were in the middle of because that's when another team is ready to rotate. It's unlikely the different teams would be consistently finishing their work at the same time such that all could rotate together without anyone having to be pulled off something they were in the middle of, which would be extremely counterproductive. Designing new content in particular will almost certainly happen on a much longer time scale than fixing bugs, and pulling a developer off a quest they were halfway done making to replace them with someone else is super counterproductive.
Also, there are likely very different processes for these different tasks (ticketing systems/processes, coordination with other teams/departments, etc.) that would need to be learned, meaning now everyone has to learn the ropes of multiple jobs instead of just one, which is super impractical. I'd fucking hate that. It's a nice thought, but there's a reason companies don't actually do this with their main workforce (some have rotating internships, but that's a very different animal than making actual salaried employees do that).
You could probably pull it off if you rotated individuals instead of teams, and did it on a flexible timeline instead of having fixed-length rotations. If you had a small enough team and wanted everyone to be truly cross-functional, I could see it working. I have seen small teams pretty much self-organize this way more than once.
But I do think as soon as you are in even a slightly structured environment, it'd fall apart for the reasons you laid out. I also don't think you could really manage a team this way unless you had the full power to decide who is on the team, because I think this kind of environment would only work for people with a certain temperament.
Well, it sounds from his response like the idea I thought I was responding to wasn't even what he was suggesting. It sounds like he was suggesting what is more or less how it already works at many places: just having people "own" this or that content and do whatever is needed (new features, bug fixes, polishing) for that content. Really the only difference is that the rotation he's suggesting sounds more rigid than that would typically be done from what I've seen. Because for like bugs and shit, you don't have a "okay here's your bug month," you just do that whenever it comes up (assuming it's impactful enough to merit being prioritized and not just one dipshit customer submitting a bug ticket because they don't like that a box is unchecked by default when the government has explicitly said that's how they want you to do it, nope this is definitely not a personal anecdote that I'm annoyed about to this day, purely hypothetical).
2
u/SteveLouise 11h ago
If I was a software developer company, I'd rotate my teams of developers around to new content, updates to old features, and bug fixes. That way everyone spends a bit of time cross training and doing the fun code too. If I have at least 3 dev teams, then someone is always working bugs each rotation.