GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-12-29) - page 1 of 10
 
___________________________________________________________________
Things I have learnt as the software engineering lead of a
multinational
196 points by kuahyeow
https://minnenratta.wordpress.com/2017/01/25/things-i-have-learn...
ave-learnt-as-the-software-engineering-lead-of-a-multinational/
___________________________________________________________________
 
scarface74 - 5 hours ago
Fire people whenever you can. There?s often someone to fire, but
not many opportunities to do so. When you are given a lot of
opportunities to fire peopleI like this. Put another way "we are a
team not a
family."https://www.slideshare.net/reed2001/culture-1798664
 
  pizzetta - 5 hours ago
  Companies like Netflix have the cachet and can retain people
  despite an anti-worker culture.  It's also a self selecting group
  of over-achievers who may like the environment.I'd argue most
  above average but not stellar workers would not put up with
  Netflix's implicit demands.
 
    sidlls - 2 hours ago
    It doesn't necessarily self-select for over achievers. It could
    very well self-select for people who don't recognize their own
    (flawed, not empirically justified) biases with regards to what
    "high performance" means. Most of that Netflix deck is the same
    kind of vague "we hire only the best" and "our values are (list
    of over-broad, meaningless but impressive looking jargon)"
    expressed in different words.
 
    [deleted]
 
    scarface74 - 4 hours ago
    I would gladly work for a place like Netflix for a year or two,
    bust my butt, put it on my resume and move on. My market value
    would make it well worth it.
 
  Xeoncross - 5 hours ago
  I'm not sure what to do with advice from someone named scarface
 
    yoyar - 5 hours ago
    It is a username and not relevant at all.
 
  cpeterso - 2 hours ago
  Company talk about "we are a family" is a red flag for a work
  environment where people may be pressured to work overtime ("it's
  more than a job; we're family.") or overlook inappropriate
  behavior ("that's just how Bob is; we can't fire him because
  family has got to stick together."). People on a team don't need
  to be "family" to be respectful and supportive of each other.
 
  junkscience2017 - 5 hours ago
  You have to be careful. I am currently in an org that has
  embraced this philosophy. Instead of making the survivors feel
  valued, it has motivated most of them to move into more stable
  environments. These employees have dependents and don't like the
  idea of having their health insurance in play on a daily
  basis.People read Glassdoor. If your company earns a rep for
  rapidly and casually dismissing people, you will see good resumes
  dry up. In our case, the quality of candidates has nosedived.
  It's not clear why a strong candidate would join a company that
  opts to fire people so casually.
 
    scarface74 - 4 hours ago
    On the other hand, if you feel you are a top performer and want
    to work with other top performers, you wouldn't want to work at
    a place with mediocre developers.A good developer is not
    necessarily one that knows everything but has competence and
    can learn fast. I've worked with smart junior developers and
    developers with years worth of experience that couldn't cut it
    when given a novel to them problem.
 
      AFNobody - 3 hours ago
      > On the other hand, if you feel you are a top performer and
      want to work with other top performers, you wouldn't want to
      work at a place with mediocre developers.This could just be
      because I'm a mediocre developer (1X) but:1) Mediocre
      developers have the ability to consistently produce all the
      basic non-architectural grunt work in a reasonable amount of
      time with a reasonable level of quality. Frankly, the "top
      performers" tend to want to work on high impact/high
      visibility projects and tend to shirk any grunt work they are
      given. (i.e. Even something as simple as a combo box that
      handles shipping I've seen "top performers" repeatedly f up
      despite me warning them and having to completely scrap their
      implementations. It isn't that the developer isn't a top
      performer, they just are not willing to do boring CRUD work
      and literally every "top performer" I've worked with does
      that. Management doesn't care because they deliver high
      quality results on other "new" things but basic maintenance
      work is simply beneath them both in attitude and the time
      they commit to the task.)2) Places that tend to focus on
      "just hiring top performers" tend to have trouble holding on
      to top performers as they are usually bribed into leaving if
      they bother to look around. Mediocre performers might take
      12-18 months to get bribed away when interviewing while
      working. Top performers tend to land a better offer in less
      than 3 months of interviewing. Places that hire mediocre
      developers can frequently throw $40k/year + a week of PTO to
      get them to stay. (i.e A top performer at my last job that
      I'm friends with got a $40k/year raise in cash, a week of PTO
      to guarantee they'd stay indefinitely.)3) Top performers are
      very good at being an architect, breaking new ground, and/or
      working on novel problems. They also tend to naturally
      prioritize high impact/high visibility projects. However,
      that often comes at the expense of doing routine work
      correctly and the long term maintainability/stability (as
      they frequently move on). I've found "Top Performer" is
      really code for "Person who focuses on getting involved on
      the highest impact project they can at any given time." And
      then end up resenting grunt work when such projects are not
      available to them.
 
        thehardsphere - 2 hours ago
        > This could just be because I'm a mediocre developer (1X)
        but:If you're mediocre as in average, that makes you 4x,
        not 1x. The 10x developer is 10 times better than the worst
        performer who is still employed, or 2.5x the median.I only
        point this out because lots of people get it wrong and end
        up unfairly underestimating their own competence.
 
          scarface74 - 2 hours ago
          If you can do competent work and add value to the
          company, you're already ahead of many developers, I've
          interviewed. Heck, you're already better than some
          "architects" I've worked with.
 
          AFNobody - 2 hours ago
          That is a fair criticism. :/I always tended to view "1X"
          as in "average" and then 10X as in "10X better than
          average" which I've seen happen in narrow competencies of
          a specific architecture/situation/business.
 
        dualogy - 4 minutes ago
        To anyone mildy deserving the title "performer", anything
        that sounds or smells like "grunt work" is merely an
        interesting candidate for (intelligent, self-contained,
        sustainable, documented of course) elimination-
        automation.This can greatly benefit all of a
        project's/product's stakeholders in the medium-to-long term
        --- assuming the organization allows fully for this
        "performer instinct" to flower --- just as any garage up-
        start and foss/hobby project naturally would. Sure: there
        are likely-potential pitfalls implied here, in terms of
        scheduling/billing/accounting for such work. (Guess that's
        the part where non-developer team members such as
        POs/PMs/etc actually get to put in some non-janitorial
        efforts! =) But never insurmountable, and the "let's just
        keep some code-monkeys for the grunt-work" workaround/cop-
        out is mentally-cheap-but-otherwise-costly --- at least as
        soon as all the rockstars have been gobbled up by a single
        competitor! (Admittedly, that never seems to quite happen
        like that.)
 
        KKKKkkkk1 - 2 hours ago
        I've found "Top Performer" is really code for "Person who
        focuses on getting involved on the highest impact project
        they can at any given time." And then end up resenting
        grunt work when such projects are not available to them.To
        me, it sounds like your company's definition of a top
        performer is someone who is good at gaming the system. I
        guess your company is not unique in that regard.
 
        barrkel - 2 hours ago
        Top performers have usually crept towards the high end of
        the salary available to them, and they're aware that grunt
        work isn't necessarily a good cost / value tradeoff for the
        company they're working for, nor a good tradeoff for their
        human capital vs income earned.If you're not being
        challenged in your job (i.e. doing grunt work), you either
        need to find a harder job within the company (it might be
        automating away grunt work), or failing that, a different
        company.
 
          AFNobody - 2 hours ago
          > If you're not being challenged in your job (i.e. doing
          grunt work), you either need to find a harder job within
          the company (it might be automating away grunt work), or
          failing that, a different company.Honestly, the only
          serious challenge I have in my job is getting people to
          do stuff in a maintainable, reliable way despite the fact
          it costs a little more in QA of the automation (or manual
          change control processes that IT frequently resists).
          Automation is not the right solution when human QA and
          manual intervention is an order of magnitude less
          expensive than the potential problems created by a non-
          technical user.You have to realize the only person who
          _really_ understands most heavily integrated systems are
          technical folks and automating abstractions to allow non-
          technical users to make sweeping system-wide changes is a
          bad idea (even if it is easier on IT).> Top performers
          have usually crept towards the high end of the salary
          available to them, and they're aware that grunt work
          isn't necessarily a good cost / value tradeoff for the
          company they're working for, nor a good tradeoff for
          their human capital vs income earned.The problem is, you
          can't always automate grunt work. For instance, matrix
          rate shipping is something that is (effectively) a
          business rule that is maintained manually across multiple
          systems. Someone, somewhere is going to have manually
          determine that business rule and apply it.Now, lets say
          you are crafty and you automate the f out of this process
          so they just have to type some values into a spreadsheet
          and upload it. Or a form. Or whatever.What happens if
          your validation is not 100% correct and you are relying
          on non-IT people to QA this update that impacts multiple
          systems?You lose $50k before the defect is fixed because
          instead of having someone who understood the impact from
          end to end dealing with it, you gave it to a business
          person who found a novel way to work around your
          validation to "make it work". The cost of annual, manual
          updates by a 6 figure salaried programmer would have been
          less than $5k a year.So the wise, automation oriented
          programmer fixes the defects in validation, writes some
          more unit tests, and so forth. Then, lo and behold, it
          happens a second time on Black Friday and you end up
          giving out 6 figures in $$ due to a "software error" that
          was due to a business person setting everything to $0.01
          because they misunderstood something.).Now, you might
          blame the business person but given this has happened for
          the Nth time before this person automated it...they
          should have known better and required some sort of manual
          validation step by QA/IT/whatever.Some things you really,
          really must have a manual sanity check on because of how
          critical they are and the business risk involved and
          automating it to the point you hand it off to someone
          else for minimal manual work is not the right
          decision.I've seen this with controlled substances,
          regulated products moving across borders, shipping, and a
          dozen other things. Non-technical people being handed
          powerful automated tools they don't 100% understand is
          not always the correct solution.
 
        scarface74 - 3 hours ago
        I agree with all of your characterizations. I couldn't
        spend year after year doing maintenance grunt work.
        Luckily, I get health benefits through my wife's job so I
        can jump back and forth between full time and contract work
        with abandon.I consider myself a "top performer".Yeah I
        know everyone considers themselves to be above average, but
        I'm the tech lead for my company so by job title and
        responsibility, I think I'm qualified to say that.But I
        guess I need a more nuanced opinion. I wouldn't want to be
        on a team where my peers are mediocre at this point in my
        career. There is a difference in my mind between a
        "mediocre" developer and an "inexperienced" developer. A
        mediocre developer is one that isn't where they should be
        in terms of competence and expertise based on their years
        of experience.Even worse, is an "experienced" developer who
        makes horrible architectural decisions.
 
          AFNobody - 2 hours ago
          > I agree with all of your characterizations. I couldn't
          spend year after year doing maintenance grunt work.
          Luckily, I get health benefits through my wife's job so I
          can jump back and forth between full time and contract
          work with abandon.I understand but
          maintenance/refactoring grunt work is technically
          necessary which is why I think going for 100% top
          performers is a bad hiring strategy for a business is
          all. Systems need to be refactored regularly to maintain
          business logic consistency between services, remain
          stable as the ecosytsem they communicate  with changes,
          and be secured.> Yeah I know everyone considers
          themselves to be above average, but I'm the tech lead for
          my company so by job title and responsibility, I think
          I'm qualified to say that.I believe you. I'm not here to
          argue ability, just the strategic merit of focusing on
          top performers.> But I guess I need a more nuanced
          opinion. I wouldn't want to be on a team where my peers
          are mediocre at this point in my career. There is a
          difference in my mind between a "mediocre" developer and
          an "inexperienced" developer. A mediocre developer is one
          that isn't where they should be in terms of competence
          and expertise based on their years of experience.Ah, and
          I think this might be a miscommunication partially as
          well.To me there are basically 4 buckets of developers:1)
          Top Performers (2X+ Developers. Highly skilled but tend
          to focus on personal growth. Tends to ignore long term
          pain points because they just will not be there that
          long.)2) Mediocre (.75-1.5X Developers who should be used
          to do the non-architectural grunt work and refactoring.
          They tend to want to stick with an employer long term and
          tend to focus on medium to long term effectiveness
          because they'll feel the pain of deviation from that.)3)
          Incompetent Developers (Experienced developers with
          little to negative net value who probably should really
          be looking for a new career. Or anyone who else who is
          substantially below the Mediocre range for their
          experience level / pay expectations. )4) Inexperienced
          Developers (Little to negative net value who will
          probably need a couple years experience before you really
          know if they are a top performer or mediocre.)> Even
          worse, is an "experienced" developer who makes horrible
          architectural decisions.That is probably the single most
          painful experience in every software developer's career.
          Poor architectural decisions that cannot be properly
          refactored due to budget constraints. The number of times
          I've seen an incompetent developer break primary keys
          during a system integration/transition is too numerous to
          count.
 
        scarface74 - 2 hours ago
        If you're not being challenged in your job (i.e. doing
        grunt work), you either need to find a harder job within
        the company (it might be automating away grunt work), or
        failing that, a different company.Now I'm going to play
        devils advocate. What's wrong with doing grunt work and not
        being challenged? I know people who have been at the same
        job for 20 years maintaining the same system and not being
        challenged. They work their 40 hours a week, love the
        familiarity and stability, and go home.I would die a
        thousand deaths doing that but sometimes I wish I had the
        type of personality that could deal with that
        lifestyle.Realistically though, couldn't people say the
        same about me? I'm about 10% below the top salary I can get
        without going into management in my market. I should hit my
        top salary in about two years, except for cost of living
        raises. I'm okay with vertical moves being a "Senior
        Developer", "Architect", "Team Lead", "Consultant", etc.
        Some people would say why don't I want to be a manager or
        start my own company.
 
      majormajor - 3 hours ago
      IME there's a fine line to balance between burning out your
      best people and over-pressuring them, vs being too
      accommodating of adequate-to-good people more interested in
      protecting their own turf/stability or playing political
      games than in getting the product as good as possible. In my
      ideal world I'd rather be in a pay-for-output-quality (not
      pure quantity or attention-getting) higher-pressure-but-not-
      insane-hours environment than in the latter, but sadly that
      doesn't seem super common.The most frustrating problem for me
      is "top performers" who are very technically knowledgeable,
      so seen as stars by their direct managers, but have zero
      interest in any solutions that they don't directly design
      themselves, and little interest in taking feedback or
      admitting that their internal mental roadmap isn't 100%
      perfect.
 
    BeetleB - 4 hours ago
    His statement could be read both ways. If you keep low
    performing people, it can suck the life of the team. I've
    personally seen teams where the top people lower their
    standards and outputs because they have low performing members
    in the team, and if the management doesn't care enough about
    the impact they have on the team, they will not work hard to
    make a good product.OTOH, I do think firing is a bit of a last
    resort. A lot of people can be coached to perform better. I
    support firing as a last resort when other reasonable methods
    have failed.
 
      scarface74 - 3 hours ago
      I thought "coaching" was the answer to. I came in as a tech
      lead where one "developer" hired by a previous regime didn't
      know how to write a JavaScript function and just couldn't
      logically figure out how to debug an issue and the other just
      couldn't focus on a problem and went way out in left field on
      the simplest tasks.We got rid of both of them as part of a
      "restructuring". I've had to cut a few contractors short
      because they just couldn't handle what for all intents and
      purposes was a startup environment where everything was up in
      the air and we needed people who could adapt, figure things
      out, and learn fast without holding their hands.In a place
      like Netflix, everything is brand new. No one in history has
      ever had to deal with the scale that they have to.
 
    troels - 5 hours ago
    Surely. (Too many) firings have a negative impact on morale.
    Especially if not done once. I think the point being made
    though is that it is very uncomfortable to fire people, so
    managers tend to avoid it, even if it's the right thing to do.
 
      scarface74 - 4 hours ago
      That was the problem at Yahoo. It's better to have one mass
      layoff and be done with it instead of having multiple small
      layoffs.
 
        ralfd - 3 hours ago
        Yahoo had a hundred other problems.
 
          MBCook - 1 hours ago
          Ive been at a company with multiple rounds of small
          layoffs. Each time they didn?t want to cut too deep or
          thought ?maybe this will be enough?. It wasn?t.It was a
          total moral DISASTER.If you need to cut, cut. But
          multiple layoffs will kill you.
 
