Why products built by large teams fail so often • Hacker News Board

Re: Why products built by large teams fail so often

#31

Post by Sigerson » Thu, Feb 09, 2017, 8:01 PM UTC

mwfunk wrote: post #8

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together. Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into dif…

The key really is making sure a large project is not a monolithic project. Break it down, break it down, break it down. The same logic that works for implementation is also valuable on the product side.

Scaling engineering is much easier if the project is designed with that scale in mind.

Re: Why products built by large teams fail so often

#32

Post by epo » Thu, Feb 09, 2017, 8:08 PM UTC

jcranmer wrote: post #30

bluedino wrote: post #25

Earlier quoted context omitted.

>> That will mean that most small teams will fail, as they will be composed from average developers. No, it means if you have a large team you will have more average developers - you could have a small team of 3-4 hotshot developers and they turnout a fantastic product - but add 10 normies to the team and it just drags them all down.

If you take 10,000 developers and distribute them among 1,000 teams, the expected average ability of each team is the same as if you distributed them among 10 teams. What changes is the variance--the averages among the 10 teams will be more tightly clustered than among the 1,000 teams.

That is a different argument and may or may not be relevant. Really, read Mythical Man Month, the problem with large teams is that their size leads to internal communications overheads, politics ...

Re: Why products built by large teams fail so often

#33

Post by mjevans » Thu, Feb 09, 2017, 8:13 PM UTC

Sigerson wrote: post #31

mwfunk wrote: post #8

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together. Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into dif…

The key really is making sure a large project is not a monolithic project. Break it down, break it down, break it down. The same logic that works for implementation is also valuable on the product side. Scaling engineering is much easier if the project is designed with that scale in mind.

Also clearly define the scale that things will /run/ at.

When possible also have (a snapshot of) real data to run conformance and performance tests against.

Re: Why products built by large teams fail so often

#34

Post by [deleted] » Thu, Feb 09, 2017, 8:33 PM UTC

snerbles wrote: post #29

webmaven wrote: post #19

Earlier quoted context omitted.

Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP. What's that..…

Watching a past employer slowly drown itself in technical debt is simultaneously sad and satisfying.

[deleted]

Re: Why products built by large teams fail so often

#35

Post by skaplun » Thu, Feb 09, 2017, 8:43 PM UTC

This is a "yes but" kind of post ( i feel ). Executing a large product can often require several project managers reporting to a product owner. It's not product vs project.

Re: Why products built by large teams fail so often

#36

Post by aaronblohowiak » Thu, Feb 09, 2017, 8:46 PM UTC

webmaven wrote: post #19

cbhl wrote: post #14

Earlier quoted context omitted.

Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.

Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP. What's that..…

"protoduction"

Re: Why products built by large teams fail so often

#37

Post by oebs » Thu, Feb 09, 2017, 8:47 PM UTC

scarface74 wrote: post #10

I agree with the article mostly, but one issue I've always had with product owners is the lack of willingness to lay the proper foundations for technical products to succeed. That can be anything from training and allowing developers to do a proof of concept before they decide on the technology. The importance of automated testing,code reviews, refactoring, etc.

Usually there's some sort of engineering manager / lead engineer who's in charge of deciding how the product is built from a technical point of view. He's the main collaborator of the product manager/owner and they need to get along well.

Re: Why products built by large teams fail so often

#38

Post by bluetwo » Thu, Feb 09, 2017, 9:32 PM UTC

If you are working on a large product that is the future of the company and involves several silos, and do not have an executive sponsor who is responsible for making sure it gets done, you are doing it wrong.

Re: Why products built by large teams fail so often

#39

Post by softawre » Fri, Feb 10, 2017, 12:36 AM UTC

mjevans wrote: post #33

Sigerson wrote: post #31

Earlier quoted context omitted.

The key really is making sure a large project is not a monolithic project. Break it down, break it down, break it down. The same logic that works for implementation is also valuable on the product side. Scaling engineering is much easier if the project is designed with that scale in mind.

Also clearly define the scale that things will /run/ at. When possible also have (a snapshot of) real data to run conformance and performance tests against.

Agree 100%. So many people make lip service to SCALE at my company, but out of 20+ teams we are the only team running real scale tests against real defined limits with real (obfuscated) customer data.

Re: Why products built by large teams fail so often

#40

Post by candiodari » Fri, Feb 10, 2017, 1:53 AM UTC

webmaven wrote: post #19

cbhl wrote: post #14

Earlier quoted context omitted.

Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.

Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP. What's that..…

> What's that...? No, I've never experienced that situation myself, why do you ask?

Another way to look at it is to say this provided you with a job and an entire company with a revenue basis, probably for years.

I mean on the other side of the fence there are plenty of stories of software developers being allowed to "properly design", no technical debt, then after 1 year of zero result they come with a product, which doesn't even start (the tests run and succeed, though). Then the third or so feature request that comes in ... needs a rewrite.