3 ms·

The fact that organizations have multiple teams working on overlapping or even similar things baffles me. I can't imagine how that wouldn't be immensely dissati

The fact that organizations have multiple teams working on overlapping or even similar things baffles me. I can't imagine how that wouldn't be immensely dissatisfying for the individual.

axg11 4y ago
Internally it was sold as: working together with other teams is too inefficient due to dependencies and differing priorities. It's faster to build it again independently than integrate with the existing service.
dsfyu404ed 4y ago
In environments where missing deadlines can have huge cascading effects it isn't unheard of to do redundant work so that you have a better shot of meeting your deadline and in a good case you have multiple successful options to pick from. When your deadlines are potentially expensive enough (think capital investment that need to be bought in time to be built out before old ones become uneconomical to operate) this approach can be well worth it.
lightbendover 4y ago
Not all teams are created equal. Having multiple teams with an extremely similar charter promotes competition, harder work, and deeper search for synergies elsewhere. A single team with a guarded remit is not going to try as hard and they may outright fail on their mission even if they do have internal competition. It makes a lot of sense if you can afford it.
shmatt 4y ago
This approach was made popular by Steve Jobs at Apple. He would have multiple teams competing to who's solution would survive, while the other teams products were thrown away This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones
- no_wizard 4y ago
  I think this approach makes sense for hardware but not pure software. I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively. If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful
- bitL 4y ago
  It was way before Jobs, IBM was using it ages ago.
  - kenjackson 4y ago
    Isn't this part of the premise of the book Hackers? Haven't read it in like 25 years, but that's what I vaguely remember.
    - warner25 4y ago
      I don't recall this coming up in Hackers: Heroes of the Computer Revolution, but it was definitely in The Soul of A New Machine, the story about Data General trying to build their first 32-bit computer.
      - kenjackson 4y ago
        Thank you... it was Soul of a New Machine. I don't think I even ever read Hackers!
  - kwertyoowiyop 4y ago
    Jobs gets credit for everything in computing the way Churchill gets credit for all the good quotes.
    - 4y ago
bitL 4y ago
You spawn multiple teams working on very similar projects without them knowing about each other, let them grow for a while, then choose the most promising one (or with the highest traction) as your default solution and kill off the rest. Pretty normal exploration strategy.
onion2k 4y ago
Amazon has about 75,000 engineers. That's the equivalent of a large town. It's completely reasonable that many people would end up duplicating the work of other teams simply because they never communicate with them.
kevan 4y ago
The philosophy is "1 > 2 > 0". This means ideally you'd prefer a single thing but single things often bottleneck delivery from different orgs as they have differing requirements. In that case you'll accept overlap/duplication if it keeps those orgs decoupled and both delivering faster. I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.
ngc248 4y ago
Speculative execution .... which ever team moves fast wins ... heck sometimes its not even the team with the best features that wins ... teams with just enough features but who can move fast win sometimes and its bad for the long run. Most big companies have been doing this for a long time now.

The fact that organizations have multiple teams working on overlapping or even similar things baffles me. I can't imagine how that wouldn't be immensely dissatisfying for the individual.

axg11 4y ago

Internally it was sold as: working together with other teams is too inefficient due to dependencies and differing priorities. It's faster to build it again independently than integrate with the existing service.

dsfyu404ed 4y ago

In environments where missing deadlines can have huge cascading effects it isn't unheard of to do redundant work so that you have a better shot of meeting your deadline and in a good case you have multiple successful options to pick from. When your deadlines are potentially expensive enough (think capital investment that need to be bought in time to be built out before old ones become uneconomical to operate) this approach can be well worth it.

lightbendover 4y ago

Not all teams are created equal. Having multiple teams with an extremely similar charter promotes competition, harder work, and deeper search for synergies elsewhere. A single team with a guarded remit is not going to try as hard and they may outright fail on their mission even if they do have internal competition. It makes a lot of sense if you can afford it.

shmatt 4y ago

This approach was made popular by Steve Jobs at Apple. He would have multiple teams competing to who's solution would survive, while the other teams products were thrown away This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones

no_wizard 4y ago
I think this approach makes sense for hardware but not pure software. I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively. If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful
bitL 4y ago
It was way before Jobs, IBM was using it ages ago.
- kenjackson 4y ago
  Isn't this part of the premise of the book Hackers? Haven't read it in like 25 years, but that's what I vaguely remember.
  - warner25 4y ago
    I don't recall this coming up in Hackers: Heroes of the Computer Revolution, but it was definitely in The Soul of A New Machine, the story about Data General trying to build their first 32-bit computer.
    - kenjackson 4y ago
      Thank you... it was Soul of a New Machine. I don't think I even ever read Hackers!
- kwertyoowiyop 4y ago
  Jobs gets credit for everything in computing the way Churchill gets credit for all the good quotes.
  - 4y ago

bitL 4y ago

You spawn multiple teams working on very similar projects without them knowing about each other, let them grow for a while, then choose the most promising one (or with the highest traction) as your default solution and kill off the rest. Pretty normal exploration strategy.

onion2k 4y ago

Amazon has about 75,000 engineers. That's the equivalent of a large town. It's completely reasonable that many people would end up duplicating the work of other teams simply because they never communicate with them.

kevan 4y ago

The philosophy is "1 > 2 > 0". This means ideally you'd prefer a single thing but single things often bottleneck delivery from different orgs as they have differing requirements. In that case you'll accept overlap/duplication if it keeps those orgs decoupled and both delivering faster. I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.

ngc248 4y ago

Speculative execution .... which ever team moves fast wins ... heck sometimes its not even the team with the best features that wins ... teams with just enough features but who can move fast win sometimes and its bad for the long run. Most big companies have been doing this for a long time now.