knieveltech - 1 hours ago
"Being overworked is not a good reason to hire."Because the world
certainly needs more sociopathic management advice.
 
  claudiulodro - 1 hours ago
  Theoretically, it might not be a good reason to hire. Maybe the
  problem is bad planning or project management. Hiring more people
  won't really solve that.But, in general, I agree with you.
 
  jayd16 - 1 hours ago
  Rereading the advice, I think he means hire before you get to
  overworked.  I agree it's phrased poorly.
 
  egor598 - 1 hours ago
  The way I understood this:  "If you are overworked, first look at
  your team, is everyone at their place and pulling their weight,
  evaluate your deadlines and promises, check your planning and
  management and your relationship with stakeholders. Because most
  of the times it's one of those things that's broken and probably
  affects the rest".
 
cjcenizal - 5 hours ago
Point 1 resonated with me (and its value outweighs that of the
others by an order of magnitude IMO):> When the plan is foggy,
that?s the moment to communicate as broadly as possible. In fact
you should not frame it as a plan, you frame it as the situation
and the final state you want to achieve. When you have a detailed
plan, that?s when you DON?T need to communicate broadly. So,
clearly state the situation and clearly state the foggy goal to
everyone who will listen.This is a great way to clarify a complex
problem, draw out and resolve disagreements in understanding,
enlist others? help, and methodically arrive at the optimal
solution. It also works well for all kinds of problems, whether
they be engineering-related, organizational, or interpersonal.
 
  abraae - 4 hours ago
  This really is an exceptionally good article, written by a
  pragmatic and insightful student of working life.I have often
  experienced the following but could never have described it as
  elegantly:> Incompetence is fiercely gregarious while knowledge
  is often fractious; the reason for this is that raw ideas
  transfer more easily through untrained minds than refined ideas
  transfer through trained minds. There?s a reason why large
  organisations focus so much on simple messages, pity that
  difficult problems often have simple solutions that don?t work.
 
