• fubo@lemmy.world
    631·
    9 months ago

    Some other ways:

    Cultivate bitterness.

    Find the pessimists in your organization, and disappoint them.

    Make mean cynicism a part of your workplace culture. Do this by example: Promote mean cynics and put them in charge of things. But do it also by conversion: Behave in a way that makes mean cynics’ view of the world correct.

    Reward bad personal habits to create internal conflicts between work and health.

    If someone skips sleep to finish a project, give them a bonus. This gives them an internal conflict between approval and health, and teaches them that they can sacrifice their health to receive a reward.

    Encourage a hard-drinking culture in teams that have stressful roles that demand team cohesion, like SRE or Ops teams with on-call requirements. This gives them an internal conflict between their support network and health.

    If someone is sick, injured, bereaved, or otherwise suffering: Make it clear how much their condition is inconvenient to their coworkers, and how much their projects are impacted by their absence. Assure them that all will be well once they can conclude their personal problems and commit to the team. Do not, however, offer them any specific help; if they express specific needs for accommodation, disregard them as idle and unrealistic wishes.

    • porgamrer@programming.dev
      11·
      9 months ago

      Here’s one I learned from a past manager:

      Stress that everyone needs to pitch in and make themselves useful at all times, but do not share any information at all

      Make sure the work is not broken down into clear tasks. Make sure nobody else has access to the stakeholders. Make people ask separately for every single account or access credential they need, and respond with incredulity that they don’t already have it.

      Give the impression that there are no processes. When someone submits work, criticise them for not following the process.

      Each day, schedule meetings so you are impossible to contact until the early afternoon. That way you can interrupt any request for information by asking the person what work they did in the morning. The goal is to close the loop by making people scared to talk to you, so they blame themselves for not knowing anything.

      • fruitycoder
        3·
        9 months ago

        Mushroom management is an amazing way to break an org. Keepem in the dark and give them shit, and no one will feel comfortable accomplishing anything.

        Even better stress that things really need to get done, and why it’s critical that it happens, but constantly question whether that is something THEY should be doing.

  • SilverShark@programming.dev
    36·
    9 months ago

    I used to work with a guy who was a tech lead on a project. He was getting constant pressure that he app he lead simply did not work. The problem all came down to a database connection that was being used in multiple threads.

    I told him what the problem was. He said, great let’s make a meeting to talk about it. I wasn’t allowed to solve it just yet. I made the meeting. Everyone understood. The lead told me to then make a prototype, but still not allowed to just fix it. I made the prototype. The lead said we needed a meeting to talk about it. Still not allowed to just fix it.

    Meanwhile we still get pressured to make the damn app work, the lead keeps saying that none ever bothered to read documentation and that we need to sit down and talk about how we are going to to solve.

    This went on for several weeks. When I was finally allowed to solve the issue (not by him), I took only one day.

    • Maalus@lemmy.world
      7·
      9 months ago

      Should have just taken charge instead of going with the techleads thing. They aren’t the lord and master, they are a developer like you with a little bit of responsibility tacked on.

    • AAA@feddit.de
      4·
      9 months ago

      I hear you. It’s amazing how much some company’s code / projects is allowed to suck.

      Not even “my” tiny-little-side-module inside the project source recompiles within 20 seconds… because of absurdly complex and large dependencies to the actual project code.

  • jadero@programming.dev
    8·
    9 months ago

    In the spirit of “-10x is dragging everyone else down” I offer my take on +10x:

    It’s not about personal productivity. It’s about the collective productivity that comes from developing and implementing processes that take advantage of all levels of skill, from neophyte to master, in ways that foster the growth of others, both in skill and in their ability to mentor, guide, and foster the growth of others. The ultimate goal is the “creation” of more masters and “multipliers” while making room for those whose aptitudes, desires, and ambitions differ from your own.

  • bob@lemmy.worldEnglish
    3·
    9 months ago

    productivity is relative and requires a reference coordinate system. The best way to become a 10x engineer is to PK with a turtle team, but of course what the value is is another matter.

    Also, your productivity may not be significantly improved in certain environments. When every member of the team reaches the speed of light, you will find yourself impossible to be faster anyway. Setting a goal beyond the speed of light is contrary to science.

  • I Cast Fist@programming.dev
    21·
    9 months ago

    Is that Emil Pagliarulo’s (the actual man responsible for Starfield, more than Todd Howard) manual? It sure as hell looks like it.