> Further, sometimes the work is unbalanced
My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.
My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.
I have a budget as a manager. I can’t always just hire more.
I think of my teams as "primarily front end" and "primarily API/back end."
Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.
E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to create endpoints, etc, on release B. But the principle holds, still).
It's more efficient to keep everyone working at their fastest, most productive (and enjoyable) tasks whenever possible. But it does take more (and better) management to handle it.