Comment by sanderjd

4 days ago

I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.

That's cool but don't get heart broken when engineers leave after repeatedly being told the thing they worked on for months wont ship because someone at the top said so.

  • Not really? If those are people I'm close with, I try to express this perspective to them in 1:1s that things that don't end up shipping are not a waste for the reasons I expressed here. And most of those people (because they are simpatico with me, which is why we're close) tend to see it the same way I do, and not leave because of this. And if they do leave for this reason, I conclude, well, they just weren't really aligned with me on this particular perspective. And that's a bummer, but not everyone is gonna see things the way I do.

put simpler, you learned what not to build.

  • It's definitely that, which is very valuable, but it's also the optionality value additionally. You had the option to launch the thing, which you wouldn't have had if you had never worked on it at all. It's notoriously difficult to properly value optionality, but it definitely has value, and often a lot of value.

    • sorry, but this just sounds like a rationalisation for "we built the wrong thing".

      we should just be straightforward, say "we built the wrong thing" and then ask how we built the right-er thing.

      10 replies →

  • Shouldn't companies figure this out before wasting tens of millions in budget + working hours? All I'm reading is that corporations are not taxed enough if they are okay with such opulent waste.

    • Knowing what to build (and that it hasn't already been built or bought elsewhere in the company) requires bits of information / person-to-person networking / visibility into the state of the company that not all managers or VPs have.

      In fact, most people don't have that knowledge, because they're busy with existing or "local" problems , or because they didn't know to ask Davis the DBA or Kris the Kafka Cluster Manger or Alex from accounting if we have <resource> our team can plug into and use. "Oh, yeah, El has one under their desk they kick occasionally, ask them to hook you up!"

      If you solve this problem in a turnkey way Fortune 500 companies will write you very large checks to help them prevent such duplicate waste, and will in turn become the 15th system they need to integrate....

      That XKCD joke about "how 14 standards becomes 15 standards" also applies to the class of "one system to integrate with and report from all other systems"

    • Story time. small business. less than 30 people.

      ceo had invested £1 million to build a data analytics platform. "democratising data analytics" in a very specific domain. essentially, competing with someone like databricks in a niche. although they had never heard of databricks before i showed up.

      For that million pounds they got a job scheduler written in pure django with a halfway finished react frontend. the whole thing was constantly broken. there were multiple race conditions throughout the product. i joined well after the million pounds was all gone. three years after i joined i had fixed the worst of the problems by rewriting massive swathes of the thing.

      i eventually convinced the ceo they'd been doing the wrong thing all this time -- they should focus on analytics + specific domain consultancy services instead of software products.

      the major failure was no-one ever moved on from idea V1. they never moved to idea V2. which meant they never got to idea V3. instead, everyone spent a hell of a lot of time talking about how great V1 was going to be, and how they planned to build V1 and what V1 would look like, check out this status update about our progress on V1, check out this mock up on what V1 is going to look like etc. they had an agile consultant come in to tell them how to be more agile. a scrum-master to tell them how to scrum.

      3 months after joining was the first time i mentioned apache airflow. they literally could have just stuck a nice frontend on top of it and written a backend data transfer library. job done. very cheap idea V1. unfortunately, the previous team of django developers could only see their trusty django hammer. edit -- and i should add their big £1 million budget too.

      multiply the budget by 10x or more. exact same thing at some big corpo. bigger budget = room for more bullshit.

      4 replies →