There are some people who really enjoy the Maintainer role, and will not enjoy being on a Creator team, and vice versa. It's always important to know which you are, so you don't find yourself going crazy or facing a skills mismatch.

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%.

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?

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.

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.

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.