Why products built by large teams fail so often

Right, so the key is giving the product owner the authority to decide what the product will be, what features will be included, which features will be excluded, and prioritization of those features.

This article simply talks about one reason that could cause a large product to fail. In my experience, an internal management focused approach is fine, but can still lead to an organisation that is good at successfully failing.

The focus on the team is interesting, specifically the "hold them accountable for clearly defined KPIs" point. What about the product owner and manager? What happens to them when the product is delivered feature complete and on schedule but still fails?

As developers we have peer reviews, in my experience, product managers rarely have people review their work. Meaning there are very few people that can push the product manager to improve his/her strategy/tactics/approach. I find it's usually a senior manager or C level that has the most influence over a product manager. The flaw in this is that the person reviewing the work is not an expert practitioner thus cannot provide concrete advice.

The author mixes in methods from LEAN and agile with statements such as:

- "Start with the smallest scope you can deliver that provides value to your users." - "Let them choose their own tools and processes. And then support their decisions."

However, given that is well tread ground, I think the author's main point is to address the issue in large teams whereby "no one is fully committed".

The key piece of advice is "Pick a group of people who are willing and able to shake up the status quo in your organization." Nevertheless, I would say that the act of doing this naturally turns your project team from a large one into a small one.

The advice is not unique and has definitely been tried, with myself witnessing a product manager that effectively created a startup within a startup. One should not discount the manifestation of this phenomenon as a visible sign of organisational disfunction.

In addition to the implied comment that people not on a team were not good enough to meet certain criteria, you also end up with a clique situation as described by a former Valver [1].

All this comes back to the point that no one is fully committed and a toxic environment begins to form. Unfortunately the answer to getting commitment from people is even higher level and ethereal, best described as ensuring the company has mission and purpose. Similar to Dan Pink's focus on mastery, autonomy, and purpose - but executed at a cohesive organisational level.

I would summarise what's needed as real leadership. Meaning someone that can rally everyone around a product and the company. Once you have defeated apathy, commitment can be channeled into extra-ordinary outcomes. What a lot of managers don't seem to understand, or be willing to practice, is that getting and building commitment often means building meaningful professional and personal relationships with the people you work with, which is at odds with the often mercenary nature of businesses.

[1]: https://www.wired.com/2013/07/wireduk-valve-jeri-ellsworth/

I remember talking to a former software exec at Amazon and he actually told me a personal philosophy that I thought was pretty profound at the time.

To set the stage this was when web services where coming into fashion and he was a big proponent of them, he said that he likes to focus teams around business domains (e.g accounts receivable, road logistics, etc.) then let them control their destiny. He said that he liked a service based architecture because it allowed him to build Amazon scale software, a piece at a time and more importantly the nugget that I really took away from the conversation was that you cant stop bad software from being written, but you can isolate bad software from the rest of the system which allows you to measure all kinds of things that give you an overall metric on the quality of that software. Things like time to defect resolution, uptime as well as true business metrics given that they are aligned with a vertical (i.e did the software empower the core business goal). If the numbers are lacking the software is bad plain and simple. Isolation makes it easy to replace.

I don't think enough people who architect large systems give thought to how do we protect the overall system from bad code which is a certainty to happen on large projects because they necessitate large teams. As developers and architects we tend to focus on elegant designs, but the overall support of an application thru it's life is anything but elegant.

I've been at two places where they were hiring like crazy because of huge rounds of funding. Even though they were hiring like crazy, they weren't hiring the right people.

I had an argument where I was explaining that engineering would be more efficient if we hired a researcher - at least just one to start with. Managements answer was to hire 10 more engineers to solve the underlying problem.

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.