I have to agree with the other commenters about #1. Adding people adds team overhead, and that is <i>killer</i>. It’s actually fairly surprising how people still think of that as a solution, when there is so much prior art, showing it’s a lot less effective than you’d think <i>(see Brooks, Fred -The Mythical Man-Month)</i>.<p>I encounter people all the time, that are inordinately proud of their infrastructure and process, and how that reduces team overhead, while allowing them to treat engineers like LEGO blocks. I worked for a Japanese company, and they actually make this work (sort of, and at a big price). It requires a fairly massive and inflexible structure (despite being labeled “agile,” it tends to be remarkably rigid).<p>There’s absolutely no substitute for a seasoned, <i>experienced</i> team that has worked together for <i>years</i>, and is secure in its cohesiveness. “Tribal Knowledge” is a dirty word in today’s business culture, but it is, hands down, the most efficient “team glue” in the world. It is also thousands of years old. No high-tech equipment required. Mammoth hunters worked as a team, and achieved big results. Military teams are as old as history, and that is all about commoditizing “tribal knowledge,” and investing in <i>people</i>, not just weapons and tactics.<p>When I read “add slack,” I was like “How does adding a gab tool improve innovation?”. Then I read that it meant adding downtime/flex goal stuff, and totally agree.
"When falling behind, the system fix is to hire more people until the team moves into treading water."<p>I actually disagree with this statement. Teams can be falling behind for a variety of reasons and throwing more people at the problem can often cause further issues especially if the domain / technology / code base / system ..... Is complex.<p>Onboarding people into a team is an incredibly costly exercise, to do it while a team is already struggling will often create a worse problem. You need to be sure that the reason the team is struggling is purely an hour's in the day and not due to other factors.
I really enjoyed An Elegant Puzzle (the book by the author, this article is there). The greatest thing about it is that it is opinionated. For example, it gives you the optimal number of developers in a team. You can disagree with it, but at least you have something concrete to disagree with. So many career advice sources I read discuss things in such a general manner that it's hard to take away anything concrete from them.
It's interesting that all of these points talk about the speed of taking items <i>out</i> of the backlog but not about the speed at which they are added. Any team can be made to fall behind by unrealistic management action.
As I understand it the assumption here that the team is already demonstrating high performance in terms of effort and what causes the team to "fall behind" is the sheer amount of necessary work that exceeds the team capacity. In that case hiring more is the only solution leading to making progress.
What a pile of rubbish. Adding people to a team already falling behind? Specifically new hires? By the time the new people are up to speed, the experienced ones will have finished burning out and left, and the cycle continues.<p>Oh, and a system fix is to <i>add</i> process? That's about as counterintuitive as it gets.<p>Especially disingenuous: "A friend is six months into supporting a sixty person engineering group"...you mean managing. Say what you mean, and don't wrap it in nonsense like that.
You know what the path of high performance teams is? Not growing that fast. The children of Google, Facebook, and other Giants dispersed across the lands, begetting many an offspring, who worshipped their lord, Complexity, solving problems they don't have.<p>Don't solve problems you don't have. Most companies think they need microservices, for example. It is an <i>extremely</i> expensive proposition. Debugging anything becomes a nightmare and developer ergonomics are shot to hell. There is a reason why we stayed away from distributed services in the past. What, you think I could not have stitched together 20 different Python services on my machine in 2009 and put my productivity into paralysis? Don't fool yourself about things like Docker making things easier. It doesn't help people <i>reason</i> about distributed systems.<p>Instagram? Monolith. 12 people when sold to Facebook.<p>WhatsApp? Monolith. 32 people when sold to Facebook.<p>StackOverflow. Monolith, with a lite SQL ORM for highly optimized queries.<p>Look at that - all those things we did in 2004, still work like a charm. But heyo, go ahead and spend a few months learning Kubernetes while the lean companies laugh at you in the rear-view mirror.