KKKKkkkk1 - 5 hours ago
There are some very rare cases where delivery date is more
important than what you are delivering, but modern management seems
to delight in generalizing this unusual occurrence to every
situation. People do get promoted for having been able to deliver
completely broken, useless and damaging solutions on time. If
that?s the measure of project success you can expect dates to rule
(even when they continuously slide). After all, if you are not a
trained surgeon, and the only thing you are told is that a given
surgery should last no more than X hours, guess what will be the
one criterium for all your actions during the operation.I love that
metaphor.
 
  mbesto - 2 hours ago
  FYI - They use the same metaphor in Mythical Man Month and it's
  very apt.
 
  crocal - 5 hours ago
  Yeah but not all things are like surgery. Often, ? A good violent
  attack now is better than a perfect one next week ? (George S.
  Patton)
 
    lj3 - 3 hours ago
    That doesn't apply to software development unless you're a
    startup with limited funding and no positive cash flow. In the
    vast majority of cases, the software is already released and
    making money. Whether you finish the next release in 1 month or
    2 is of no practical importance, except that it makes the
    manager look good. He can report a larger profit margin because
    the cost that went into that release is roughly half if it was
    released in 1 month rather than 2.And therein lies the conflict
    that this post doesn't really address or resolve: there's
    rarely a discernible difference in revenue between a high
    quality release and a buggy, low quality release, but the
    profit margin of the former can be (and often is) much lower. A
    great real world example of this is PUBG.
 
      jayd16 - 1 hours ago
      As long as you completely ignore the cost of technical debt
      and bug fixes, sure.
 
        lj3 - 1 hours ago
        All projects have tech debt and bug fixes. If there was a
        surefire way of obliterating both of those things
        consistently, it would be an easy sell to management. But,
        because there isn't, they fall back on what they can
        measure: costs vs revenue.
 
      Negitivefrags - 55 minutes ago
      Since you picked a gaming example, I would like to present
      the idea that in gaming the opposite is true.If you have a
      live game that you intend to last a long time, it?s extremely
      important to establish a reliable release cadence that the
      players can depend on.Our company first released our game in
      2012. After release we didn?t know how important this is. We
      just kinda made updates and released them when we finished
      them.The player numbers never went above what we had at
      release. For a few years our numbers were pretty flat. We
      would have up releases and down releases but we never broke
      our initial numbers.Then we changed to a cycle of having a
      release every 3 months.This was a massive improvement. Most
      players won?t keep playing your game continuously forever,
      but if they always know that there will be a thing to come
      back for, and when that will be, they will stop playing
      before they are burned out with a plan to come back.Suddenly
      our numbers grew with every release. Each 3 month cycle saw a
      large percentage increase over the previous one.After a few
      years of that our game is massively larger than it was at
      release, and it?s still growing with each subsequent
      release.I?m not saying that it?s okay to release a buggy
      game, you have to scope each release so that you can do it on
      time without being too buggy. What I am saying is that the
      release schedule is actually really really important.
 
      shandor - 2 hours ago
      > there's rarely a discernible difference in revenue between
      a high quality release and a buggy, low quality release, but
      the profit margin of the former can be (and often is) much
      lower.A wonderful insight, thanks.I guess that hints in a
      direction where "both are Right". For the technical teams,
      it's self-explanatory that "one does not simply push out
      crap". On the other hand, the MBAs and finance hear
      engineering say the same thing about mostly everything, and
      double profit margin is double profit margin, so the
      incentive structures that encourage faster releases probably
      seem completely plausible to them.Not that things are that
      clear and clean in real life. But having drifted from pure
      engineering to engineering management during the years, I
      feel more and more sympathy towards some of the challenges of
      the "ugly and evil business side" by the year. Also, nothing
      is as hard as communication. Except trying to communicate
      goals with broad incentive structures, I guess.
 
      brucephillips - 1 hours ago
      > Whether you finish the next release in 1 month or 2 is of
      no practical importance, except that it makes the manager
      look good.No, it also increases value to the customer, and
      therefore price. It also helps you stay ahead of the
      competition, also increasing price.Can you elaborate on PUBG?
 
        lj3 - 1 hours ago
        > it also increases value to the customer, and therefore
        priceNot always. Look at the most recent OS releases.
        Windows 8 and 10 had terrible adoption rates because they
        actually deliver a negative value for most users compared
        to what they already own (windows 7).> It also helps you
        stay ahead of the competition, also increasing price.Again,
        not always, for the same reasons mentioned above.> Can you
        elaborate on PUBG?From a technical point of view, PUBG is a
        train wreck. They had budgeted a 1 year development cycle,
        which for an online 3d FPS is ridiculously short. I think
        they initially launched it after a year and a half of
        development. But, from a sales point of view, PUBG has been
        very profitable. People are playing it despite the
        networking problems and relatively bad graphics because it
        fills a niche that hasn't been addressed by other game
        companies in years. But, there was no guarantee it would
        have been a hit. The condensed timeline and less than
        stellar graphics was their way of keeping development costs
        low. If the game hadn't been an instant hit, they could
        have still made a profit.
 
          brucephillips - 56 minutes ago
          PUBG is an example of how low quality releases can be
          profitable, not how "there's rarely a discernible
          difference in revenue between a high quality release and
          a buggy, low quality release"
 
          [deleted]
 
          chickenfries - 32 minutes ago
          Go back and read the sentence you quoted, in it's
          entirety.> there's rarely a discernible difference in
          revenue between a high quality release and a buggy, low
          quality release, but the profit margin of the former can
          be (and often is) much lower.I think you agree with the
          OP...
 
          brucephillips - 28 minutes ago
          No, I don't. I don't believe there's rarely a difference
          in revenue between a low quality release and a high
          quality release. Further, PUBG, at least as presented,
          doesn't support this assetion, since it doesn't show
          revenue failing to increase after a higher quality
          release.
 
    junkscience2017 - 4 hours ago
    Patton's strategy was borrowed from his inspiration...Sherman.
    The goal was to make war intensely in order to end it quickly
    and let his soldiers return to their lives. Software
    development is not war.
 
      CapitalistCartr - 3 hours ago
      Business often is, though.
 
        jschwartzi - 3 hours ago
        Business never ends though. If you spend all your time
        making business intensely, you will burn everyone in your
        business out.
 
          brucephillips - 1 hours ago
          The metaphor extends further, actually. The "war" of
          business ends once a market consolidates.
 
      scirocco - 3 hours ago
      It is, if you ask Ben Horowitz
 
    qq66 - 5 hours ago
    And, plenty of surgeries are done in situations where speed
    matters more than the quality of the surgery (emergency
    tracheotomy, amputation, etc.)
 
      dvt - 3 hours ago
      Speed never matters more than the quality of the surgery.
      You're conflating constraints and criteria. Speed is
      sometimes a constraint, but never a criteria.
 
        stefco_ - 1 hours ago
        But speed is a self-imposed constraint on most projects
        rather than a physical law, meaning it might be violated.
        Furthermore, there might be a smooth relationship between
        speed of execution and value returned (even outside of cost
        of production). So when evaluating how successful a project
        was (software, surgery, or otherwise), you often do want to
        use speed as a criterion, even if you initially thought of
        it as a sort of constraint for the sake of simplifying
        planning.
 
        brucephillips - 1 hours ago
        Constraints are criteria.
 
          dvt - 46 minutes ago
          No they aren't. Constraints are necessary but not
          sufficient. Criteria are necessary and sufficient. In
          other words, necessity is a lower bound and sufficiency
          is an upper bound. Criteria is the upper bound,
          constraints are the lower bound.[1]
          https://www.sfu.ca/~swartz/conditions1.htm
 
          brucephillips - 37 minutes ago
          You're also confusing an equality and a subset
          relationship.
 
          zbentley - 1 hours ago
          No, they're not.If you violate a constraint, delivery
          fails. If you pass it, delivery does not necessarily
          succeed.If you fail to meet a criterion, delivery might
          fail. If you successfully meet all criteria, this is the
          definition of successful delivery.Different places may
          assign different meanings to those terms in project-
          management speak, but those are the ones I've heard the
          most.
 
          brucephillips - 1 hours ago
          You're confusing an equality relationship and a subset
          relationship.
 
    sebcat - 1 hours ago
    "It is even better to act quickly and err than to hesitate
    until the time of action is past"-- Carl von Clausewitz (On
    War?)
 
  euroclydon - 4 hours ago
  Where I work, we deliver on time. Customers schedule upgrades
  many months in advance, and in series or sync with other
  upgrades. They are on maintenance contracts to get the latest
  version.If we deliver a broken product, than that is a failure to
  cut scope adequately. Do that once or twice and suffer through
  the consequences and you will learn not to let it happen again.
 
    [deleted]
 
    [deleted]
 
    jjoonathan - 2 hours ago
    Moving a feature into the next release cycle is equivalent to
    extending the deadline for that feature. You're right, though
    -- management does seem to have a strong preference for one
    terminology over the other.
 
      euroclydon - 1 hours ago
      That?s true, but if the product is big enough, with enough
      varying constituencies,  then delivering something to a large
      chunk of those people on time is a lot better than delivering
      nothing to everybody on time.
 
        tfigment - 29 minutes ago
        I think there is a lot of "it depends" in here. If
        deployment is zero friction to the customer then maybe this
        applies.  If deployment by customer is disrupting then
        forcing them to go through multiple release cycles due to
        bugs or lack of required features can be worse for them.I
        just lived with a half-broken product for a year rather
        than deploy the more final full featured but less stable
        version multiple times from a vendor due to such deployment
        difficulty.  I want quality and completeness over speed in
        that case.
 
  tyingq - 38 minutes ago
  Deadlines do matter in many situations.  Like, for example, being
  able to announce a new product or feature at a conference with a
  fixed date.  Or before a sales meeting with a new client, or
  before a yearly allocated budget expires, etc.I have, however,
  also encountered arbitrary deadlines that people hang onto for no
  good reason.
 
