3 ms·

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need?

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.

sanderjd 7y ago
My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.
- ebiester 7y ago
  I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code. 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.
marcus_holmes 7y ago
Can you stream multiple releases in parallel instead of doing them in series? 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.
- skolsuper 7y ago
  Assuming no slowdown from all the context-switching (a generous assumption), and equal sized features, splitting the team would make the high priority feature take twice as long to deliver.
- ebiester 7y ago
  The best way I've learned to build working software is to have a group working together driving at the delivery of it rather than organizing a series of handoffs. Not only do people have context switching concerns at the task level, but teams and organizations have context switching concerns: more tasks in progress mean more organization thrashing and things drop on the floor.

sanderjd 7y ago

My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.

ebiester 7y ago
I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code. 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.

marcus_holmes 7y ago

Can you stream multiple releases in parallel instead of doing them in series? 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.

skolsuper 7y ago
Assuming no slowdown from all the context-switching (a generous assumption), and equal sized features, splitting the team would make the high priority feature take twice as long to deliver.
ebiester 7y ago
The best way I've learned to build working software is to have a group working together driving at the delivery of it rather than organizing a series of handoffs. Not only do people have context switching concerns at the task level, but teams and organizations have context switching concerns: more tasks in progress mean more organization thrashing and things drop on the floor.