> [I] would like to see is increased risk-taking in the workplace [...] I want to blow up the scope [1], but they won't allow me
While I generally agree with the sentiment, let me offer a devil's advocate position to counter the whole "woe is me, I am but a 10x engineer suffocated by the evil VCs and PMs of the world who keep asking for dumb jira updates. If they stopped asking for updates, I'd give it to them in 5 years" narrative.
There are similar criticisms in academia-- "The bean-counting administrators need some dumb metrics (num papers, num citations) for tenureship". While these are valid criticisms, the alternative is not one I'd prefer.
Consider someone who does make grandiose claims, but pushed back against those who ask for "updates" or "metrics". Elizabeth Holmes is cited as one such person with "[going] all-in; mega bold and despite the odds stacked against them". But this example actually is a warning that goes against the point of the article, I feel. The "evil VCs" full-heartedly trusted her. Are you telling me that if the VCs just took more risk, she would have succeeded? But instead, they basically margin called her and screwed her over because they were too risk-intolerant?
W.r.t Holmes, I actually place a small amount of fault on her. It's good to dream big. I place more fault on the VCs for not being "bean-countery" enough, because anybody with proper auditing would be able to see the issues there, instead of blindly trusting "oh this $100mil is for R&D, just trust me. You need to take risks for this world changing blood testing methodology."
The takeaway is-- there's a reason scope might be restricted. In academia, there's a notion of a "publon" [2], the smallest "quantum" of knowledge that can be published (ha! I love that name). The idea is, no matter how large a project might be, it is segmentable, and if it is not segmentable, it's not a good project. Furthermore, publishing is THE mechanism of which scientists get feedback, and feedback is critical to our iteration process.
(Again, as I mentioned, there are tons of problems with the "publish or perish" culture, which I could also go on forever about, but preferable IMO to the alternative of publishing a magnus opus every 10 years).
We can generalize that concept to most things. Feedback and metrics are critical inputs to iteration. You can certainly criticize these metrics, but you can't JUST say "take more risk" without providing alternative data to update a VC's investing strategy. You want them to accept your giant ass scope? Give them better data. Help them help you.
For another example-- Consider a project that's been going on for almost 20 years. Mill Computing [3]. They have established some pretty massive scope, and it's a goal I support. But do we (the public) have much insight as to what they're doing, precisely? Not really. They most definitely have their reasons, I'm sure, but I, as an outsider, know very little about how they are achieving their goal. So then why would I invest in them?
> [I] would like to see is increased risk-taking in the workplace [...] I want to blow up the scope [1], but they won't allow me
While I generally agree with the sentiment, let me offer a devil's advocate position to counter the whole "woe is me, I am but a 10x engineer suffocated by the evil VCs and PMs of the world who keep asking for dumb jira updates. If they stopped asking for updates, I'd give it to them in 5 years" narrative.
There are similar criticisms in academia-- "The bean-counting administrators need some dumb metrics (num papers, num citations) for tenureship". While these are valid criticisms, the alternative is not one I'd prefer.
Consider someone who does make grandiose claims, but pushed back against those who ask for "updates" or "metrics". Elizabeth Holmes is cited as one such person with "[going] all-in; mega bold and despite the odds stacked against them". But this example actually is a warning that goes against the point of the article, I feel. The "evil VCs" full-heartedly trusted her. Are you telling me that if the VCs just took more risk, she would have succeeded? But instead, they basically margin called her and screwed her over because they were too risk-intolerant?
W.r.t Holmes, I actually place a small amount of fault on her. It's good to dream big. I place more fault on the VCs for not being "bean-countery" enough, because anybody with proper auditing would be able to see the issues there, instead of blindly trusting "oh this $100mil is for R&D, just trust me. You need to take risks for this world changing blood testing methodology."
The takeaway is-- there's a reason scope might be restricted. In academia, there's a notion of a "publon" [2], the smallest "quantum" of knowledge that can be published (ha! I love that name). The idea is, no matter how large a project might be, it is segmentable, and if it is not segmentable, it's not a good project. Furthermore, publishing is THE mechanism of which scientists get feedback, and feedback is critical to our iteration process.
(Again, as I mentioned, there are tons of problems with the "publish or perish" culture, which I could also go on forever about, but preferable IMO to the alternative of publishing a magnus opus every 10 years).
We can generalize that concept to most things. Feedback and metrics are critical inputs to iteration. You can certainly criticize these metrics, but you can't JUST say "take more risk" without providing alternative data to update a VC's investing strategy. You want them to accept your giant ass scope? Give them better data. Help them help you.
For another example-- Consider a project that's been going on for almost 20 years. Mill Computing [3]. They have established some pretty massive scope, and it's a goal I support. But do we (the public) have much insight as to what they're doing, precisely? Not really. They most definitely have their reasons, I'm sure, but I, as an outsider, know very little about how they are achieving their goal. So then why would I invest in them?
[1]: https://timdaub.github.io/2021/06/18/when-scope-blows-up/
[2]: https://en.wikipedia.org/wiki/Least_publishable_unit
[3]: https://millcomputing.com/