lifeisstillgood - 1 hours ago
Interestingly he (she?) seems confused and rage driven (!) over
entropic organisations - i think the main issue with entropic
organisations is simply size - there is no organisational approach
that can ever make hundreds of thousands of people co-ordinate in a
positive manner.we don't lack the technology, just that there is no
good strategy at that level.
 
egor598 - 1 hours ago
>>Construction work is not a good metaphor for software/product
development. Factory work neither.I like this, really fed up with
everyone comparing software development with construction work
and/or building a house. Don't compare those, apples to oranges.
Sure, borrow the best, most appropriate things, techniques,
methodologies, approaches and not just from construction. Just
don't compare.
 
hkarthik - 4 hours ago
> Incompetence is fiercely gregarious while knowledge is often
fractious; the reason for this is that raw ideas transfer more
easily through untrained minds than refined ideas transfer through
trained minds.This resonated with me and definitely gave me food
for thought. Raw ideas with uninformed opinions can easily
percolate throughout organizations and even across the industry.
Feels like something we as a society need to more actively guard
against.
 
  dboreham - 3 hours ago
  I think this explains a great deal and was a concept I had been
  mulling over myself recently: basically there's an asymmetry in
  clueffulness that works to propagate cap around much more widely
  than you'd expect.
 
sam0x17 - 3 hours ago
Thing one: use "learnt" instead of "learned" to sound
multinational. ;)
 
