3 ms·
I think your statement may be a bit broad here. Let’s say upper management considers they need both feature A and B to win the market by end of quarter. But su
by solalf 4y ago
I think your statement may be a bit broad here.
Let’s say upper management considers they need both feature A and B to win the market by end of quarter.
But suddenly your team is half the number of people it used to be. You’re not realistically going to achieve more than you used to just through sheer elasticity.
So either A or B will get done and it becomes a matter of prioritization.
Smaller companies and shops are nimble because they don’t have the burden of the past, red tape and standards that exist at scale.
For engineering orgs the size of Snap’s things take longer and having more people very often does solve the velocity problem.
- NeverFade 4y agoRealistic outcome: management tells the team they still need to achieve the same work with half the people through heroism. The remaining members notice they're expected to do twice the work under a lot more stress, in a workplace that suffers the typical post-layoff low morale, and they quit themselves. Feature B doesn't get done, feature A gets rolled out by a bunch of enthused fresh grads and is buggy and unstable.
- dasil003 4y ago> For engineering orgs the size of Snap’s things take longer and having more people very often does solve the velocity problem Your comment is totally fair. I will say though, that the impact of having more people is a function of how independently they can be deployed. One of the biggest challenges for hypergrowth companies is how to decouple things as they scale to keep people productive without drowning the org in communication overhead. Brooks' Law looms large in single product companies when they start to hit 4-figure engineering team sizes.