6 ms·
>suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product At scale it tends to be worthwhile, even necessary,
by closeparen 6y ago
>suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product
At scale it tends to be worthwhile, even necessary, to engage fully with the complexity of all those "niche" aspects.
When you don't understand how something could possibly take so much effort, it's possible all the people working on it are idiots and you could do it better in a weekend. (When you spot situations like that, think of them as startup opportunities...)
It's also possible they're doing a good job hiding the complexity from you.
- munificent 6y agoI think there is a lot of truth to both your comment and the parent comment. Everyone underestimates the complexity of systems they aren't personally familiar with. Ask the average person how many parts are in a modern automobile and they'd probably guess too low by an order of magnitude. But it is also true that large organizations get weird when money is easily available. You get a Cambrian explosion where without selection pressure to ensure people and teams do real, useful work, everything starts to seem like a good idea. Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business.
- neumann 6y agoThis is a very nice description of what I've noticed moving to a large organisation. There is also a lot of busy work. As the organisation grows, communicating and negotiating between groups requires extra effort that often ends up being the role of a new management level, and groups have self-preserving incentives to stay relevant leading to lots of entropy (busy work, repeated work, hero projects that are just there for internal branding). As someone who has recently been put in this level of management I spend a lot of time having to negotiate out of new project initiatives invented more to attract exec attention or satisfy a rogue execs dream project. Makes me really look forward to moving back to working in a smaller company.
- ethbro 6y ago> Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business. Three questions. (1) "What would the impact on our business be if we built the best possible, state of the art feature here?" (2) "What would the impact on our business be if we half-assed a solution in a quarter of the time?" (3) "What would the impact on our business be if we utterly failed?" (Usually, the different between 1 & 2 is negligible. Sometimes, between 1 & 3. Don't ask people to justify success. Ask them to justify why we should spend any more time than slightly-above-failure.)
- munificent 6y agoThose questions assume an existing framework where "the feature", "state of the art", "half-assed", and "failed" are all well-defined. But my experience is that the framing itself is most of where the challenge lies. You end up with team A who wants to add the feature, team B who thinks it's an anti-feature, team C who thinks the entire application where feature lives should be scrapped, PM D who says users can already accomplish what the feature does using existing features, UX design E who says the fact that users are still asking for the feature means all those other features must be poorly designed and we should fix those...
- vishnugupta 6y agoThat second paragraph summarized the last 5 years of my professional career.
- srnvs123 6y agoIn my experience, I've always listened to the last UX design E guy. Every time we worked on what he said the users asked for, we did well..
- jpalomaki 6y agoThe problems caused by "half-assed" solutions are likely somewhere down the line, in distant future and their true costs impossible to estimate.
- thrav 6y agoEvery tech company thinks they’ll just build their own CRM until they try.
- munificent 6y agoSee also: build systems and UI frameworks.
- deleted 6y ago[deleted]
- kortilla 6y agoThat’s a false dichotomy. It’s likely that that are both not idiots and what they are doing isn’t necessary. When large companies have such excess engineering power to blow, they tend to say yes to all requirements and scope creep takes over everything. So no, the engineers building the abstract framework factory are not stupid, but they should have just built the report dashboard instead of the tool to generate tool generators.
- marcus_holmes 6y agoAs soon as an organisation gets above a size limit, organisational politics becomes the most important factor in any decision. The decision to agree to a feature request starts to consider Who the feature request came from before any of the practicalities of the feature itself. They're not idiots, and they are doing what is necessary, but the goals have moved from outward-facing market and customer concerns to inward-facing organisational-political concerns. Every coder in a large organisation, sooner or later, gets given a task that makes no engineering sense but achieves some internal political goal.
- varjag 6y agoIt is fair to say that when you have R&D headcount in thousands it better be something really impressive. Boeing 747 design team was 4500 engineers and they were done in 29 months.
- blackrock 6y agoSoftware is a little strange sometimes. It’s a different type of systems engineering, that’s more akin to sorcery, than to actual physics. The hardware is, of course, limited by physics, like the speed of electrons and heat dissipation. But once you get past that, your computer system is a collection of bytes that you reassemble to form whatever it is your imagination desires. And while the 747 is a magnificent plane, it did have the benefit of over 50 years of aviation and aeronautical science behind it, all figured out. Whereas software is still somewhat in its infancy right now. And every few decades, it seems to revolutionize itself, as newer and faster hardware become available.