5 ms·

"When falling behind, the system fix is to hire more people until the team moves into treading water." I actually disagree with this statement. Teams can be fa

"When falling behind, the system fix is to hire more people until the team moves into treading water." 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. 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.

bob1029 5y ago
This is the only point in the article I disagreed with as well. My suggestion for the "falling behind" phase would be to buy a few days to allow the team to decompress from whatever shit coaster they are currently riding. Letting people actually unwind can help bring strategic focus and calm back into the fold. Otherwise, this read like a documentary about my current company and product.
- notaclevername 5y ago
  Agreed that this was my biggest disagreement with the article as well. You describe the solution to "falling behind" as giving the team a few days to decompress. I would create that decompression in a different way - by setting and sticking to priorities. Ultimately, if you're falling behind, there's not enough capacity in the system, and so some things won't get done. Better to make that judgment explictly by setting priorities, rather than having it happen ad hoc.
mnahkies 5y ago
Completely agree - augmenting teams with extra people can have the opposite of the desired effect depending on the situation. There's only so much work that can be parallelized efficiently before people start stepping on each others toes. Even if you are able to split things into independently workable chunks, the lack of domain knowledge in a new team member will still often result in a net negative for the first few weeks/months
papito 5y ago
It's like every generation is determined to re-learn the Mythical Man Month - the hard way. You crack it open and boom, there is your anti-pattern right there, called "Brooke's Law".
- theptip 5y ago
  MMM was making a different claim. “Adding people to a project that is late will make the project more late.” This is taking about the best way to minimize growing pains, assuming you want to grow your org. > To spread hiring equally across the teams in need, or to focus hiring on just one or two teams until their needs were fully staffed? That was the question. It’s not claiming that adding people will make the current project ship faster. It’s claiming that focusing hiring people to underperforming teams will eventually buy them the slack they need to start fixing their issues and increase their velocity in the future, and that you get less total disruption by hiring many people into one team than by hiring one person onto many teams.
analyst74 5y ago
I think the unspoken part is the new manager do not have the clout to push back users/stakeholders, both due to being new and the team having already lost trust of its users/stakeholders. Adding more people may not be the only option, but pushing back demands or changing the wider organizational dysfunction is probably not even on the table.
theptip 5y ago
> hour's in the day and not due to other factors. I think the author’s framework is that most “other factors” would be fixed if the team had more slack. So increase the team’s head count, wait for them to gel, and then with the new slack they should be able to resolve the issues. I agree that there could be other factors (eg a toxic employee, say a TL or manager that is holding everybody back, or an ill-defined mission/mandate). But this article is really just answering the question of where and in what order to add employees if you’re doing hiring, rather than giving you a reason to hire more people.

bob1029 5y ago

This is the only point in the article I disagreed with as well. My suggestion for the "falling behind" phase would be to buy a few days to allow the team to decompress from whatever shit coaster they are currently riding. Letting people actually unwind can help bring strategic focus and calm back into the fold. Otherwise, this read like a documentary about my current company and product.

notaclevername 5y ago
Agreed that this was my biggest disagreement with the article as well. You describe the solution to "falling behind" as giving the team a few days to decompress. I would create that decompression in a different way - by setting and sticking to priorities. Ultimately, if you're falling behind, there's not enough capacity in the system, and so some things won't get done. Better to make that judgment explictly by setting priorities, rather than having it happen ad hoc.

mnahkies 5y ago

Completely agree - augmenting teams with extra people can have the opposite of the desired effect depending on the situation. There's only so much work that can be parallelized efficiently before people start stepping on each others toes. Even if you are able to split things into independently workable chunks, the lack of domain knowledge in a new team member will still often result in a net negative for the first few weeks/months

papito 5y ago

It's like every generation is determined to re-learn the Mythical Man Month - the hard way. You crack it open and boom, there is your anti-pattern right there, called "Brooke's Law".

theptip 5y ago
MMM was making a different claim. “Adding people to a project that is late will make the project more late.” This is taking about the best way to minimize growing pains, assuming you want to grow your org. > To spread hiring equally across the teams in need, or to focus hiring on just one or two teams until their needs were fully staffed? That was the question. It’s not claiming that adding people will make the current project ship faster. It’s claiming that focusing hiring people to underperforming teams will eventually buy them the slack they need to start fixing their issues and increase their velocity in the future, and that you get less total disruption by hiring many people into one team than by hiring one person onto many teams.

analyst74 5y ago

I think the unspoken part is the new manager do not have the clout to push back users/stakeholders, both due to being new and the team having already lost trust of its users/stakeholders. Adding more people may not be the only option, but pushing back demands or changing the wider organizational dysfunction is probably not even on the table.

theptip 5y ago

> hour's in the day and not due to other factors. I think the author’s framework is that most “other factors” would be fixed if the team had more slack. So increase the team’s head count, wait for them to gel, and then with the new slack they should be able to resolve the issues. I agree that there could be other factors (eg a toxic employee, say a TL or manager that is holding everybody back, or an ill-defined mission/mandate). But this article is really just answering the question of where and in what order to add employees if you’re doing hiring, rather than giving you a reason to hire more people.