3 ms·

I was just thinking about how at most jobs I've ever worked the main barrier to productivity is the inability to make minor (in my opinion) changes to organizat

I was just thinking about how at most jobs I've ever worked the main barrier to productivity is the inability to make minor (in my opinion) changes to organizational policies that have high business logic complexity relative to benefit.

JohnBooty 7y ago
Yeah. Particularly if you don't have the authority to implement changes that would improve things in the long run, there's really no way for a dev to be a "10x" in that situation, even if they may have the ability to be a "10x" dev in other contexts.
- cbzoiav 7y ago
  A lot of it is drive and people skills. If senior people like/trust you and you're willing to stand your ground/fight for something you can normally achieve significantly more. That and luck on how those above you are trying to play the corporate politics / personal career game.
  - JohnBooty 7y ago
    Agreed on all counts. Drive and people skills matter a lot. Also, a lot of nefarious people skills are also rewarded. If senior people like/trust you and you're willing to stand your ground/fight for something you can normally achieve significantly more. Yes, although in a lot of company cultures this is nearly impossible due to the lack of level playing field. A "software architect" I once worked under liked to play the following game, and he played it awfully well. We'll call him "B." 1. "B." spends days, weeks, or months researching a solution all by his lonesome. 2. "B." presents this idea to the team. It is effectively an edict, but he presents it as a meritocratic chance for others to offer feedback or alternative ideas. 3. The rest of the team is caught flat-footed, because we... just heard about this problem minutes ago, and obviously aren't as prepared as... well, somebody who has prepared. We are also not allocated time away from our scrums in order to research and test alternatives, whereas that was essentially his entire job. In other words, we bore the burden of proof and yet had no time in which to produce said proof. 4. I don't recall one of the edicts-masquerading-as-RFCs from "B." ever being successfully challenged. Management (who was non-technical) perceived this as evidence of B's superiority, because after all, it's not like folks had better ideas than "B." Since he structured things in a way such that folks really couldn't have better ideas. Eventually many folks on the team (like me) tuned out and just stopped participating in the whole charade after a few trips around the block. This, of course, was seen by management as more evidence that "B." was the only one with legit ideas.

JohnBooty 7y ago

Yeah. Particularly if you don't have the authority to implement changes that would improve things in the long run, there's really no way for a dev to be a "10x" in that situation, even if they may have the ability to be a "10x" dev in other contexts.

cbzoiav 7y ago
A lot of it is drive and people skills. If senior people like/trust you and you're willing to stand your ground/fight for something you can normally achieve significantly more. That and luck on how those above you are trying to play the corporate politics / personal career game.
- JohnBooty 7y ago
  Agreed on all counts. Drive and people skills matter a lot. Also, a lot of nefarious people skills are also rewarded. If senior people like/trust you and you're willing to stand your ground/fight for something you can normally achieve significantly more. Yes, although in a lot of company cultures this is nearly impossible due to the lack of level playing field. A "software architect" I once worked under liked to play the following game, and he played it awfully well. We'll call him "B." 1. "B." spends days, weeks, or months researching a solution all by his lonesome. 2. "B." presents this idea to the team. It is effectively an edict, but he presents it as a meritocratic chance for others to offer feedback or alternative ideas. 3. The rest of the team is caught flat-footed, because we... just heard about this problem minutes ago, and obviously aren't as prepared as... well, somebody who has prepared. We are also not allocated time away from our scrums in order to research and test alternatives, whereas that was essentially his entire job. In other words, we bore the burden of proof and yet had no time in which to produce said proof. 4. I don't recall one of the edicts-masquerading-as-RFCs from "B." ever being successfully challenged. Management (who was non-technical) perceived this as evidence of B's superiority, because after all, it's not like folks had better ideas than "B." Since he structured things in a way such that folks really couldn't have better ideas. Eventually many folks on the team (like me) tuned out and just stopped participating in the whole charade after a few trips around the block. This, of course, was seen by management as more evidence that "B." was the only one with legit ideas.