9 ms·

Staying on the path to high performing teams (2018)

103 points by bsilvereagle 5y ago

fconnor 5y ago
"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.
papito 5y ago
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. Don't solve problems you don't have. Most companies think they need microservices, for example. It is an extremely 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 reason about distributed systems. Instagram? Monolith. 12 people when sold to Facebook. WhatsApp? Monolith. 32 people when sold to Facebook. StackOverflow. Monolith, with a lite SQL ORM for highly optimized queries. 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.
- vasergen 5y ago
  It always surprise me why startups want to grow in amount of people. I see this picture quite often. There is a small team that managed to create a great product. Then they get investmens, grow in size, hired a few starts that worked before in FAANG like companies and now trying to adopt microservices. The initial team spirit is gone, people who worked there from the leaving
  - cosmodisk 5y ago
    Sometimes it's done for smoke and mirrors more than anything else. There's suddenly a ton of money pushing in your door,so people decide to start adding random titles to the payroll,even though it's probably still those 5-10 guys that making it all tick.
  - marcinzm 5y ago
    Because they need to grow users and build a moat against competitors. If your product was made in 6 months by 5 engineers then a competitor can (and will) do the same. Users will generally want new features or capabilities or other such things. Boring but time consuming work not matter how well engineered your product is. This type of work is very different from a green field new product so it'd be odd if many people didn't leave during the shift.
