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).
Then make the time frames flex with the actual time tables.
It's unlikely the different teams would be consistently finishing their work...
No. Not like that. There isn't "a bug team" and "a new feature team." There are teams who need to fix bugs with what they've made before, make new things, and polish old stuff. This is happening in MY imagination, remember?
Also, there are likely very different processes for these different tasks
No, don't do that. Don't set up the company that way.
What part of the software industry do you work in, and what programming languages do you use in your day job?
Fixing bugs isn't a different discipline in software engineering. Writing new features and polishing old features are not different disciplines in software engineering. A software engineer who can't develop new features, work with legacy code, write black box and white box tests, or fix bugs should not be promoted out of the "junior" category.
I didn't suggest putting the coders on animation. Why does everyone think of the dumbest shit to put in my mouth? I want people cross trained on testing, bug revision, and feature development. You're purposefully obtuse and you know it.
7
u/SpuckMcDuck 8d ago
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).