Good point, I'd like to add another model: "people who want to ship stuff to the customer" vs "people who strive on solving emergencies" vs "people who love to create internal tools"

I.e. the first group wants a feature request and ship it fast in a package (or maybe in small steps, doesn't matter), the second group doesn't really "ship", they are reactive problem solvers - sometimes sniffing out the weirdest edge cases on a whim. And group three prefers to write the first 80% of a solution, like an MVP, improve their coworkers' happiness, but aren't so good at following through to polish the last 20%.

I agree.

Current trends in software ("agile" in particular), seem to push against allowing this kind of distinction to develop, and give negative connotations to maintaining code developed by another team ("thrown over the wall" seems to be the preferred expression).

Any thoughts on how to structure things so that maintainers and creators can both focus on their strengths without too much tension?

Finding the right balance usually requires, unfortunately, a very mature company with a policy of keeping talent happy and a strong R&D department (which requires a lot of income to maintain). The creators get to thrive in R&D while the maintainers get to thrive in working on very mature (and usually profitable) codebases.

I say unfortunately, since those companies tend to look like (and are) Oracle, IBM, Microsoft, etc. Oracle, in particular, has a policy that you can make any lateral move you want at almost any time; at the cost of pushing out your eligibility for a raise.

This kind of flexibility doesn't exist in most startups; I've personally been turned down for a lateral move within a startup because I "failed" a whiteboard interview. Startups also don't tend to attract the Maintainer personality since they are considered startups because they're creating something new.

I also think they have trouble with easily accepting lateral transfers because there's so much raw talent banging on the doors that it's appealing to bring in outside help on new projects. Especially since a transfer will be viewed as a loss of critical knowledge about the project that just switched into maintenance mode. What's missed is that the person who requested the transfer is probably going to leave anyways because of a the mismatch with their new job role and what they want to do.

Mostly long-term perspective, I think. Sprints (releases, versions, however you call it) are very lucrative, because being short term they offer quick turnout, sense of quick progress (in terms of tickets closed, features delivered) and bring easy to achieve victories, visible in probably every daily team call/meet.

The whole premise of various Agile methodologies (at least as I see it) is building minimal viable solution that solves the problem at hand without investing in bullet proof solution, because requirements may change (not necessarily client requirements. Internal design requirements as well) and that investment may be gone. From management perspective a minimax game to maximise "billable hours", which rarely include bugfixes and do not include maintenance. Though it seems to sweep under the rug the fact that next sprint may be built on top of weak assumptions under that MVS.

Without long term goals a team needs a person who is experienced enough to see problems down the road, caring enough to refactor stuff themselves and capable enough to squeeze deliverable required by ticket and maintenance duties into story point value - rockstar developer, and those tend not to be available in bulk.

I've seen this kind of senior maintenance developer being allowed to flourish only once in my career. In my opinion, the key was project scope. It was complex enough and had been in production long enough so that this maintenance wizard always had a wide range if issues to choose from. He got the reputation of knowing the whole complicated mess by heart, and being able to resolve the problems nobody else could. As a result, the management did not dare move him to new feature development, he got to work on what he liked, did it good, and thus cemented his position more and more.

If the project had been any less of a mess (lucrative, highly lucrative mess), somebody in management would have insisted on "not wasting the talent" and moved him to churning out new features. Because features are always more important, unless the bugs become perfectly capable of sinking the whole project.