ChrisMarshallNY 5y ago
I have to agree with the other commenters about #1. Adding people adds team overhead, and that is killer. 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 (see Brooks, Fred -The Mythical Man-Month). 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). There’s absolutely no substitute for a seasoned, experienced team that has worked together for years, 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 people, not just weapons and tactics. 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.
- WJW 5y ago
  Having been a Navy officer myself, I cannot agree more about the role of experience and training in team formation. So many software companies just throw together a few people and expect them to be productive right off the bat but that is simply not how people work. Reorgs every six months actively destroy any sense of team formation too. That said, the military enjoys a level of personnel lock in that few software orgs can dream of. I don't know many software engineer that would agree to a five-year contract with no option for early leaving.
  - ChrisMarshallNY 5y ago
    > I don't know many software engineer that would agree to a five-year contract with no option for early leaving. Which is why it's important to practice good, humane management. Good engineers can punch their own tickets. Need lots of carrot, and very little stick. I kept high-functioning, smart, experienced, C++ image processing engineers together for decades on my team, despite mediocre pay, and a pretty challenging environment (no, I won't go into detail). This required that I connect with each and every member of my team as a human, often on an equal basis, as opposed to as a "superior/inferior" basis. It also meant that I needed to learn about the drivers for each person, give them as much family time as they needed, back off from micromanaging, and find ways to help them to resolve differences in ways that strengthened the team. As I have stated before, when they finally rolled up my team, after 27 years, the person with the least tenure had a decade. In about a month, we'll be getting together for a cookout at one of my former employees' home. We haven't worked together in over 3 years, but we still share a bond.
tomerv 5y ago
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.
pjc50 5y ago
It's interesting that all of these points talk about the speed of taking items out 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.
- omgwtfpmr 5y ago
  The author has a complementary article that addresses that: https://lethain.com/limiting-wip/ https://lethain.com/limiting-wip/.
- gonzo41 5y ago
  There's a techniuqe i like, I think it's a Lean technique, anyways it's called 5 Why's. When ever I get to act as a filter on requirements from the business, I bust it out to tease out the root cause issues driving the solution. It's really good. Essentially it boils down to asking Why as much as possible until you get to the original problem. From there the problem can be put in the backlog to be solved by the devs rather than the precooked solution.
- Viliam1234 5y ago
  Exactly. When you are adding items to backlog faster than the team can process them, it is not obvious to me why "add more people to the team" should be the right solution. Maybe there was a wrong decision made at the beginning of the project that needs to be fixed. Maybe the version 1.0 has too many features. Maybe the project could be split in two independent parts (which will still require hiring more people, but with less complex of internal communication). Maybe the basic infrastructure was not set up correctly (logging, unit tests, continuous integration) and there is no time to make it right because the visible parts of the application always get the top priority. Maybe the team members are working with a technology they never used before, and giving them a one-week training could increase their speed dramatically. Maybe there is some interpersonal conflict in the team, where things could be improved by removing a team member? More importantly, why are you adding new items to the backlog so fast? Is your company doing "agile rituals, but with predetermined scope and deadlines"? Let me guess: the answer "hire more people" is so popular, because it is a universal answer that does not require the manager to actually understand anything; and as a nice side effect, having more underlings increases the manager's importance.
g051051 5y ago
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. Oh, and a system fix is to add process? That's about as counterintuitive as it gets. 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.
- herval 5y ago
  What works, in your experience?
  - g051051 5y ago
    If the team is falling behind, stop incoming work until they catch up. If the team is treading water, stop incoming work until they start making progress. If the team is repaying debt but not at the desired capacity, then add more people. In that case, the effort of training and integrating a new person is just another form of debt. In all cases, if the team is overloaded in some way (debt rising, not delivering quality, missing deadlines) also add slack.
    - herval 5y ago
      Have you seen that work anywhere, at any scale? What you’re describing is pretty much every single chronic underperforming team I’ve ever watched. It leads to an organization where everyone is essentially “blocked”, and since work tends to expand to take all available time, it’ll remain “blocked” forever (as you remove the main lever for having to unblock yourself - inbound work)
      - g051051 5y ago
        > Have you seen that work anywhere, at any scale? Of course. It's the only logical and effective way to deal with the problem. > It leads to an organization where everyone is essentially “blocked” There's a big difference from being "blocked", and what the article called "falling behind": >> "A team is falling behind if each week their backlog is longer than the week before. Typically folks are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied." So, you deliver one or two features, or consume a backlog item, but more work comes in, so there's net negative progress (as measured by the list of pending work items). So, you stop the incoming work so that the existing work can proceed to completion, the team can then figure out how to add capacity without falling behind again. If the team is incapable of doing the work for some reason, that's a completely different problem.
helge9210 5y ago
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.

103 points by bsilvereagle 5y ago

"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.

papito 5y ago

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. Don't solve problems you don't have. Most companies think they need microservices, for example. It is an extremely 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 reason about distributed systems. Instagram? Monolith. 12 people when sold to Facebook. WhatsApp? Monolith. 32 people when sold to Facebook. StackOverflow. Monolith, with a lite SQL ORM for highly optimized queries. 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.

vasergen 5y ago
It always surprise me why startups want to grow in amount of people. I see this picture quite often. There is a small team that managed to create a great product. Then they get investmens, grow in size, hired a few starts that worked before in FAANG like companies and now trying to adopt microservices. The initial team spirit is gone, people who worked there from the leaving
- cosmodisk 5y ago
  Sometimes it's done for smoke and mirrors more than anything else. There's suddenly a ton of money pushing in your door,so people decide to start adding random titles to the payroll,even though it's probably still those 5-10 guys that making it all tick.
- marcinzm 5y ago
  Because they need to grow users and build a moat against competitors. If your product was made in 6 months by 5 engineers then a competitor can (and will) do the same. Users will generally want new features or capabilities or other such things. Boring but time consuming work not matter how well engineered your product is. This type of work is very different from a green field new product so it'd be odd if many people didn't leave during the shift.

ChrisMarshallNY 5y ago

I have to agree with the other commenters about #1. Adding people adds team overhead, and that is killer. 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 (see Brooks, Fred -The Mythical Man-Month). 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). There’s absolutely no substitute for a seasoned, experienced team that has worked together for years, 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 people, not just weapons and tactics. 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.

WJW 5y ago
Having been a Navy officer myself, I cannot agree more about the role of experience and training in team formation. So many software companies just throw together a few people and expect them to be productive right off the bat but that is simply not how people work. Reorgs every six months actively destroy any sense of team formation too. That said, the military enjoys a level of personnel lock in that few software orgs can dream of. I don't know many software engineer that would agree to a five-year contract with no option for early leaving.
- ChrisMarshallNY 5y ago
  > I don't know many software engineer that would agree to a five-year contract with no option for early leaving. Which is why it's important to practice good, humane management. Good engineers can punch their own tickets. Need lots of carrot, and very little stick. I kept high-functioning, smart, experienced, C++ image processing engineers together for decades on my team, despite mediocre pay, and a pretty challenging environment (no, I won't go into detail). This required that I connect with each and every member of my team as a human, often on an equal basis, as opposed to as a "superior/inferior" basis. It also meant that I needed to learn about the drivers for each person, give them as much family time as they needed, back off from micromanaging, and find ways to help them to resolve differences in ways that strengthened the team. As I have stated before, when they finally rolled up my team, after 27 years, the person with the least tenure had a decade. In about a month, we'll be getting together for a cookout at one of my former employees' home. We haven't worked together in over 3 years, but we still share a bond.

tomerv 5y ago

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.

pjc50 5y ago

It's interesting that all of these points talk about the speed of taking items out 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.

omgwtfpmr 5y ago
The author has a complementary article that addresses that: https://lethain.com/limiting-wip/ https://lethain.com/limiting-wip/.
gonzo41 5y ago
There's a techniuqe i like, I think it's a Lean technique, anyways it's called 5 Why's. When ever I get to act as a filter on requirements from the business, I bust it out to tease out the root cause issues driving the solution. It's really good. Essentially it boils down to asking Why as much as possible until you get to the original problem. From there the problem can be put in the backlog to be solved by the devs rather than the precooked solution.
Viliam1234 5y ago
Exactly. When you are adding items to backlog faster than the team can process them, it is not obvious to me why "add more people to the team" should be the right solution. Maybe there was a wrong decision made at the beginning of the project that needs to be fixed. Maybe the version 1.0 has too many features. Maybe the project could be split in two independent parts (which will still require hiring more people, but with less complex of internal communication). Maybe the basic infrastructure was not set up correctly (logging, unit tests, continuous integration) and there is no time to make it right because the visible parts of the application always get the top priority. Maybe the team members are working with a technology they never used before, and giving them a one-week training could increase their speed dramatically. Maybe there is some interpersonal conflict in the team, where things could be improved by removing a team member? More importantly, why are you adding new items to the backlog so fast? Is your company doing "agile rituals, but with predetermined scope and deadlines"? Let me guess: the answer "hire more people" is so popular, because it is a universal answer that does not require the manager to actually understand anything; and as a nice side effect, having more underlings increases the manager's importance.

g051051 5y ago

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. Oh, and a system fix is to add process? That's about as counterintuitive as it gets. 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.

herval 5y ago
What works, in your experience?
- g051051 5y ago
  If the team is falling behind, stop incoming work until they catch up. If the team is treading water, stop incoming work until they start making progress. If the team is repaying debt but not at the desired capacity, then add more people. In that case, the effort of training and integrating a new person is just another form of debt. In all cases, if the team is overloaded in some way (debt rising, not delivering quality, missing deadlines) also add slack.
  - herval 5y ago
    Have you seen that work anywhere, at any scale? What you’re describing is pretty much every single chronic underperforming team I’ve ever watched. It leads to an organization where everyone is essentially “blocked”, and since work tends to expand to take all available time, it’ll remain “blocked” forever (as you remove the main lever for having to unblock yourself - inbound work)
    - g051051 5y ago
      > Have you seen that work anywhere, at any scale? Of course. It's the only logical and effective way to deal with the problem. > It leads to an organization where everyone is essentially “blocked” There's a big difference from being "blocked", and what the article called "falling behind": >> "A team is falling behind if each week their backlog is longer than the week before. Typically folks are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied." So, you deliver one or two features, or consume a backlog item, but more work comes in, so there's net negative progress (as measured by the list of pending work items). So, you stop the incoming work so that the existing work can proceed to completion, the team can then figure out how to add capacity without falling behind again. If the team is incapable of doing the work for some reason, that's a completely different problem.

helge9210 5y ago

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.