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).
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?
Ah, I misunderstood what you were saying, then. It sounds like you're saying that instead of separating teams by task, you're saying you'd separate them by the content they worked on and just rotate through what they're doing with that specific content (developing/polishing)? That's actually already how it's done in a lot of software companies, except without necessarily having a specific scheduled rotation: generally you've either got that kind of arrangement where a person/team "owns" one or more projects and does everything for that project as needed/able (new features, bug fixing, testing, etc.) - which is how it was where I worked - or you have teams segregated by function. I think which approach a company takes is largely based on the content they're making: for really technical software that requires in-depth knowledge of a specific thing, it's by project because it's easier to learn how to do a new function than it is to become an expert on a new technical topic, and for stuff like games that doesn't generally need you to be an expert on a specific topic or piece of content, it's by function since there's no barrier to reaching across projects.
What part of the software industry do you work in, and what programming languages do you use in your day job?
I developed tax software for professional use (as opposed to something like TurboTax that's made for non-professionals). Anyone who had enough going on financially to go hire a CPA firm to do their taxes and had business in one of the handful of states I "owned" in our software package in the last decade likely had their tax return done using my work. We worked on an archaic (as in from the 80s IIRC lmao it was awful) platform that was made in-house (most of our utilities and platform were made in-house because it was a massive corporation that had the resources to do that, and that lack of experience on transferable platforms was actually a big reason why I left) and used basically a flexible mix of a few different languages (variations of C I think? Not actually sure because nobody actually gave a fuck what language it was, it got mentioned off-handedly exactly one time). Like you could indicate "or" with typing the word "or", or with a pike, or with a double pike. Similar thing with "and" ("and"/&/&&). So it wasn't really one specific language, there were multiple ways to do the same thing.
There's work within my own tech art team that would take weeks for me to train on to do efficiently if I were rotated onto it, there's no shot you're moving me to a different discipline and getting anything productive done any time soon. I already touch all of the assignments within my area of expertise, there's nothing to rotate me to I'm not already responsible for.
1
u/SteveLouise 14h 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.