| Yes, agreed. But it's not a binary. It's not like you can either wrestle with hard engineering problems until an eventual breakthrough or exclusively pretend to be working. Sure, on one extreme is the purely value-extractive person whose only work product is calling recurring meetings to talk about how great things are going (while having contributed little). In that case, it's an error to be corrected. But there are different types of useful work. Let's use engineering as an example. You could build a set of new filter options on in-product analytics that customers have been asking for. Assuming this doesn't require net-new data sources or whatnot, this is usually not a complex engineering challenge, but will be loved by customers. Then you have types who refactor an obscure caching function to reduce its memory use 15% when performance wasn't an issue, but it was a fun engineering puzzle that made the code more elegant. Clearly both create value, but one will be more useful to customers, although it's not as fun to solve. My point isn't that we should treat corporate bureaucracy, performative work, and freeloading as "the way things are" (they're toxic to any work culture). I'm saying that "deeper engineering challenge" doesn't equal "more important work". Also, I don't necessarily like this! Deep problem-solving and focused work on tricky challenges are the most fulfilling things to me and to most people I know. But this is the dynamic we're in. (and yes you can argue that having the most efficient code possible prevents future performance issues and whatnot and is thus long-term more valuable than analytics options, but at least in the startup world, limited resources mean you tend to solve things when they become problems, not because they could one day become problems) |