crocal - 5 hours ago
I have to disagree slightly on the paragraph about dates (#32).
Engineers leaders cannot dismiss dates as one of the metric of
their performances. The metric is not the goal nor the means in
itself, though. In my view, entropic organization and management
make this mistake constantly of confusing the metric with the job,
like driving a car looking at the speed meter and not at the road
(sounds absurd, I know, but is really what happens).
 
  marcosdumay - 5 hours ago
  I have to completely agree with that paragraph. As long as we are
  talking about metrics, impact is the one to measure.Ok, if you
  already are measuring impact and has a correct prioritization of
  it above anything else, adding delivery date and time spent won't
  hurt. But if you don't prioritize it above anything else, you are
  simply begging for a huge failure.
 
  yoyar - 5 hours ago
  For a competent team, arbitrary dates, generally leaving not
  enough time, only serve to limit scope. A competent team will
  produce as fast as is possible, given a specified scope.
 
  troels - 4 hours ago
  Agree. Dates are good for limiting scope. Without that
  constraint, it is usually very hard to set boundaries as to what
  should and what shouldn't go into a project. There is also
  validity to the notion that time is money. Eventually, we'll all
  be lying in our graves.But yes - for measuring success, it's a
  terrible metric. One should prefer a project to be delayed, but
  proper, than delivered on time, but broken.
 
BeetleB - 4 hours ago
>Mass emails and top-down communication are not taboo: just because
most such communications are irrelevant it doesn?t mean yours will
be perceived as such.Mine are always perceived as such :-(
 
  tinymollusk - 3 hours ago
  Have you considered studying how you communicate?  There was
  something on HN recently titled How to write emails like a CEO
  (or similar).I studied my old CEO's communication style, holding
  it up against how many of my peers communicated.  I noticed that
  he got right to the point, expecting other people to assume he
  considered multiple ancillary points.  My (lower status) peers'
  emails would meander, and read like they wanted to show their
  superiors how good/smart they were at their job, and that they
  thought of every last thing.The high status person didn't feel
  the need to pre-emptively brain dump.My larger point is if your
  emails are perceived in such a way, it's worth improving.
 
    asafira - 1 hours ago
    Along similar lines: I often write an e-mail with all of the
    information I want to include, and read it over and edit it
    several times to cut down on things that aren't necessary. The
    unnecessary things can be as simple as an awkward prepositional
    phrase, but often they are a technicality that is hogging too
    much space in the e-mail.I personally think this really
    improves my communication. In a workplace where people are
    expected to read through dozens of emails each day, it makes a
    difference in the information that's finally conveyed to my
    colleagues, which is often what matters the most to me.
 
busterarm - 5 hours ago
All of the comments about entropic organizations ring true and hit
close to home.  Way too close to home.
 
  marcosdumay - 5 hours ago
  The idea that entropy works on the direction of "hard work ->
  easy work", instead of "complex work -> simple work" or even
  "more work -> less work" is a great insight.
 
cbcoutinho - 5 hours ago
I'm a bit confused by the authors use of the words entropy and
entropic, starting specifically with this point:> Don?t let entropy
get at your daily routine. Avoid entropy-driven workIn a physical
sense, my understanding of entropy is that it's a degenerative
phenomenon, a lowest common denominator - it doesn't create
anything. This point means avoiding distracting or sporadic work,
which is a test of discipline. But the rest of this point and
others further down using words like 'entropy-driven' work are
meaningless.I'm sure there's a good point to be made here about
valuable work in large corporations, but the (over)use of the word
entropy has lost me.
 
  foobarchu - 4 hours ago
  Entropy is the measure of disorder in a system, so my
  interpretation here was that you shouldn't take on work that was
  generated by organizational disorder. An example I have in mind
  is when someone on the product side asks for a new feature that
  you know wouldn't take much time at all. Even though you could
  knock it out quickly, the correct action is to have them go
  through proper feature request channels.
 
riffraff - 5 hours ago
OT, but: funny, I felt the name was familiar, and turns out I
commented on a post on this blog 12 years ago[0].  A reading lost
due to the death of google reader, I presume.[0] How time flies!
https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-...
 
zbentley - 2 hours ago
>  Teams don?t self-organize unless you organize them to do
so....or, teams self-organize unless you have organized them not
to, in which case, if you want them to self-organize, you have to
hire an Agile coach and start putting up posters telling people
what it means to be "self directed" and fire everyone who is
insufficiently short-term in their thinking./s
 
scrame - 4 hours ago
"When the plan is foggy, that?s the moment to communicate as
broadly as possible."Here's a good rule of thumb: Ask them to
explain what has to be done, and then count the number of times
they say "it should be pretty straightforward".Consider those
multipliers of complexity.
 
  TheAceOfHearts - 1 hours ago
  Relevant XKCD [0].Lots of topics vary wildly in complexity,
  depending on what's actually expected of the developer. For
  example, I could see how implementing an authentication system
  might take as little as a few hours to as much as a few months.I
  think developers sometimes get overconfident when they can just
  reach for a library to do anything they need, so they
  underestimate the complexity of having to implement everything
  themselves. I've seen tons of great examples of this while doing
  frontend work. Need a typeahead component? Just pull in some
  plugin or library and wire it up, frontend development is so
  easy! But if you actually go implement your own you quickly
  realize there's lots of details to consider in order to make it
  accessible and user-friendly. Working with local data? Might want
  to go brush up on search algorithms. Throw in a bit of extra fun
  if you need to support multiple languages.[0]
  https://xkcd.com/1425/
 
    aphextron - 1 hours ago
    It's funny that with easy to use CV libraries like TensorFlow
    nowadays this cartoon has lost it's edge, although the point
    stands.
 
      jtmcmc - 48 minutes ago
      it's funny because that was from 2014 - so he was just off by
      a few years
 
  jschwartzi - 3 hours ago
  Or measure how annoyed they are when you ask them to go into
  specifics about what they expect.
 
  dudul - 4 hours ago
  I apply a similar algorithm, except I use the word "just" as
  variable.  As in "we could just stick this in a DB", or "isn't it
  just about adding a checkbox to the page?"
 
    zitterbewegung - 3 hours ago
    Using Just and extremely easy should be where you make a
    milestone for each statement(s) after that .
 
  qaq - 1 hours ago
  This. +500 The devil is always in the details something that
  sounds obvious but yet is hard to express clearly by PMs will
  def. be the thing that takes a while to implement (and more
  importantly to get all stake holders to agree on what "it"
  actually is)
 
AnimalMuppet - 4 hours ago
Teams don?t self-organize unless you organize them to do
so.Interesting.  I wish there was a bit more detail on how you
organize them to do so...
 
  com2kid - 1 hours ago
  Seating arrangements. Be it putting people who work well together
  in adjacent offices, or on adjacent tables.Giving people freedom
  and allowance for failure, not having a strict "I am the boss"
  micromanaging  hierarchy on the team.Reward people for taking
  initiative. Find work that people want to do, and give them time
  to do it on their own but only if they self organize all of it,
  this builds necessary skills.Taking someone who looks like they
  may have leadership potential aside and asking them to take on a
  small feature.Combine all these together and you'll come in one
  day and find your team in a huddle tackling tasks
  together.Requirements: Not being an insecure manager. Knowing
  that your value to the team and org is not in telling people what
  to do, but rather in helping them do what needs to be done.
  Sometimes this means communicating directives from on high, other
  times it means getting the team the resources that they've
  determined they need.
 
Bahamut - 5 hours ago
> Being overworked is not a good reason to hire. Instead, hire to
be ready to catch opportunities, not to survive the current
battles.I disagree - if you have overworked people, that is usually
a red flag that you need more personnel and planning failed. It
doesn?t necessarily mean you should be hiring right at the moment,
but it is a significant alarm bell that you should seriously
consider starting to hire or you?re going to chase away engineers.
 
  AnimalMuppet - 4 hours ago
  You either need more people or less work.  And having too much
  work may be because the organization has lost focus on what
  really matters, and is trying to do everything.  You cannot hire
  enough people to solve that problem, because as you add people,
  management says "great, now we can do even more..."
 
  foobarchu - 4 hours ago
  I think what he was going for was that you shouldn't solve the
  overworked problem with hiring. It indicates you need more
  manpower, yes, but it's also indicative of planning and resource
  allocation problems that need to be solved first. Adding more
  people before you solve those problems will probably make things
  worse. Things need to be properly divided and conquered, some
  things may need to be put on the back burner. It often indicates
  that you haven't split up the workload into manageable pieces,
  and are instead trying to get it all done at one time.Someone
  might now jump and say 'sometimes crunch time is necessary!', and
  I would reply that if you're in crunch time you've just
  demonstrated the exact issue I'm describing.I think he's
  essentially restating 'the mythical man month' for a modern
  environment.
 
    Bahamut - 4 hours ago
    But similarly, quickly coming to the conclusion to not hire is
    just as fallacious.If someone burns out as a result of the
    bungled planning, then the project can potentially be doomed
    without hiring (or even doomed anyway) - one should almost
    immediately reevaluate when one comes into this situation
    unless there was some sort of agreement beforehand.
 
  junkscience2017 - 4 hours ago
  "18.  Don?t shy away from leading without doing, it is
  unavoidable, so just do it. Then do some work to stay
  pertinent.19.  If you are not able to hire and fire people,
  leave. Or stay for the retirement fund if you can stomach it."the
  way the author discusses people and pretty much everything in the
  "Yourself" category makes me think this unnamed multinational is
  a sweatshop overseas. I've worked (temporarily) with people who
  try to bring this thinking to Silicon Valley
 
    sidlls - 2 hours ago
    I got the same sense as you, but without the "overseas" bit. We
    have sweatshop software shops in the US (look in just about any
    AAA game company, for example).
 
    MBCook - 1 hours ago
    I took #18 as ?don?t be afraid to delegate, you don?t have to
    have your finger in everything.#19 makes sense me to too. If
    you can?t hire/fire then you?re not really in charge. How can
    you manage your team if other people have the ultimate veto on
    your strongest management options?
 
  ptero - 4 hours ago
  >> Being overworked is not a good reason to hire. Instead, hire
  to be ready to catch opportunities, not to survive the current
  battles.> I disagree - if you have overworked people, that is
  usually a red flag.Overworked people is a red flag indeed, but it
  is usually a symptom of a deeper problem that is unlikely to be
  solved with more hires. I think the author hits the nail on the
  head here -- first and foremost hire for future opportunities.
 
    MBCook - 3 hours ago
    Agreed. At a previous (small) job the IT department was VERY
    overworked. They tried to hire to fix it and it didn?t work.
    Because it wasn?t the problem.The problem was unsustainable
    methods of doing everything. Every job was unique for no good
    reason. It was all managed by hand, monitoring monitored the
    wrong things.Each existing thing generated a ton of work due to
    how it was setup and required constant tweaking. Any new thing
    just piled additional work on, often causing issues with what
    already existed.Because of the lack of any kind of system or
    useful documentation new employees only made things worse as
    they tried to understand what existed, had to ask constant
    questions, or failed to take into account hidden gotchas that
    they had no way to watch out for.Until they started
    standardizing and stabalizing the base things couldn?t be
    improved.Yes there are times you have 10 developers worth of
    work and 5 developers. But there are times you have 4
    developers worth of work and 6 developers worth of mess they
    have to tip-toe around, but only 5 people.
 
    hashset - 4 hours ago
    Perhaps the deeper problem is the lead who committed to the
    deliverables isn't doing a good job and should be removed.
 
    geezerjay - 3 hours ago
    > Overworked people is a red flag indeed, but it is usually a
    symptom of a deeper problem that is unlikely to be solved with
    more hires.Not necessarily. Accepting a new project or extra
    responsibilities in exchange for a generous sum may increase
    your company's workload unexpectedly, which leads to overworked
    people while the company struggles with the hiring process.
    Another example is losing a team member right before crunch
    time.
 
      ptero - 3 hours ago
      Sure, there are exceptions. For example, I do not see a team
      flying out for a 2 60+ hour week test campaign as a red flag
      as long as the participation is mostly voluntary and the team
      gets an ample opportunity to detox after the fact.The
      exceptions, for me, have three key properties: (1) they are
      temporary, (2) overworked people know that it is temporary
      and have a clear (maybe not 100% realistic) date for return
      to normalcy and (3) this state of affairs is seen by most of
      the team as acceptable at the moment: not pleasant, but
      bearable and probably least bad of all options.If (1) and (2)
      hold, (3) is usually easy to achieve with sweeteners: $x
      bonus, T extra vacation, etc. But break either of the three
      and you have a clear red flag. Just my 2c.
 
  AcerbicZero - 2 hours ago
  Almost every military metaphor in this piece fell flat for me,
  but this one might have been the worst of the bunch. Not only is
  it a forced metaphor that barely fits the point being made, it's
  not even a particularly good point.
 
  nottorp - 5 hours ago
  That's about where I stopped reading.
 
asafira - 1 hours ago
Most people are commenting on what bullet points they agreed or
disagreed most with. I am sure, however, that there are other
software engineering leads on HN --- what other lessons have you
learned, and/or what were the best resources to learn them (if not
just experience).
 
rasta78 - 1 hours ago
Looking at things related to Entropy I can can clearly see the
company I'm working for(which is sad).Considering that I'm not at
leadership position, my next action is to quit and find a better
one.
 
  MBCook - 1 hours ago
  It really resonates with me and a job I used to have too.