[HN Gopher] Individuals Matter
___________________________________________________________________
Individuals Matter
Author : benfrederickson
Score : 702 points
Date : 2021-11-16 01:02 UTC (21 hours ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| Gentil wrote:
| Interestingly enough, the pay for these individuals differ too.
| And this matters as well. We should be taught to negotiate. This
| is the most underrated thing our industry and seniors don't tell
| juniors of the field.
|
| I learned this the hard way. After 5 years when the company was
| winding down, I learnt 5 colleagues of varied gender and race who
| were my colleagues were paid shit ton more than me. I know this
| is a sensitive topic. But if you ask, they will pay more or you
| will know how much you are worth. I thought the system will
| acknowledge and reward accordingly after I got a surprising
| bonus. IT DOES NOT. You have to fight for it. I felt really
| betrayed. And this is when everyone told me how and when to
| negotiate.
|
| From the moment you are hired, you bargain for a better pay. That
| itself, from that starting period itself, your pay differs
| compared to the other person who may have been hired with you.
| Then not everyone takes the same effort (they can't or don't want
| to for varied reasons). But some people do a 9 to 5, the other
| people does late nights, some people are dettached from company
| and it's vision, some are are very loyal. It depends on
| individuals and their circumstances.
|
| Handling everyone the same way doesn't work. This discourages
| people who want to put in more effort. So they jump ship and move
| to another company for a better pay. No person want the same
| amount of pay, they all want more. And the answer is negotiate.
| And ditch and make some noise on companies which have stereotype
| pay. Trust me. It is not the right place for you to work.
|
| Imagine this, giving $1 million dollar to ten people and see how
| much money they all have after a year. It will all be very
| different for each of them. It will not be the same amount. That
| is the same for salaries, you salary at this point are based on
| how much you worked and how much you bargained. It won't be the
| same for another person with same experience and same background.
| It just won't be.
| hamburga wrote:
| This conversation makes me wonder: has there been any halfway
| decent quantitative research on estimation methods?
|
| I've lived through what seems like the de facto agile standard:
| you take some piece of work, and estimate it out according to a
| point scale, assuming the "average" dev does the work.
|
| Curious to know now if it has any effect on project timeliness.
| Or are these estimates generally "vanity metrics" in practice?
|
| Anecdotally, they are generally pretty useless for planning
| unless they are at a very fine grained level, with low
| complexity, on an extremely well-understood piece of software.
| hunglee2 wrote:
| > A similar thing happens with retention. A great engineer I know
| who was regularly creating $x0M/yr4 of additional profit for the
| company per year wanted to move to Portugal, so the company cut
| the person's cash comp by a factor of four, causing them to leave
| for a company that doesn't have location-based pay. This was
| escalated up to the director level, but that wasn't sufficient to
| override HR, so they left. HR didn't care that the person made
| the company more money than HR saves by doing location
| adjustments for all international employees combined because HR
| at the company had no notion of the value of an employee, only
| the cost, title, level, and location5 <
|
| This is overall a brilliant post by Dan (as usual) but in this
| case he is harsh on HR; there is also a cultural cost on breaking
| salary structure for exceptional individual contributors -
| everyone else gets upset and threatens to leave. HR needs to
| calculate this, which is more likely the motivator rather than
| saving a few dollars here and there on a single individuals
| salary.
|
| Individuals matter, but in exaggerating the point, he has
| neglected to consider teams / groups matter also.
| Tycho wrote:
| I suppose the opposite of all this is Guns'n'Roses taking ten
| years to record _Chinese Democracy_ because Axl Rose wanted to
| hire a pro skateboarder to do mixing and stuff like that.
| slantedview wrote:
| From the article:
|
| > People, as a whole, cannot be treated as an abstraction where
| the actions company leadership takes impacts everyone in the same
| way. The people who are most effective will be disproportionately
| likely to leave if you turn a knob that leads to increased
| attrition.
|
| Damn correct.
|
| An observation of mine is that a company may recognize the most
| valuable employees in informal ways. For example, they may have
| some peer recognition awards that the same employees get because
| their peers know how valuable they are, but due to other
| constraints (ex, politics) they may not hold a title/level that
| represents this. When the company turns the nob, as Dan says,
| these most valuable people are the first to leave. Management is
| mostly oblivious, but the other engineers know.
| AussieWog93 wrote:
| This is a really interesting and enlightening article that covers
| an important topic, and it's honestly sad that it will get less
| engagement than some clickbait or hot-topic issue.
| [deleted]
| 908B64B197 wrote:
| > A similar thing happens with retention. A great engineer I know
| who was regularly creating $x0M/yr4 of additional profit for the
| company per year wanted to move to Portugal, so the company cut
| the person's cash comp by a factor of four, causing them to leave
| for a company that doesn't have location-based pay. This was
| escalated up to the director level, but that wasn't sufficient to
| override HR, so they left. HR didn't care that the person made
| the company more money than HR saves by doing location
| adjustments for all international employees combined because HR
| at the company had no notion of the value of an employee, only
| the cost, title, level, and location5.
|
| I laughed because I've been on the other end of these
| conversations (poaching a talented engineer going remote). I
| guess I have some random HR department to thank!
| hammock wrote:
| Would like to see these thoughts applied to public health policy.
| brodouevencode wrote:
| ...or all public policy.
| maccolgan wrote:
| I think it's something inherent in the self-selection for the
| politician/bureaucrat process that makes them inherently
| unable to believe that people aren't cogs.
| nimish wrote:
| >Some people seem to view companies like a game of SimCity,
| where if you want more money, you can turn a knob, increase
| taxes, and get more money, uniformly impacting the city. But
| companies are not a game of SimCity. If you want more attrition
| and turn a knob that cranks that up, you don't get additional
| attrition that's sampled uniformly at random. People, as a
| whole, cannot be treated as an abstraction where the actions
| company leadership takes impacts everyone in the same way. The
| people who are most effective will be disproportionately likely
| to leave if you turn a knob that leads to increased attrition.
|
| This gem applies to so many fields. It's bonkers that this has
| to be spelled out to people who are ostensibly experts. This is
| why you never, ever take anyone seriously who thinks of society
| like a model.
| nimithryn wrote:
| > This is why you never, ever take anyone seriously who
| thinks of society like a model.
|
| I've never understood these critiques. If you want to study
| society, what's the alternative? No matter what, you have to
| make a model of some kind. Yeah, some models are simplistic,
| but maybe they can capture the high order bits of the
| phenomenon they are modeling, and at least you are committing
| to an idea you can codify, find fault with, and improve. The
| alternative (never making models) seems to be a type of
| intellectual nihilism.
| nimish wrote:
| "All models are wrong, but some are useful"
|
| A lot of so-called experts don't quite grasp the former and
| don't care about the latter. They cannot be relied upon for
| actual decision making, since the low level details are
| what's hard!
| nverno wrote:
| > some models are simplistic
|
| Every model is simplistic, otherwise it's not a model, but
| reality. Societal models (I've never heard of a remotely
| reasonable one, aside from psychohistory) have the unique
| problem where they influence the people they are supposed
| to model. If your business is societal models, planned
| obsolescence is part of the deal.
| pedrosorio wrote:
| > The people who are most effective will be
| disproportionately likely to leave if you turn a knob that
| leads to increased attrition.
|
| > This is why you never, ever take anyone seriously who
| thinks of society like a model.
|
| The description above is just a different model
| chrisweekly wrote:
| > "This is why you never, ever take anyone seriously who
| thinks of society like a model."
|
| Yet that is _precisely_ what classical economic theory has
| done, for decades! It boggles my mind how long it 's taking
| for that kind of reductionist, simplistic, reality-ignoring
| "thinking" to mature.
| perl4ever wrote:
| "Reality" is necessarily a model. Your brain doesn't see
| photons, doesn't touch objects, doesn't respond to audio
| waves.
|
| If you are sane, then your model must not be subject to
| your will; therefore it is outside "you" even if within
| your skull, and performs as a trusted intermediary.
| chrisweekly wrote:
| Sure, on that point we're agreed. Our perceptions
| (distinct from sensory input) are dependent on a
| conceptual framework / paradigm / model. But I didn't say
| models were useless, I was pointing out the profound flaw
| at the heart of typical economic models. Classical
| economic theory reduces the messy reality of human
| interaction to a handful of simple pseudo-mathematical
| axioms, then proceeds to build complicated formulas and
| algorithms atop this unreliable foundation. It's only
| quite recently that real-world complexity is (finally!)
| entering the picture, thanks to things like the Santa Fe
| Institute. It's reminiscent of the Copernican revolution.
| tzury wrote:
| an easier to read version -
|
| https://outline.com/xrdMdP
| evancoop wrote:
| An overlooked notion, analogous to fat-tail, high-upside ROI is
| the absence of a similar downside risk. In the case of the
| sclerotic, flagging, midsize company failing to adapt, we're
| actually talking about a fixed downside (the company can fail)
| and a virtually unlimited upside. In this case, allowing talented
| humans to explore seems mathematically-required. And yet...
| skybrian wrote:
| A team where you have to ask who is going to do the work is one
| where people can't _get help_ when they are in trouble. It
| shouldn't matter who gets assigned to it first, if they can't do
| it, someone with more experience will step in.
|
| This is what those stand up meetings were supposed to be for.
| It's not supposed to be a meaningless ritual. If people can't get
| help, or are afraid to ask for help, something is wrong.
| zdragnar wrote:
| An experienced person will likely take half the time of an
| inexperienced person who gets help.
|
| If the inexperienced person pesters the experienced one much
| that it _doesnt_ take more time, that would imply that the
| experienced people aren 't (on paper) getting much done,
| because they are too busy teaching to do much else.
|
| The actual balance of course depends on the experience gap
| between the assignee and assigned work, but the notion that any
| two people on a team will always get the same work done in the
| same amount of time is silly.
| skybrian wrote:
| But this also means you can't assume a more experienced
| person will get the job done faster. They will be busy
| helping others, and that's not a bug.
| jcims wrote:
| I'm an introvert, I love working from home, I live in the woods
| with a 1/3rd mile long driveway. Since my youngest went off to
| college I'm here alone with her fish and a cat. I go into town
| once or twice a week for supplies and the rest of the time I'm
| just out here in my little sanctuary enjoying the lack of people.
|
| That said, even I know that while individuals matter, teams
| matter more. And I don't see anything in this entire post about
| how to build a team or sustain a team or inspire them to support
| each other. Absolutely nothing about how you can develop skill
| and aptitude in junior folks or redirect conflict or conveying
| the importance of actually shipping something vs running
| marathons on the tech debt treadmill. You know all the shit that
| has to happen in the real world to keep people happy and
| invested. All I see is an ode to the 10x'er and how sucking up to
| them might keep them around long enough to be successful.
|
| I love HN and the community overall but there are few things more
| predictable than this story making it from new to the front page
| lol.
| [deleted]
| PragmaticPulp wrote:
| > All I see is an ode to the 10x'er and how sucking up to them
| might keep them around long enough to be successful.
|
| Don't get me wrong: I enjoy Dan Luu's writings and I'm thankful
| that he shares his thoughts.
|
| That said, a lot of his recent writings present extremely rare,
| specialized situations like small teams of carefully-selected
| 10X-er type programmers who are hand-picked from their sterling
| reputations and naturally extremely motivated. If you find
| yourself in a top 1% unicorn team like that, a lot of his
| writings ring true. Trying to apply arbitrary big-company
| management to highly-optimized, high-performing teams like that
| is a mistake.
|
| However, statistically most of us won't be working on or
| managing those unicorn teams. Trying to apply top-1% advice to
| the median team is going to result in a lot of mismatches.
|
| Generally speaking, HN isn't a great place to get any sort of
| management advice. The userbase is mostly IC engineers, and as
| a result the upvotes tend to follow what IC engineers want to
| hear. Writing an article about making the difficult management
| choices that come with managing real-world (not top-1%) teams
| is hard to do without upsetting a lot of readers, so instead we
| get a lot of "engineers good, managers bad" type articles even
| if the authors start out with best intentions.
| dgreensp wrote:
| Wow, how do I start a list of people to never work for.
| rStar wrote:
| i've had one for years. the way you start is, when you meet
| an asshole, write their name and company and job title down,
| and a short, less than 20 words, statement describing the
| assholery. keep doing that for a few years and watch as
| patterns start to emerge.
| slantedview wrote:
| Teams are mentioned near the bottom in the section about
| reorgs.
| hsn915 wrote:
| Individuals matter for the team as well.
|
| Put a person who doesn't get along with people as a team leader
| and watch what happens.
| lmilcin wrote:
| "Individuals matter" does not mean that teams do not.
|
| The "individuals matter" is contrasted with "individuals do not
| matter" and not with "teams matter".
|
| If you think about this it is exactly pro-team. It means that
| the team is built from the people that compose the team and
| people are sometimes intimately linked together through the
| circumstances in which the team was built and cannot be easily
| replaced. The team building is path dependent and that path
| cannot be easily replicated.
|
| There are even examples of this in the article.
| Sniffnoy wrote:
| That doesn't go against the point of this article, it
| _enhances_ it. Teams mattering reduces the fungibility of
| people _even further_.
| caffeine wrote:
| I think the article also applies to teams - in particular, how
| not to destroy teams by ignoring the individuality of the team
| members, and indeed of the team itself.
|
| Each individual grouping of humans is unique in its social
| dynamics, relationships, culture, expertise, etc and so will be
| uniquely effective or ineffective at identifying and achieving
| desired outcomes.
| a_square_peg wrote:
| I agree. I think there is a strange trend of fetishicization of
| individual contributor capacity in tech world, some sort of
| hero syndrome. Even a lot of posts about 'culture' and
| 'organization' end up being about how at the end of the day
| these affect individual performance not how well the
| organization performs overall. Maybe we can all take lessons
| from playing in a team sport - it's true that the team will do
| poorly if each individual contributors perform poorly on their
| own for whatever reason but what wins the game is not about how
| well everyone played on their own.
| kmonsen wrote:
| Most effective people are not only because they are magical 10x
| people, but also because they have the right experience and
| knowledge in the situation. Skills and knowledge the company
| might have given them over years.
|
| I think there are ways of reading this without ever thinking
| some people are 10x super humans while the rest are not.
| barry-cotter wrote:
| Previously from danluu.com on the topics you mentioned
|
| Company culture matters https://danluu.com/culture/
|
| Different organisations have radically different expectations
| about how fast and well you can work
| https://danluu.com/productivity-velocity/
|
| Different organisations are capable of different things because
| of the (kinds of) people who work there https://danluu.com/in-
| house/
|
| Two different kinds of oransations work very differently
| https://danluu.com/startup-tradeoffs/
|
| Different organisations hire differently and this can be an
| enduring (dis)advantage https://danluu.com/tech-discrimination/
|
| Being better than most people isn't that hard because most
| people aren't trying https://danluu.com/p95-skill/
| Kinrany wrote:
| All of these are about organizations and individuals, not
| teams.
| Smaug123 wrote:
| No, they're not - at least if teams have some base level of
| autonomy. A team could choose to grow itself along the
| dimensions in https://danluu.com/culture/ without the
| company even knowing.
| kelnos wrote:
| I didn't get that feel out of this at all. Sure, there was
| mention of a few individuals who were "10x-ers", but I read it
| as appreciating _each_ individual for what they can bring to
| the team and to the org, which is always different for each
| person.
|
| The point is that people are not fungible. Some people have
| specialized skills, while others have a broad breadth of
| skills. They won't both be good at completing the same tasks,
| so you can't reorg to put them in positions that don't make use
| of their strengths and expect success.
|
| The bit about budgets was really eye-opening. Reducing things
| to "headcount" instead of figuring out what kind of people you
| need for a team or project is a great way to fail. If you just
| say "hey, you can hire three level-2 people", but believe that
| hiring two level-3 people (assuming at your org that the total
| cost for both of those is the same) will be more successful,
| and get told you can't do that, that is a failure of the
| organization.
| giga_chad wrote:
| Why is this blog so ugly and unreadable?
| ozim wrote:
| One thing missing is that author is assuming that talented people
| will like to work in one place indefinitely.
|
| With developers skipping boat every ~2 years on average how do
| you make sure you will keep such person in-house.
|
| You can compensate people only up to some level but as they got
| bored or feel they can do something better with their time they
| will move. Not to mention family reasons or whatever else can
| happen in persons life. You can have talented dev today - next
| day he might be hit by a truck, if you run your business by
| relying on people you will be affected by such accidents, if you
| run your business as if everyone is interchangeable you won't.
| Even if they are not easily replaceable.
|
| That "corporations are doing it wrong" premise is also wrong -
| somehow those big corporations are chugging along for decades. Of
| course they leave "lucky ticket" profits on the table, but that
| "lucky ticket" has risk of loss - which is missing from the text.
|
| Yes with small focused team you can achieve great ROI in one off
| project but those are not projects that are done by big
| corporations. Then you have all the startups that usually fail.
|
| Then leave alone "my friend's team was composed of people who had
| a track record of being highly effective across a variety of
| contexts" - seems like author does not understand how hard it is
| to find such people and assemble a team especially if you are
| BigCorp. That friend just got lucky to be in specific time and
| place and their experience. Especially if you read that they just
| wanted to hire another scapegoat - so it is just survivor-ship
| bias.
| rramadass wrote:
| > if you run your business by relying on people you will be
| affected by such accidents, if you run your business as if
| everyone is interchangeable you won't. Even if they are not
| easily replaceable.
|
| This right here is the problem and a fundamental error.
|
| It is a recipe for guaranteed disaster because you have
| completely ignored all the knowledge, experience and expertise
| which one has gathered over a period of time. Unless and until
| the task is trivial and/or very well defined with all
| constraints, assumptions and risks clarified people are not
| interchangeable.
|
| Paraphrasing Isaac Asimov: _[Knowledge Work] does not mean my
| Ignorance is just as good as your Knowledge._
| underdeserver wrote:
| In my view skipping boat every ~2 years on average is the
| result of a bad situation. Maybe people feel they have to do
| that to increase their comp or advance in their career, but I'd
| much rather stay in one place for 5-10 years growing it and
| growing with it.
|
| I'd also wager that a good workplace that provides autonomy,
| fair compensation, strong peers and a good atmosphere will not
| see 2-year average attrition.
| pm90 wrote:
| Developers wouldn't skip a boat every 2 years if they were
| happy. Instead of accepting that as a fact to be worked around
| try to understand why your developers are leaving after a 2
| year tenure.
|
| I've worked at a few companies, all of them have had highly
| skilled senior engineers with long tenures. The "2 year tenure"
| is a self fulfilling prophecy that management types love as a
| way to treat engineers poorly (why bother? They're gonna leave
| anyways!).
| Jensson wrote:
| > That "corporations are doing it wrong" premise is also wrong
| - somehow those big corporations are chugging along for
| decades.
|
| Once you have market dominance it is really hard to lose it,
| you have more resources and more experience than any startup.
| So they can carry a lot of bad practices without failing as a
| company, they have to be really bad to lose their position.
|
| This is actually a common business question, how can big well
| funded companies ever fall? Well, things like this is how they
| fall. Any one of these things wont be enough, but it all ads
| up.
| ozim wrote:
| There is a lot of corporations that are far from market
| dominance. There is more to the world than Fortune 100. Some
| companies chug along with ~500 employees for multiple years
| with a lot of rotation.
| lkrubner wrote:
| The one strategy that the article doesn't cover, but which I see
| often, is where the top leadership says "We need to keep
| headcount down, but we need to get more software development
| done, so how can we do it without any extra people? Oh, I know,
| we will outsource this to an outside agency."
|
| And yet, the outside agency costs more than actually adding to
| the headcount, so it is not cost effective. However, it is seen
| as temporary, so it this strategy is favored. There is the odd
| fear that headcount is permanent -- a fear that is mildly true in
| Europe, but definitely not true, at all, in the USA. Yet in the
| USA I still see managers who are eager to outsource.
|
| The outsourcing tends to become permanent. The idea that it is
| somehow less permanent than headcount is a pure fiction.
|
| But to the main topic, I appreciate this essay for emphasizing
| that "People are not fungible." I've tried to emphasize this in
| my own writing. I think, in general, writing about startups would
| be healthier and more realistic if we had more case studies that
| emphasized the role of specific individuals, for good or for bad.
|
| In my own book, How To Destroy A Tech Startup, I tried to
| emphasize this:
|
| -----------------------------
|
| Emotions matter. We might hope that those in leadership positions
| possess strength and resilience, but vanity and fragile egos have
| sabotaged many of the businesses that I've worked with. Defeat is
| always a possibility, and not everyone finds healthy ways to deal
| with the stress.
|
| More than once, I've seen startups self-destruct.
|
| I'm making a point about the importance of the individual in a
| small startup. In a large company, an eccentric individual does
| not do much damage. Even when such a person is in a leadership
| position, the company will have a bureaucracy that can ensure
| some stability. But when a company consists of two, or only a few
| people, and one of them reacts neurotically to challenges, that
| company is doomed.
|
| I'll relate one of my previous experiences to illustrate this
| point. From 2002 to 2008 I spent most of my time working with an
| entrepreneur who had inherited a few million dollars when he was
| 25. He managed to burn through much of his legacy in just the
| time we were colleagues. He admired musicians and considered the
| music industry glamorous, so he built a sound studio. It never
| made money. The bands that stopped by were broke. Those few who
| came up with a hit song mostly signed with a major label which,
| typically, had its own recording studio.
|
| I met him in 2002 when his focus was shifting to the Web. I had
| developed some software that allowed people to create weblogs.
| Typepad.com, which offered something similar to what I'd built,
| had just raised $23 million in funding. Surely we could do the
| same?
|
| Working with him was difficult. We might go like maniacs on some
| project for four months, and when we were on the brink of
| unveiling it to the public, he would grow bored with it, and move
| on to something else. The first time this happened, and I asked
| him his reasons, he improvised some arguments that sounded
| plausible. Perhaps he suggested there were already too many
| startups doing the same thing. But this pattern, where he walked
| away from a project just when we were ready to introduce it to
| the public, repeated itself. What led to this self-sabotage? As I
| met his whole family over the years I got to see the sad dynamics
| that ate at him. He had a desperate need to impress his father. A
| modest business success would not be enough, in fact, it would
| leave him embarrassed. Only the creation of something as big as
| Google would impress his father. But to grow that big, we would
| first need to be small, and that was the step he had no patience
| for.
| As the years went by, and he burned away all the money he'd
| inherited, the stress wrecked him. His self-image became
| increasingly grandiose. He told people that he was a visionary,
| someone who was able to tell what the future would look like.
| Late at night he would smoke marijuana and read articles on
| Slashdot and TechCrunch and then put together an amalgam of words
| that seemed full of the bright hopes of humanity, which he
| offered up as our marketing: "The Universe is fundamentally
| electromagnetic yet non-sentient, and we are sentient but only
| partly electromagnetic; the Internet is the ultimate harnessing
| of sentience to the fundamental forces of the Universe. Therefore
| our software will put you, our customer, in the driver's seat of
| real-time conscious human evolution." Later, when he wrote up our
| business plan, he put these two sentences in the Executive
| Summary. I'm not joking.
|
| He had no ability for internal dialogue. Only by talking to
| others could he hear his own thoughts. At our peak in 2007, we
| had eight people on our team. Sometimes I would look around the
| room, when he was talking at everyone, and I would think, "If you
| add up what we pay all these people, we are spending $300 an hour
| so that he can have an audience." When he felt fear about our
| chances of success, he would need to talk to everyone, and when
| he was euphoric about our chances of success, he would need to
| talk to everyone. Therapy would have been cheaper.
|
| https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
| bob229 wrote:
| Is this moronically awful website meant to be funny? Maybe this
| guy has something good to say but I'll never know as the site is
| unreadable
| mynegation wrote:
| Individuals do matter but outside of their immediate manager no
| one has knowledge, time, or attention span to account for it. It
| is a case of "all models are wrong, but some models are useful"
| and this is why sufficiently high level plans and budget
| allocations follow the assumption of fungibility.
| jnwatson wrote:
| Deciding that your attrition is too low is like determining your
| days between accidents is too low.
| hinkley wrote:
| I think attrition can be low as long as your team is steadily
| growing. No attrition can lead to no new people, and no new
| people is often the bigger problem.
|
| A stable team becomes an echo chamber and/or rant fest. Certain
| arguments have already been won, right or wrong, and others can
| never be won.
|
| New people come in and ask dumb questions that upset the status
| quo. They often are the only people who can.
| softwaredoug wrote:
| Another way of saying this is "Don't use process to overcome
| people problems". I've seen a lot of dysfunction because the org
| chooses to put a heavy process in place because 1 or 2 people
| made obviously bad decisions. It then punishes everyone for the
| acts of a few, and usually is done because the org isn't healthy
| enough to give those people feedback or let them go.
| kasey_junk wrote:
| One thing that I always think is undervalued is how variable a
| single persons output is. A bad day, illness, life changes, etc
| all dramatically impact a person's efficiency.
|
| Treating even the same persons output as abstract is fraught with
| issues. One month a rockstar the next a schlub.
| mrandish wrote:
| Some of the most capable people I've ever worked with have been
| "bursty" in that they would go through intense periods of high
| value output and then need to almost go dormant for a while to
| reset. As long as the "high value" phase was uniquely and
| significantly valuable it wasn't a problem so long as
| management understood and planned their assignments
| appropriately.
| tux3 wrote:
| Not to lean too much into my armchair, but the phenomenon you
| describe sounds like some mild form of bipolar.
|
| Periods of very high output, and then periods of slump. Not
| much of a long term stable in-between.
|
| I wouldn't be surprised if that's very effective for the
| right kind of project.
| rramadass wrote:
| >some mild form of bipolar
|
| Please no; we don't have to stigmatize normal waxing and
| waning of mental/physical energy.
|
| There are a lot of "normal" factors involved in any
| Individual's productivity and pathology should be consulted
| only as the last resort.
| hallway_monitor wrote:
| Thank you. Everyone has up days and down days. Some of
| them can even be kind of extreme like not wanting to get
| out of bed. Variation is normal, we are not robots.
| kayodelycaon wrote:
| I am bipolar and this is completely wrong. People have
| variable output. Motivation comes and goes. Live
| circumstances change. People burn out.
|
| These are not bipolar. The name "bipolar" is very
| misleading. One book I've read has called with multipolar
| disorder, which is far more accurate. There isn't just
| mania or depression. There is a whole world of possible
| dysfunctions that come with it: Anxiety, ADHD, insomnia,
| psychosis, and the list continues. There can be different
| moods, stages, and flavors of mania and depression _in one
| person_!
|
| On top of this, these symptoms need to be severe enough to
| impair normal daily function to be diagnosed.
| [deleted]
| mbot5324 wrote:
| I'd like to think I'm capable, but whatever I am, it's
| certainly bursty with periods of dormancy. To the other
| comment, it's probably on the bipoloar spectrum. Some of it
| is self-inflicted. Most of it isn't.
|
| Before covid, I'd had 2 managers who knew something of what I
| was dealing with and gave me the space to deal with it and
| encouragement that my work was good enough often enough not
| to worry. With some 5+ other managers, I believe I
| successfully masked it and that it would have threatened my
| job had I failed.
|
| In the remote world, it takes almost no work at all to manage
| around my work schedule. I don't even feel like I'm masking
| anything, just living. Weirdest part is I've now fallen into
| a far more social role.
|
| Who would have thought remote work had such hidden benefits?
|
| /...almost everyone
| rStar wrote:
| congratulations on finding a comfortable way to work that
| works for you, allows you to be productive, as well as more
| socially fulfilled. as someone currently attempting to find
| a nice niche for myself as well, much respect.
| rramadass wrote:
| This right here is what everybody needs to factor into their
| planning. For some reason management doesn't seem to understand
| this. IMO this is one of the main reasons for failure.
|
| As an example; i was once complimented (backhanded?) as "you
| are brilliant but moody" :-) It really made me realize the
| variation in my productivity which others had picked up on.
|
| Another example; in one project there was a real smart and
| knowledgeable programmer who had taken up a lot on his own
| shoulders. I was skeptical on whether he would be able to
| deliver on it and had tried to raise it diplomatically with
| management. Of course they didn't understand the human
| ramifications; result? A week before the deliverable, the guy
| cracked under the pressure and did not show up to work for the
| next two weeks. IMO, Management was squarely to blame for this
| since they did not understand the psyche of the people
| involved.
| foxfluff wrote:
| Motivation is a big one for me. Some tasks (or projects) just
| don't motivate me at all, and they turn into a dreadful slog.
| Others are captivating and I have a hard time logging out at
| the end of the day. I think there's easily a more than 10x
| difference in my own performance between those. Could be closer
| to 100x.
| ptmcc wrote:
| Completely agree, and reminds me of how much I hate the common
| Agile terminology of "sprints".
|
| Sprints are an extraordinary effort and are by definition not
| sustainable. If you run a sprint, you have to recover for at
| least as long before returning to baseline.
|
| I know it's just a word and doesn't literally mean to sprint,
| but I feel like it still subtly infects how development is
| viewed and approached. Even replacing it with something like
| "iterations" still implies that every 2-3 week period is
| cookie-cutter and predictable.
| underdeserver wrote:
| "Who can run at the top of their ability? Right. A short
| distance runner. You can't run far at that speed. We
| programmers have figured out how to fix that, though. We just
| fire the start pistol every hundred yards and call it a new
| sprint!"
|
| Rich Hickey
|
| https://www.youtube.com/watch?v=SxdOUGdseq4
| ChrisMarshallNY wrote:
| I tend to enjoy the topics that Dan Luu discusses, but his "wall
| o' text" presentation can be somewhat intimidating. It's better
| on a computer, than on an iPad.
|
| He's absolutely correct. I'm not sure that anyone in the industry
| (that can do something about it) cares, though.
|
| Nothing will change, until C-suite pocketbooks start getting
| impacted. As long as people are willing to pay for the type of
| software generated by organizations that treat ICs as "LEGO
| blocks," then it will continue.
|
| For myself, I care _-deeply-_ about the Quality of my work. I.
| Simply. Cannot. Bring. Myself. To. Write. Crap.
|
| Since no one is interested in paying me to do it, I write for
| free. I'm very fortunate that I am able to do this.
| zshrdlu wrote:
| What do you consider to be crap?
| ChrisMarshallNY wrote:
| I won't actually get into that.
|
| The reason being, is that I have made it a point to try to
| keep my [public] criticism to my own work.
|
| I tend to hold myself to a fairly high bar. I'm quite aware
| that the level of Quality that I expect from myself is
| usually considered "commercially infeasible."
|
| I'm OK with that. It's never been about the money, for me.
|
| You are more than welcome to look at my [highly accessible]
| public portfolio, to see what kind of work I do. Check out my
| HN profile. I am not anonymous.
| rob_c wrote:
| I've seen projects come in factors of 3 either way depending on
| the skill set of the individual.
|
| Having myself made these mistakes another thing I have to make
| the effort to extract is "how long would it take me" vs "how long
| would it have taken me 5years ago before I knew what I know now".
|
| It's amazing how many times the "big picture" changes can lead to
| complete overhauls or rewrites of otherwise consistent and well
| built software stacks.
| hprotagonist wrote:
| _Granny: "There's no greys, only white that's got grubby. I'm
| surprised you don't know that. And sin, young man, is when you
| treat people as things. Including yourself. That's what sin is."
|
| Mightily Oats: "It's a lot more complicated than that--"
|
| Granny: "No. It ain't. When people say things are a lot more
| complicated than that, they mean they're getting worried that
| they won't like the truth. People as things, that's where it
| starts."
|
| Mightily Oats: "Oh, I'm sure there are worse crimes--"
|
| Granny: "But they start with thinking about people as things."_
| voz_ wrote:
| Pratchett is amazing, one can identify his prose from a mile
| away. RIP to a beautiful soul.
| [deleted]
| aVx1uyD5pYWW wrote:
| Glad to see Dan Luu endorsing the idea of a 10x programmer
| rStar wrote:
| if your org doesn't work for you in some fundamental way, find a
| way out, immediately. you can't change the board, and the board
| gives hr it's marching orders, so if you have management you
| consider to be terrible and a "clueless" hr team, you have to
| leave. orgs can evolve over time, but they don't change for you
| or your feelings, no matter how smart you are or how justified
| your feelings.
| babelfish wrote:
| It's really hard for me to take this author seriously after his
| "Willingness to look stupid" post that went viral here about a
| month ago. The entire post was ridden with a superiority complex
| about how he's willing to look stupid, but never willing to
| explain his actions that make him look stupid.
| https://news.ycombinator.com/item?id=28946490
| robocat wrote:
| If you have decided you will not learn from imperfect people,
| then you will never learn at all.
| jart wrote:
| Yes but being wrong doesn't make you imperfect. New knowledge
| is rare so it's not possible to discover without being wrong
| much of the time.
| csee wrote:
| Merely publishing public essays is an example of being willing
| to look stupid.
| eyelidlessness wrote:
| Lacking emotional intelligence to explain my motivations is
| something I've struggled and worked to improve my whole life.
| But it doesn't make my motivations invalid. Just harder for you
| to understand.
| civilized wrote:
| Maybe his reason for wanting a small box computer was
| idiosyncratic and weird and he preferred not to discuss it.
| Maybe it was part of a bizarre prank or a secret project.
|
| The dictum "think horses not zebras" has its value - ordinary
| possibilities are more likely - but it doesn't say that zebras
| don't exist.
|
| To be honest, this comment is a perfect illustration of why Dan
| had to write that essay. Some people can't see beyond the
| obvious, and if the obvious is "this guy is stupid", well, you
| better not be afraid to look stupid.
| babelfish wrote:
| It is far more important to be able to explain your line of
| reasoning to those around you, especially professionally
| (much of the essay was about school/work), than it is to hope
| your coworkers are able to "see beyond the obvious".
| nkoren wrote:
| I think the worst of all cognitive biases which humans suffer
| from is the belief that observations about collectives can be
| usefully applied to individuals. How much faulty thinking, from
| racism and sexism onwards, stems from this simple category error?
| rStar wrote:
| strong disagree. there exist truths on a population level.
| oxycontin addicts traverse similar behavioral patterns, for
| example. for the worst of all cognitive biases i would say
| confirmation bias.
| interroboink wrote:
| > there exists truths on a population level.
|
| I don't think the person you replied to was claiming
| otherwise. The problem is when one takes those population-
| level truths and blindly applies them to individuals. You
| might be right 80% of the time (or whatever) with that
| approach, but that doesn't help when you're wrong _this_ time
| with the specific person in front of you.
| rStar wrote:
| > observations about collectives can be usefully applied to
| individuals.
|
| > You might be right 80% of the time
|
| or, as in my example of a collective of oxycontin users,
| you might be able to predict certain of their actions at a
| 99% efficiency rate, and that may enable you to make
| statements that apply to the collective as a whole, and as
| individuals.
| nkoren wrote:
| Yep, you're exhibiting precisely that kind of bias. I've
| known a variety of addicts and there's absolutely no
| statement one could make about them with 99% certainty
| that it will apply to a given individual.
|
| I don't mean that one should be naive about things. You
| might correctly observe that a high percentage of
| Oxycontin addicts exhibit behaviour X, and therefor you
| might want to keep a wary eye out for that behaviour when
| dealing with an individual Oxycontin addict. Of course
| that way lies confirmation bias, which one must also
| guard against. But it's still better than saying that
| because most Oxy addicts exhibit trait X, this individual
| addict will necessarily exhibit trait X. That's worse
| than confirmation bias becuause it's _pre_ -confirmation
| bias. You're treating statistics about a group as
| evidence about an individual -- and that's wrong.
| rStar wrote:
| > I don't mean that one should be naive about things.
|
| i think that's the literal disagreement we are having
|
| > I've known a variety of addicts
|
| how bout they try to get more oxy by any means necessary?
| i think i'm safe. i also think that some people really
| like to believe the line you're selling, but that's all
| it is. want and belief. some call it faith. whatever you
| want to call it, it's wrong.
| rStar wrote:
| i have to say though, i do appreciate the well thought
| out, reasoned and mannerly post. you are very good at
| arguing your position, so, even though we ultimately
| disagree, much respect
| [deleted]
| rramadass wrote:
| Well said and Insightful.
| andrewflnr wrote:
| This is cathartic to read, but I also despair at getting the
| people who need to hear it to take it seriously.
|
| > But many people want the world to be simple
|
| This is the source of so much insanity in the world, not just
| with regard to allocating labor. Details matter, but people who
| plan "timelines" desperately don't want to hear it. They can go
| through whole careers without being forced out of the cozy
| illusion that the world is simple. It's hard to get a man to
| believe something when his salary depends on it not being true,
| the market can stay irrational longer than you can stay solvent,
| etc.
| wffurr wrote:
| There's a great book about this called "Seeing Like a State".
| Infinitesimus wrote:
| On that subject - I have read the original yet but I did
| enjoy this take https://www.ribbonfarm.com/2010/07/26/a-big-
| little-idea-call...
| wreath wrote:
| I cannot recommend this book enough.
| abbeyj wrote:
| "There is always a well-known solution to every human problem--
| neat, plausible, and wrong" - H. L. Mencken
| vishnugupta wrote:
| > Details matter,
|
| You are on the money[1]. People want to estimate work _without_
| even telling what is it that needs to be done in the first
| place.
|
| [1] http://johnsalvatier.org/blog/2017/reality-has-a-
| surprising-...
| quickthrower2 wrote:
| Knowing what needs to be done is insufficient in programming
| too. You need to do careful archeology on the code base as
| well. Yes that code base you work on every day.
| mro_name wrote:
| knowing what needs to be done is impossible without
| considering the means at hand.
|
| It's not just wishing for a goal - a three year old can do
| that - but enabling to go the way there.
|
| But a statistical estimate may be possible indeed.
| Andy_G11 wrote:
| This is not a planning problem - this is a power problem. If
| competent and incompetent people alike are told to regard each
| other as peers in a meritocracy, a range of possible outcomes
| ensues.
|
| The only option for incompetent staff will be to game the system
| by ensuring that they pass a load off their shoulders to
| competent staff and cultivate cultural and organisational aspects
| that let them give the impression of performance without actually
| having to perform.
|
| This article is quite anecdotal but it is possible for
| organisations to require high performance from members. E.g. I
| assume that there is less scope for less competent individuals to
| hide out in teams like SWAT teams, heart or brain surgery teams,
| bands or movie crews: every one is visible and under the
| spotlight for delivery at any one time and relied upon by others
| to be at the top of their game.
|
| Critical dependence should trim incompetence from organisations,
| but will only work if scrupulously applied. Perhaps logically,
| this might work best in fluid structures where selection and
| deselection of team mates / suppliers is very easy.
| lucidbee wrote:
| I think there is a structural problem here that we are avoiding.
| The reason some higher ups don't see the merit of particular
| individual developers is that their pay does not reflect their
| contribution. Pay is the simple metric that should reflect worth,
| but we don't use 10x or 100x pay scales. We are failing to pay
| stars and superstars in accordance with the value they contribute
| to company. profits.
| jpgvm wrote:
| This is something I fail to understand. no-one blinks an eye
| when proposing a high performing CEO he compensated
| appropriately but propose the same for an engineer and everyone
| looks at you funny unless you give them a VP title and saddle
| them with a bunch of non-technical responsibilities in the
| process. If an engineer is the crucial individual in creating
| and delivering a product that the companies profits are derived
| from they should also receive appropriate performance based
| compensation in line with senior management, perhaps even more
| as senior management is definitely more fungible (namely C
| level roles like CFO, etc).
| thadk wrote:
| It's certainly not perfect, but it is funny to me that the author
| on one line complains the Peace Corps "produce[s] little value"
| but then in the surrounding lines talks about how important it is
| for individuals to bridge and bring contextual incisive change
| that consistently resist abstractions and not just look at the
| problem from the outside.
|
| He's falling for his own simplification of individuals and
| lifetimes.
|
| That kind of nuance sounds exactly like the skills Kennedy and
| his associates were intending to cultivate in individuals from
| the USA during and returning from Peace Corps when they created
| the agency: see e.g.
| https://en.wikipedia.org/wiki/The_Ugly_American Ugly American
| (1958). Huge percent of state dept employees. I'd be willing to
| wager Guinea Worm intervention mentioned involved RPCVs. Notably,
| Netflix founder, RPCV. It has 3 stated goals. This is essentially
| one.
| SavantIdiot wrote:
| > He's falling for his own simplification of individuals and
| lifetimes.
|
| Totally.
|
| > complains the Peace Corps "produce[s] little value"
|
| This is what happens when quantitative minds encounter the real
| world. It's a consequence of putting engineering on a pedestal
| and ignoring any and all context.
|
| However, the top comments on the thread give me hope that many
| more people see the thought errors in this piece than people
| who revere it.
|
| EDIT: Quanti- not quali-
| dzonga wrote:
| this is pretty much obvious to people who study and design
| systems. Russel Ackoff pretty much nailed it by saying: a system
| is a whole that consists of parts, each of which might affect the
| whole. taking the best parts from say a toyota and a mercedes
| won't make the best car. same thing with individuals, in a team
| you need cohesion. not just the best individuals.
| tayo42 wrote:
| Abstraction is necessary to deal with things at scale, on a
| programming focused site i think we all know that and know that
| often the trade off is inefficiency. Its probably to expensive to
| track all these peoples real value and really it doesn't even
| matter. What was the consequence of all these supposedly valuable
| people leaving? Did the stock drop after the guy saving millions
| a year left? Probably some pointless project was delayed that
| would have been delayed anyway. We are nothing but cogs in a
| machine that doesn't care about the cogs.
|
| I think you'll just drive your self crazy worrying about
| corporate waste and monetary inefficiency (environmental might be
| the only thing worth thinking about). There always going to be
| waste and there's no awards when its fixed. I used to be
| concerned about money being wasted, but now, IDK why I cared in
| the first place. Its not my money and I don't get any of it.
| AnthonyMouse wrote:
| This depends entirely on what you're doing.
|
| If you're at some adtech company where the entire point of the
| advertising is to cancel out some competitor's advertising and
| you're only there for the paycheck, efficiency is irrelevant
| because the company could be destroyed by a giant meteor and
| nobody else in the entire would would have any reason to care.
|
| But not all jobs are like that. Some people make medical
| devices that save lives. If the company is inefficient, they
| don't save as many lives, and that matters. Some people are in
| charge of making loans to people or selling legally mandated
| insurance and the rate the customers pay has a significant
| effect on their economic well-being. Some jobs are in the
| production of food and the work impacts the quality and price
| of food. Some companies make fire suppression systems or
| automobiles or industrial equipment, and it needs to be safe
| without being unaffordable.
|
| Not all jobs are an exercise in futility.
| civilized wrote:
| Today I worked with Company B, founded by former workers in
| Company A who were sick of Company A's dishonest, high-
| pressure, customer-hostile sales tactics (which I personally
| experienced).
|
| The guys who left Company A didn't stop Company A from
| continuing to be the #1 provider of widgets (for now). I'm sure
| the Company A stock price didn't care.
|
| I'm still very glad I get to work with Company B rather than
| Company A.
|
| There is still such a thing as honor among men.
| yjftsjthsd-h wrote:
| > Abstraction is necessary to deal with things at scale, on a
| programming focused site i think we all know that and know that
| often the trade off is inefficiency.
|
| We also all know that abstractions leak, and sometimes... Not
| always! But sometimes, those leaks will _kill_ you. CPU details
| are irrelevant, until per-opcode details give you a 10x
| speedup. Compilers are a magic black box, until a compiler bug
| breaks your code. Hardware is cheap, until someone notices a
| way to save millions by caring. And yes, sometimes developers
| are interchangeable, until they make or break the company.
| Veelox wrote:
| Just as a random aside, I don't know why but Dan is putting out
| some great articles at an absurd rate late. I really appreciate
| it. Keep it up Dan!
| doitLP wrote:
| If you want a great book on the subject of management legibility
| and what is lost when it is imposed, read Seeing Like a State.
| One of the most eye opening books about the world I've ever read.
| wins32767 wrote:
| The author is conflating two different things here. At large
| enough scale, almost everyone in a given role is practically
| interchangeable but there are some people who very much aren't.
| It's a hard leadership problem to both solve for making 99% of
| the staff function at a consistently high level while still
| carving out the exceptions for the 1% that really can move the
| needle at the company scale.
|
| At a the level of a single team, nobody is interchangeable, but
| both reducing specialization and creating a "we're all in this
| together" spirit are both important goals for long term team
| performance (and so people can go on vacation).
|
| Both of those problems have different solutions but can feel
| pretty similar when you're at the receiving end.
| [deleted]
| gadrev wrote:
| > The roadmap creation and review process maintains the polite
| fiction that people are interchangeable, but everyone knows this
| isn't true and teams that are effective and want to ship on time
| can't play along when the rubber hits the road even if they play
| along with the managers, directors, and VPs, who create roadmaps
| as if people can be generically abstracted over.
|
| Agreed, and this breaks down when there's a large deviation from
| the mean for any particular team member, where the mean isn't
| necessarily some sort of "average", but more like what the rest
| of the organization has become used to in terms of productivity
| from that team/department.
|
| But if the "polite fiction" enforcement resists this reality, it
| comes out in all sort of undesirable ways. It's... not nice.
| a_square_peg wrote:
| We are interchangeable - everyone is. The president of the
| United States is interchangeable. The CEO is interchangeable.
| Is this really that difficult to accept?
| efitz wrote:
| I am a security engineer but have been a business leader from
| time to time. Business leaders often need to plan around dates-
| eg "should we spend $50k announcing at conference Y in month Z,
| or should we wait until month A?" "Our competition just launched;
| will we be able to launch this quarter (the board wants to know,
| and we have to report material financial impact items quarterly
| or face SEC fines)?"
|
| Every team I have ever worked with hates planning; every team
| hates their methodology and thinks it's stupid and inaccurate and
| why are those pinhead business people insisting on a date; it'll
| be done when it's done.
|
| One of the primary jobs of managers at all levels is to plan and
| then execute in accordance with the plan. Some managers are good
| at it, many aren't- the world is populated with people nearer the
| center than the ends of the bell curve.
|
| So show me a methodology that mere mortals can implement
| successfully. If all you can do is complain and point out unicorn
| 500x engineers (yeah try hiring for that characteristic, good
| luck), then I don't want to hear it. But if you have a practical
| idea on how to "solve" planning, then you have my full attention.
| watwut wrote:
| > One of the primary jobs of managers at all levels is to plan
| and then execute in accordance with the plan.
|
| Yep, just as I thought. This is why those teams hated plans -
| because once there is plan they will be beaten and abused to
| make it, despite the plan being unrealistic from the start.
|
| > Every team I have ever worked with hates planning; every team
| hates their methodology and thinks it's stupid and inaccurate
| and why are those pinhead business people insisting on a date;
| it'll be done when it's done.
|
| In that case, teams in which you worked had stupid methodology
| about planning. It sounds like your plans did not accounted for
| uncertainty at all. They did not accounted for what if we are
| not making it, which features will be cut.
|
| > Some managers are good at it, many aren't- the world is
| populated with people nearer the center than the ends of the
| bell curve.
|
| And many of them are abusive or exploitative about it and there
| is nothing in business organization to prevent or at least
| acknowledge that.
| aahortwwy wrote:
| > So show me a methodology that mere mortals can implement
| successfully.
|
| Commit to a deliverable or a deadline, but never both.
| bodge5000 wrote:
| I'm not all to familiar with this kind of thing so I could be
| missing something, but what is a deadline without a
| deliverable? Surely "We will do something (literally
| "something", not a stand-in for X) and it will take a month"
| is worth nothing?
| darrenf wrote:
| I worked for several years on an extremely large and
| popular sports news/results website, meaning all our
| deadlines were absolutely set in stone by the outside world
| - sporting events start on specific dates. The Tour de
| France sure as hell ain't gonna postpone a few days until
| we've finished our team profile pages.
|
| So we committed to a deadline, but not a single
| deliverable. Scope would shrink and grow as delivery of
| each component progressed. Well in advance, for each major
| sporting event in each country where we operated, we would
| scope out literally every single thing we'd like to
| deliver, and then start work on the components in priority
| order. In each planning session as the event approaches
| we'd appraise whether we still have time to realistically
| deliver the next priority thing, and if not we'd skip it
| and move to the next - those that got missed out could wait
| until the following year (when the major features already
| delivered would need to evolve, not be implemented from
| scratch).
|
| I learnt a _lot_ from working on sports. Having third party
| deadlines that no-one could bitch about made us an
| extremely effective team at planning, estimating, and
| ruthless scope reduction.
| selfhoster11 wrote:
| You can have a fixed scope with a flexible timeline, or a
| flexible scope with a fixed timeline. If you try to have
| both, you'll incur an additional cost, which most companies
| avoid. It's a well known law of project management and
| software development.
| jcims wrote:
| "Ok awesome! Glad to hear you've committed to deliver widget,
| when do you think it will be done? We have four business
| units that were going to use wedgie but that's getting
| decommed next year and they'd much rather avoid a pivot.
|
| Oh and change restrictions start in six weeks, don't forget
| that. BTW what's your team's vacation schedule looking like?
| We only get to roll over 7 days this year, hopefully they
| took some this summer haha!
|
| Ok so anyway really would like some estimate that i can take
| back to product, you thinking January? Maybe get something up
| in test that they can kick around in what, a month?"
|
| Etc etc.
| aahortwwy wrote:
| "No."
|
| It's remarkably powerful.
| xvilka wrote:
| I would say an approach closer to the Heisenberg uncertainty
| principle would make more sense. The more information
| specified that can't be changed about the expected product
| the less information is available about the deadline, ans
| vice versa. Thus, the desired balance could be used depending
| on the situation, goals, budget, etc.
| eitland wrote:
| That was briliant and is already added to my quotes list.
|
| Should I attribute it to xvilka or did you get it from
| somewhere else?
| xvilka wrote:
| I think, it's my own idea but you never can be 100% sure,
| some kind of uncertainty always persist.
| [deleted]
| solatic wrote:
| > So show me a methodology that mere mortals can implement
| successfully.
|
| There's an impedance between "Bob can do task of type A really
| quickly" and "we need to make sure that people other than Bob
| can do the task or else we have bus factor = 1 and this poses
| systemic risk". Clearly these goals are not really in conflict.
| In general, assign the work to Bob, but understand the effect
| on timeline in case Bob is unavailable. How long would it take
| if Bob isn't available? Is it worth the inefficiency from
| cross-training Mike? Is Mike even interested?
|
| Modern militaries are not majority staffed by combat soldiers.
| Less than 10%. The rest are support of one kind or another.
| Smart engineering leadership in large companies, if they care
| about shipping on-time, eventually realize that roles like PMs
| are less effective if they understand themselves to be bosses
| and more effective if they understand themselves to be support
| staff.
| lmm wrote:
| Leaders may need to know some specific dates for some specific
| purposes. Responding to that need by demanding your methodology
| deliver a schedule for everything in case you need it is lazy
| and wasteful.
|
| If your engineers are part of the same team, working on the
| same business goals, they'll be glad to contribute what you
| need to the decision about whether to announce at conference Y,
| and may even be able to suggest relevant aspects you haven't
| thought of.
| mobjack wrote:
| A lot of my planning is making sure the most effective
| engineers are working on the most important things.
|
| It is about making sure resources are most efficiently
| allocated to meet the business objectives.
| noduerme wrote:
| I'd imagine the corollary to this is assigning each of them
| the task you think they're most suited to. I think that's
| what used to be called "management".
| [deleted]
| aidenn0 wrote:
| > So show me a methodology that mere mortals can implement
| successfully. If all you can do is complain and point out
| unicorn 500x engineers (yeah try hiring for that
| characteristic, good luck), then I don't want to hear it. But
| if you have a practical idea on how to "solve" planning, then
| you have my full attention.
|
| TFA doesn't suggest hiring 500x engineers, it suggests taking
| steps to _retain_ highly effective engineers (and highly
| effective teams) by not ignoring the evidence that they are not
| fungible.
| mjmahone17 wrote:
| A point the article also alludes to: often people are only
| "unicorns" due to the specific context they're working on.
| Move them to a different project, and your high value person
| may be a net negative. And it's not possible for people who
| aren't familiar with a person's work to anticipate how making
| that person switch projects will affect the quality or
| quantity of their output.
| [deleted]
| vbezhenar wrote:
| Stop using methodologies actively preventing any kind of
| planning (mostly agile stuff). Return to waterfall, write lots
| of documentations, spend time planning architecture, resist
| urges to rewrite non-ideal solutions. Do not allow changes.
|
| It'll take more time and result will not be as clean.
|
| Basically learn from older engineering disciplines.
| sergio wrote:
| Also, build several prototypes of every important part of the
| product in order to learn how long they will take to be made
| and how each variant will perform, so when you make
| estimations they are as effective as possible; and then, make
| integration tests on the selected variants so you can reduce
| estimation risks due to integration. Just as in every other
| engineering discipline.
| RNCTX wrote:
| The two replies below yours at the moment capture what you're
| trying to say...
|
| > This mentality of thinking is exactly the problem, I think.
| You want a tool that can solve an entire class of problems.
| We are telling you that no such tool can exist to do what you
| want, the problem and the tools don't work that way. Each
| project should be planned as a snowflake.
|
| > This is exactly right and is the biggest problem with
| "Management" types. They want a "cookie cutter methodology"
| to solve all their problems so they can be spared thinking
| through each one. Hence the various "Management" fads and
| buzzwords.
|
| Which is another way to say... if there was a system to do
| their thing, they wouldn't have to pay smarter people a lot
| of money to do it. Reliance on a system (any system) tells
| you that the people don't value your expertise, but rather
| see you as a cost to be minimized.
| jiggawatts wrote:
| I just went through this, like... today.
|
| "Tell me what date task X will occur on." -- where task 'X'
| takes 5 minutes, but has a long list of pre-requisites that
| take 1-4 weeks each, _sequentially_ , of which 100% our out of
| our control.
|
| ...
|
| That's not _planning_ , that's _fortune-telling_. You may as
| well ask an Ouija board.
|
| Planning is making sure the the _pre_ -requisites happen
| _before_ you attempt to start the things that depend on them.
| It is making sure that everyone is unblocked. It is making sure
| that nobody is wasting time going down a dead end. It is making
| sure that _everyone is rowing in the same direction_.
|
| What I see from PMs is that they just want facts from the
| future, instead of solving problems in the here and now.
|
| Until today, weeks into the project, I could not access the
| system that I needed. This was the _key_ pre-requisite for 4x
| FTEs progressing on their own tasks.
|
| The only thing the PM did is repeatedly ask me if he needed to
| move the date for the completion ETA.
|
| _I_ solved the problem. He did _nothing_ to expedite progress.
|
| Does it really matter which specific date this occurred on? No.
| It just had to happen _as soon as possible_. The trick is to
| make it possible, not to try to pin down exactly when "soon"
| will occur by repeatedly asking the same question in every
| daily stand up.
|
| Why do we pay these people, again? Remind me?
| biztos wrote:
| That was the glory of the good ole Gannt Chart in what I
| might call Microsoft Project Based Project Management.
|
| If you set your dependencies right, the dates would just slip
| by themselves, and it was easy to tell the bosses what
| slipped. Required a lot of printing and taping every week,
| and caused a ton of headache whenever people lied about their
| progress, and didn't really work without a FTE project
| manager, _but_ I have yet to see a supposedly better system
| actually work better on big projects.
| notpachet wrote:
| Like the parent poster said, people are on a bell curve. It
| sounds like you may only have been exposed to mediocre,
| passable, or plain bad PM's so far in your career.
|
| So I'll remind you: the reason we pay PM's is because good
| PM's can, and do, exist. I've only worked with a few great
| PM's, but they outshone their competition with just as much
| brilliance as the 10x among us engineers outshine the 1x.
| It's ironic that you would reduce PM's to a single
| heterogeneous caricature in reply to an article that is
| essentially saying that it's harmful to do so.
| notpachet wrote:
| Woops -- *homogeneous!
| atoav wrote:
| I can't really speak about managment here, but when I organize
| projects the three most important things are:
|
| 1. Create the room for every member of the team to comfortably
| do their job (what this means depends on the persons needs and
| at the work environment, communication structure, tools you
| provide them). Room not only means physical room, but also
| time, frame of mind etc. If everybody has 10 other daily things
| on their list they won't have the (mental) room to work on the
| project.
|
| 2. Communicate clearly why you think this is a workable plan
| and ask for feedback whether this is realistic. Communicate
| what happens if you are faster, what happens if you are slower.
| They are helping you, you are helping them, ideally both sides
| take away something from the project beyond purely finishing
| it.
|
| 3. Adapt, Improvise, Overcome. The primary goal should always
| be to finish the project _in a good way_ , especially if the
| deadline is not a hard deadline, but one arbitrarily set by
| someone else. Defend the team, create the room for them. Don't
| let them slack around too much. _A bit_ of slacking around is
| _not_ too much, but precisely the right amount - this is the
| space needed if something goes terribly wrong.
| dharmab wrote:
| A technique I read once (and lost the link) was to track both
| the estimated time metrics and the error in estimation for
| every engineer. Over time you could build reasonable error bars
| around every engineer's estimations, and then sum the estimates
| _with the confidence intervals_ together and figure out the
| probability of achieving a certain ship date.
| bojan wrote:
| > A technique I read once (and lost the link) was to track
| both the estimated time metrics and the error in estimation
| for every engineer.
|
| To do this you need to communicate very clearly why are you
| doing it, and if it will have any influence on performance
| reviews. But I do think that monitoring estimates in this way
| will affect the quality of estimates.
|
| A manager in my previous company noted everyone's estimations
| during sprint planning in an Excel sheet. No-one knew why, so
| I found myself thinking more about that Excel sheet than
| about making an well-founded estimation.
| DocTomoe wrote:
| That's what Fog Creek Software's FogBugz tried to do. I liked
| it a lot, it also allowed for some team structure planning
| (e.g. giving you a chance to see if your team consists of
| pessimistic estimaters or positive ones, and mix
| accordingly). Unfortunately, their marketshare got gobbled up
| by Jira.
| noduerme wrote:
| I feel like pessimistic estimators are way more accurate
| and probably more intelligent than optimistic ones. I'd
| probably use software like that to fire half the team.
|
| (edit: of course then I'd have to fire half the team
| again... and again... until only one or two incredibly
| depressed pessimists remained... tough call)
| Jensson wrote:
| Why would you fire the team? The software shows you how
| their estimates relates to real world timelines, just
| adjust their estimate accordingly and the problem is
| fixed.
|
| I never understood why managers get so upset over
| consistent time under estimates, just track it and add
| the relevant factor without telling the team and it
| should on average be on point.
| vishnugupta wrote:
| I'm speaking as someone who has handled a fair share of
| timelines (with reasonable success) you have pointed out.
|
| To begin with, it is interesting to see you lumping up
| different _kinds_ of timelines. For example, the cost of not
| meeting SEC timeline different one compared to demo to be shown
| in a press conference.
|
| > should we spend $50k announcing at conference Y in month Z,
| or should we wait until month A?
|
| _What_ is it that you want to announce? Product launch
| perhaps? Then let 's work with the product folks to design it
| and then take it to engineers to figure out work estimate. Give
| them time to estimate; if the timelines don't match then reduce
| the scope.
|
| > Our competition just launched; will we be able to launch this
| quarter
|
| Sure, they _launched_ this quarter. Do you know how long have
| they been working on it? If not then it 's a similar exercise
| as above.
|
| > we have to report material financial impact items quarterly
| or face SEC fines
|
| Why are you telling me this? SEC doesn't ask for such reports
| overnight. You messed up by not telling us so fine it is. OR
| there is some human at the SEC with whom you negotiate.
|
| > So show me a methodology that mere mortals can implement
| successfully.
|
| If there were such a methodology we wouldn't be having this
| discussion to begin with. It would have been commoditised,
| similar to a car manufacturing assembly line.
|
| What business people don't understand (or internalise) is
| software is a truly a new beast. It is a tool that can be
| applied in just about every domain. No such tool has existed
| ever in human history. If you want to disrupt a domain then you
| either develop expertise in it or hire them from the industry.
|
| > If all you can do is complain and point out unicorn 500x
| engineers (yeah try hiring for that characteristic, good luck),
| then I don't want to hear it.
|
| In some cases that is indeed the reality. If you don't even
| want to acknowledge the reality then good luck hiring good
| people. If you say point out how Apple launches products like
| clockwork then I'll point out how they have had close to 50
| years worth of experience and all the associated optimisations
| they have done with their supply chain and what not.
|
| Reality is, whether you acknowledge or not, is full of
| detail[1]. It can't be bent to your convenience, unfortunately.
|
| [1] http://johnsalvatier.org/blog/2017/reality-has-a-
| surprising-...
| m_eiman wrote:
| > What business people don't understand (or internalise) is
| software is a truly a new beast. It is a tool that can be
| applied in just about every domain. No such tool has existed
| ever in human history.
|
| That's not quite true: the inventions of mathematics, writing
| and especially affordable material to write on were probably
| even larger culture shifts, but software and computers are of
| the same magnitude - perhaps it's easier to realize the shift
| needed in corporate culture when you compare it to those
| earlier changes.
| fractalb wrote:
| You can just give a random guess on the timelines and save the
| developers time.
| downWidOutaFite wrote:
| I'm really confused what this comment has to do with the
| article (not about planning) and why it's the top comment on
| HN.
| thegrimmest wrote:
| > But if you have a practical idea on how to "solve" planning
|
| Seems pretty straightforward to me - just don't use dates in
| your plans. That means don't announce features which aren't
| complete. Don't plan marketing campaigns for unlaunched
| products. Embrace "Now, "Next" and "Later" as headings on your
| roadmap. There are many successful companies that operate like
| this, Nintendo being a famous example. It doesn't seem to hurt
| their bottom line - quite the contrary.
|
| The usual issue that folks have with planning is that business
| leaders are simply not willing to spend the resources to do it
| accurately enough to answer the questions they're asking. Think
| how much time it would take to break 6 months of work for
| several teams into detailed stories and estimate each one.
|
| It therefore seems they're basically wasting everyone's time,
| since dartboards and magic-8-balls are just as good as
| engineering estimates without details.
| rramadass wrote:
| >One of the primary jobs of managers at all levels is to plan
| and then execute in accordance with the plan
|
| "Plans" can never be set in stone. They evolve based on the
| people involved and circumstances. A Manager's job is to
| _understand_ his people and then Plan accordingly; not the
| other way around.
|
| >If all you can do is complain
|
| This is exactly the wrong way to frame the discussion. Pointing
| out that you are clueless is not complaining but raising issues
| which if unaddressed, will most probably result in failure of
| what is attempted.
| rStar wrote:
| >If all you can do is complain This is exactly the wrong way
| to frame the discussion. Pointing out that you are clueless
| is not complaining but raising issues which if unadd
|
| he's pointing out that you are clueless ramadass
| rStar wrote:
| i would say, everyone acts in their interests, at all
| times, except for individual actors who may value things
| like the city the work in or loyalty in themselves that may
| artificially tie them to a situation. i say, if you
| identify a problem with your organization that you can't
| get over, be a grown up, and find another job. seriously,
| it's the best thing you can do for yourself. if you feel an
| organization is rotten, leave. you will never ever fix the
| rot. if you've got bad hr you've unfortunately got bad hr,
| and that's not your fault, but that also will never, ever,
| change.
| alfiedotwtf wrote:
| > "Plans" can never be set in stone
|
| Setting plans in stone was the entire Waterfall Methodology
| where contracts had requirements and milestones locked in and
| any deviation meant heavy penalties.
| DnDGrognard wrote:
| Not when I have done waterfall - each waterfall phase can
| iterate
| alfiedotwtf wrote:
| Show me a Software Engineering book that calls Waterfall
| that can iterate "Waterfall" rather than "Spiral" or
| "Iterative".
| rramadass wrote:
| There is a big difference between _the stages involved in
| "Waterfall Model"_ and _the various techniques of
| combining, using and transitioning_ from one stage to
| another.
|
| "Waterfall" specifies the _What_ while "Spiral and
| Iterative" specify the _How_.
| rramadass wrote:
| Absolutely Categorically Wrong!
|
| This has been so endlessly repeated without thought that
| people assume it is a fact when the Truth is far from it.
|
| Excerpts from wikipedia -
| https://en.wikipedia.org/wiki/Waterfall_model ;
|
| * In 1983 the paper was republished with a foreword by
| Benington explaining that the phases were on purpose
| organised according to the specialisation of tasks, and
| pointing out that _the process was not in fact performed in
| a strict top-down fashion_ , but depended on a prototype.
|
| * Royce's five additional steps (which included writing
| complete documentation at various stages of development)
| never took mainstream hold, but his diagram of _what he
| considered a flawed process_ became the starting point when
| describing a "waterfall" approach.
|
| * In 1985, the United States Department of Defense captured
| this approach in DOD-STD-2167A[citation needed], their
| standards for working with software development
| contractors, which stated that "the contractor shall
| implement a software development cycle that _includes the
| following six phases: Software Requirement Analysis,
| Preliminary Design, Detailed Design, Coding and Unit
| Testing, Integration, and Testing._
|
| The "Waterfall" is what is imagined as a "Ideal and
| Rational" process (see D.L.Parnas' paper _A Rational Design
| Process: How and Why to Fake it_ for motivation -
| https://ieeexplore.ieee.org/document/6312940). The stages
| in the model and the issues to be considered in each stage
| are what is important NOT their order. In practice it was
| always a iterative spiral model described by Barry Boehm -
| https://en.wikipedia.org/wiki/Spiral_model
| alfiedotwtf wrote:
| Maybe you've never done big government contracts.
| rramadass wrote:
| Totally irrelevant and no Ad Hominem please.
|
| FYI, D.L.Parnas and Barry Boehm _defined_ the field of
| _Software Engineering._ Almost all Govt. /DoD standards
| are based on their research and writings.
| alfiedotwtf wrote:
| TIL: "Winston W. Royce's final model, his intended
| improvement upon his initial "waterfall model",
| illustrated that feedback could (should, and often would)
| lead from code testing to design (as testing of code
| uncovered flaws in the design) and from design back to
| requirements specification (as design problems may
| necessitate the removal of conflicting or otherwise
| unsatisfiable / undesignable requirements)"
|
| https://en.wikipedia.org/wiki/Waterfall_model#Modified_wa
| ter...
|
| Interesting because that's definitely not what's taught
| in the handful of Software Engineering books I've read,
| and steps backward are not canon (rather, they're called
| something besides Waterfall i.e Spiral or Iterative).
|
| Looking at that page again, it looks like what I describe
| is called "pure waterfall".
| rramadass wrote:
| Most books on Software Engineering are mere compendiums
| with nothing much to recommend them eg. the texts by
| Sommerville or Pressman. Two exceptions that i know of
| are those by Ghezzi,Jazayeri,Mandrioli and Pankaj Jalote.
| mattm wrote:
| This is a good article on the topic
| http://www.bawiki.com/wiki/Waterfall.html
| rramadass wrote:
| That is indeed a Great Writeup!
|
| Instead of getting lost in the comments, You should post
| it to HN and invite discussions with a title like "Most
| of what you have heard about the Waterfall Development
| Model is Wrong!" or "How the Agile folks have misled you
| about the Waterfall Development Model" :-)
| flawedbydesign wrote:
| _The first formal detailed diagram of the process later
| known as the "waterfall model" is often cited as a 1970
| article by Winston W. Royce. However he also felt it had
| major flaws stemming from the fact that testing only
| happened at the end of the process, which he described as
| being "risky and invites failure". The rest of his paper
| introduced five steps which he felt were necessary to
| "eliminate most of the development risks" associated with
| the unaltered waterfall approach._
|
| _Royce 's five additional steps (which included writing
| complete documentation at various stages of development)
| never took mainstream hold, but his diagram of what he
| considered a flawed process became the starting point when
| describing a "waterfall" approach._
|
| https://en.wikipedia.org/wiki/Waterfall_model#History
| Afforess wrote:
| This mentality of thinking is exactly the problem, I think. You
| want a tool that can solve an entire class of problems. We are
| telling you that no such tool _can_ exist to do what you want,
| the problem and the tools don 't work that way. Each project
| should be planned as a snowflake. Each project is different.
| Each team is unique. Every individual performs differently,
| even one day to the next. Stop looking for this tool to make
| these plans. It can't exist.
|
| Do the hard thing and plan projects individually.
| rramadass wrote:
| >This mentality of thinking is exactly the problem
|
| Damn right!
|
| >We are telling you that no such tool can exist to do what
| you want
|
| This is exactly right and is the biggest problem with
| "Management" types. They want a "cookie cutter methodology"
| to solve all their problems so they can be spared thinking
| through each one. Hence the various "Management" fads and
| buzzwords.
|
| The core of the solution lies with the Individual; understand
| their needs, wants, motivations, practice "Empathetic
| Management" and you will be successful.
| [deleted]
| paxys wrote:
| "Who is going to do it?" is always my first question whenever I
| am asked to estimate a piece of work. PMs/EMs are usually taken
| aback by the response, as if we are all supposed to pretend that
| all dev "resources" are equal. Yet reality doesn't fit into neat
| planning spreadsheets or burndown graphs, so often gets ignored.
| jseban wrote:
| The best teams I've ever worked with, that were the most
| productive and also had the best team work and team spirit, was
| when we assigned tasks in planning. And gave the tasks to
| whoever was most suitable to work on it.
|
| Unfortunately we were never allowed to do that, because of
| Scrum, and were only able to do it on the low down for a short
| time until management cracked down on it and enforced "anyone
| who happens to be free works on whatever is on top of the
| backlog".
| Swizec wrote:
| Devs: there are no 10x engineers!!
|
| Orgs: okay you are indistinguishable cogs and we will treat you
| as cattle
|
| Devs: no wait not like that
|
| Truth is everyone knows that who or which teams takes a task
| matters immensely. We know that if Bob leads it's gonna suck
| and if Alice does it's gonna rock and finish on time.
|
| Managers know this also.
|
| But we've constructed a corporate culture where this is not
| allowed to be said. So we bend over backwards to pretend
| everyone is equal and capable of the same things in all areas.
| Then we secretly make sure somehow by magic the truly critical
| projects are routed to the people and teams with more reliable
| outcomes.
| sneak wrote:
| > _But we've constructed a corporate culture where this is
| not allowed to be said. So we bend over backwards to pretend
| everyone is equal and capable of the same things in all
| areas._
|
| http://www.tnellen.com/cybereng/harrison.html
| john_moscow wrote:
| The corporate culture serves a very specific purpose of
| lowering the self-esteem of the 10x folks, keeping them at
| their place doing 10x work at 1x salary until they burn out.
| This is scalable, predictable, and serves management's
| interests well.
|
| It's just if you happen to be a 10x guy, for the sake of your
| own sanity, learn how to run a business and get out of the
| corporate swamp. Nothing else will bring you happiness,
| believe me.
| unobatbayar wrote:
| Isn't it insane that there are many 10x engineers who have
| created enormous amount value (creating patents, leading
| and executing projects, innovating etc.); Yet, the world
| will only know about the company or the CEO and never the
| engineers behind it.
| RNCTX wrote:
| There are other ways to be known.
|
| https://www.dallasnews.com/news/crime/2021/04/27/allen-
| man-w...
| polskibus wrote:
| People often forget that the 10x guy is 10x only in the
| domain he's been working on, and many chores has been taken
| away from him by his manager and given to someone else. It
| is fairly easy to make a 10x someone closer to a 1x just by
| changing his tasks and giving more chores like CR, bug
| fixes, more mundane features or GUI etc. Sure it will often
| be better quality but in areas where it matters less.
| Jensson wrote:
| Ensuring people work on what they are comparatively best
| at is a feature. 1x engineers would also get a lot less
| done if they had to clean the toilets and sweep the floor
| and many of the other low end tasks others do, instead
| they assign people who cost less to those tasks.
| polskibus wrote:
| That's argumentum ad absurdum though. There may well be
| people that are useless in a given profession, my point
| was not about that. My point was that 10x occurrence
| should be analysed within specific project, work division
| within the team, etc. For most 10x programmers in a
| project it does not guarantee repetition of 10x on a
| different type of project or problems. Matching problem
| with a team member and ensuring he has a chance to become
| 10x at it is something that good managers do.
| crispyambulance wrote:
| I think people also don't realize that high-performers
| weren't always high-performers. They had to hone their
| skills, usually by doing years of the right kind of
| challenging work with modest rewards, and sometimes they
| can be formed by exceptional mentoring.
|
| But however they got there it took time, it's something
| that can be cultivated as long as folks aren't treated as
| fungible.
| PeterisP wrote:
| I disagree, the few really high-performers that I have
| worked with were high-performers already from the first
| week with a new technology, from the first month in their
| first job, and already as a student during practical work
| they were more productive than most people who had many
| years of challenging work behind them.
|
| Experience is important and adds up, honing the skills
| makes everyone better, but it's orthogonal to this issue;
| there are people that will very quickly outperform
| someone who has honed their skills for years, and once
| _they_ have honed their skills in that domain they might
| perhaps start outperforming them by the mythical 10x
| ratio.
| crispyambulance wrote:
| I guess it depends on how one defines 10x or "high
| performer". Prodigies and maestro's will always be few
| and far in-between, is that what is meant by 10x? I don't
| know. But given the relative abundance of 10x'ers
| anecdotes in discussions in places like HN, I always just
| take that term to mean "really good" or perhaps just
| fuzzy romanticizing-- and not literally able to do the
| work of 10x "mortals".
| jseban wrote:
| Well, he became 10x in the domain, and the other did not
| become 10x, it's not like he was born with this
| knowledge, he just took it more seriously and went deeper
| varjag wrote:
| No, some people are a lot more productive across broad
| range of tasks. Often they are assigned tougher/critical
| stuff though because it doesn't make sense them do
| trivial tweaks.
| kortilla wrote:
| This is just a redressing of the same "everyone is just
| as good" bullshit. Some people get a fuckload more work
| done because they go down the right design paths to start
| with, know how to work effectively, know what pieces to
| skip, etc.
|
| The same is true in nearly every field. Programming is
| not special.
| polskibus wrote:
| I deliberately used "closer to 1x", but let me respond
| with an anecdote. I know several people, each working in
| a different org, who explicitly manage their managers by
| demanding to work on issues that have good visibility,
| are not too short >2 weeks but not too long <2-3 months
| so they are ready before the next review period. This way
| they are seen from the outside as very good performers
| while someone else is doing the less appreciated (but
| still essential) work.
| silexia wrote:
| I built and own a company with 200x employees building a
| wide variety of websites for people.
|
| The 10x programmer is real. The 5x salesperson is real.
| The 20x manager is real.
| polskibus wrote:
| Sure they are, I'm arguing that their force multiplier
| has to be taken with the context they are in, and that
| the change of the context can reduce the multiplier.
| kragen wrote:
| Jeff Dean was 10x when he wrote EPI INFO, he was 10x when
| he worked on profilers at DEC WRL, he was 10x when he and
| Sanjay Ghemawat wrote MapReduce, and he was 10x when they
| rewrote Google's search indexer. Maybe 1000x or 10000x,
| really. It's true that part of that was that he worked on
| things that mattered instead of things that didn't, and
| he could have found himself in a situation where he
| didn't have that opportunity. But it's clearly not just
| productivity in a single domain, and it's not because
| someone else was fixing all his bugs.
| Dudeman112 wrote:
| There are statistical outliers in every single thing that
| has a big enough amount of samples and that it is
| possible for there to be statistical outliers.
|
| Maybe you attract those like flies are attracted to
| honey, but pointing out that an Einstein existed isn't
| really helpful for approximately all teams of physicists
| out there, minus one or two teams
|
| I'm not even saying there isn't a huge quality variance
| in the regular pool of programmers, mind you. Just that
| pointing out the existence of bad motherfuckers in a
| population of a few million people shouldn't come as a
| surprise.
| varjag wrote:
| The proverbial '10x developer' is by definition an
| outlier tho yet people never stop arguing they don't
| exist.
| Dudeman112 wrote:
| I'd wager that has something to do with jumping the
| shark.
|
| People feel the need to chat about 10x developers when
| they don't even agree what a 1x developer is, and when
| they do present a definition, that definition is a
| function of (company, team, project, existing code base)
| which means there are more possible instances of 1x
| developers than the amount of developers who have ever
| lived.
|
| Everyone is better off if they just ditch the "10x" which
| has connotations that programming nerds will latch on to
| and just use "highly performant dudes".
| [deleted]
| dtech wrote:
| I'm not sure you can generalize from the top 0.001% like
| Jeff Dean to the top 10% or even 1%
| Dylan16807 wrote:
| "10x" is still treating people like cogs, it's just having
| cogs of different size.
| systemvoltage wrote:
| I like being treated like a cog instead of playing pretend-
| games of making me feel like a unique flower (but truth is
| still that I'm a cog). I prefer honesty. I prefer the
| brutal, unvarnished reality over executive bullshit.
|
| A cog means I have specific responsibility and I will make
| sure I don't hog down the entire machine. I work well with
| other cogs - we mesh perfectly. Being treated like a daisy
| with beautiful narrative of lies would eventually lead to a
| delusional state of mind, dissent and ultimately negative
| spiraling burnout.
|
| Former is peaceful, the latter is deceit.
| jseban wrote:
| But one of you really is a daisy, people are not equal,
| and those daisies are actually what's responsible for
| most of this machine and it's origins in the first place.
| Without daisies there will be no place for cogs, the cogs
| come after the daisies
| ncmncm wrote:
| Not only are there 10x engineers, I personally know an
| objectively measured 500x engineer. He is humble because he
| knows someone who produces 10x what he does (albeit spending
| twice as much time at it).
|
| The measurement happened as a result of a joint venture
| between Siemens AG and Ericsson called Ellemtel. Each company
| sent 250 [edit: not 500] engineers. It was a six month
| project, the classic death march: if it did not deliver on
| time, the parent companies would not be paid.
|
| At the end of the project, half the code delivered was his.
| Had he not been on the project, it would not have been
| completed on time, so no product would have been delivered.
| [Edit: Thus, it is not really the line count that makes him a
| 500x engineer.]
| bcrosby95 wrote:
| This really isn't my experience with super productive
| engineers. Usually they're solving high level technical
| problems for the company that most employees wouldn't touch
| with a ten foot pole. It isn't the raw LOC they produce but
| their ability to translate complex technical problems into
| elegant solutions for everyone else to take advantage of.
| ncmncm wrote:
| The Death March is not a usual circumstance. In usual
| circumstances, different practices are indicated.
| mrisoli wrote:
| Assuming you can objectively measure someone like this,
| either by LoC or delivery times, this is the wrong way to
| approach any project.
|
| Having a 10x engineer(or even worse, a 500x engineer in
| this alleged case) is a huge risk for the company, should
| the engineer want to leave or if they are incapacitated in
| a tragic event, the company is severely handicapped,
| ideally a so-called 500x engineer should spend less time
| writing the actual code and instead mentoring/managing
| others to scale up their knowledge, should the company do
| this right, they might not deliver on time, but they'll
| have a much wider array of experts when something breaks or
| for the next projects, reduces overall company risk and
| it's more profitable in the long run.
| lostcolony wrote:
| Maybe he was an amazing engineer 100s of times better than
| anyone else on the project...or maybe he was a bottleneck
| for everyone else.
|
| The latter I've seen. A lot. The former I have not.
| PragmaticPulp wrote:
| > I personally know an objectively measured 500x engineer.
| He is humble because he knows someone who produces 10x what
| he does (albeit spending twice as much time at it).
|
| So your 500X engineer knows a 5000X engineer and he wrote
| as much code as 999 other engineers combined? (That would
| make him a 999X engineer, FWIW)
|
| A 500X engineer (per your measurements) would have to write
| 500 lines of code every day without fail, while all 500
| other engineers in the entire company could only average 1
| line of code per day. And the 5000X engineer they know
| would have to write 5000 lines of code per day while
| everyone else was only limited to 1 line of code per day.
|
| Not just one day, but _every single day_ for six straight
| months. And all of their managers would have to somehow not
| notice this disastrous situation for the duration of the
| project. Come on.
|
| I think you've been fed some exaggerations.
| iratewizard wrote:
| I remember a day when one of my engineer's full days of
| work was one line of code. Not all lines of code are made
| equal
| sneak wrote:
| https://www.folklore.org/StoryView.py?story=Negative_2000
| _Li...
| ncmncm wrote:
| And, not all projects are death marches. It is generally
| hard to measure value, which is one of Dan Luu's points.
| Counting lines of code rarely produces a very good
| answer, but sometimes that is the best you have. Company
| revenue can be meaningful. When a contribution that makes
| the difference between $X million revenue and $0, against
| 250 years worth of engineers' salaries, it is hard to
| quibble. 500x is as good a number as you can get.
| wittycardio wrote:
| You don't measure code by the number of lines written,
| you measure it by amount of productive value. Early
| engineers at Google were easily 500x ( keep adding more
| zeros if you want ) more valuable to google than a random
| swe today
| ncmncm wrote:
| If you thought this was about lines of code, you were not
| paying attention.
| moralestapia wrote:
| By measuring productivity on lines of code written you
| show just how inexperienced and naive are.
|
| Are you HR, by chance? Have you ever coded something in
| your life?
| [deleted]
| Jensson wrote:
| For any positive real number X and employed engineer A
| with positive productivity, I can find an employed
| engineer B where productivity of A is more than X times
| the productivity of B.
|
| Proof: Pick B to be an engineer with productivity 0. 0 *
| X = 0 for all X. Productivity of A is defined to be
| positive, so is greater than 0. Hence productivity of A
| is greater than X times the productivity of B.
| JBiserkov wrote:
| And then there's people with negative productivity.
| ncmncm wrote:
| The person who told me about this was the person who
| counted up the code at the end of the project. And, yes,
| it was 250 from each, not 500 from each parent company.
| (Memory is funny that way.)
|
| I do not doubt that the numbers were rounded for
| simplicity. It is meaningless to talk about a 499x
| engineer.
|
| As was explained to me, this engineer assigned two-week
| work units. If the work was not ready at the end of two
| weeks, he wrote it himself over the weekend. So, a fair
| bit of code was written that did not make it into the
| final product.
| pseudalopex wrote:
| > If the work was not ready at the end of two weeks, he
| wrote it himself over the weekend.
|
| Using no code or knowledge from the past 2 weeks?
| ncmncm wrote:
| That would have taken longer.
| pseudalopex wrote:
| Using it or not using it would have taken longer?
| ncmncm wrote:
| Trying to use somebody else's code that does not solve
| the problem generally takes longer than writing it
| yourself.
| pseudalopex wrote:
| Solving a problem isn't all or nothing.
| druvisc wrote:
| For it to matter, it is.
| newaccount74 wrote:
| But looking at someone elses code first generally makes
| you faster even if you end up not using any of it.
| ahtihn wrote:
| That's a ridiculously wasteful way of managing work. I
| too can be a 10000000x engineer if I never let others
| actually merge their code and just write it myself
| instead.
| ncmncm wrote:
| It was a way that delivered product on deadline, for
| exactly that project. Every project has specific needs.
| If you code to some other project's needs, you do the
| wrong thing.
| Jensson wrote:
| If you hired engineers like they hired them before coding
| interviews combined with a decade of the dead sea effect
| I can easily see a team of 500 barely getting anything
| done at all. Big organizations are often grossly
| mismanaged like this which is why smaller organizations
| can beat them.
| deckard1 wrote:
| mismanaged, yes. But also risk-adverse and encumbered
| with process. At a big corp you may need 5 or more sign
| offs on a single merge. I probably spend a good 40% of my
| time herding cats and babysitting the merge pipeline.
| There is a lot of overhead you simply won't find in a
| startup.
| fitzn wrote:
| Measuring programming progress by lines of code is like
| measuring aircraft building progress by weight.
|
| - Bill Gates
| mostertoaster wrote:
| And I bet an in progress airplane that weighs a 1000lbs
| is further along than an airplane that weighs 1.
| bdavis__ wrote:
| Note this applies to the manufacturing,not the design.
|
| It is actually a wonderful analogy with software:
|
| * to a first order, cost of the materials in an airplane
| are proportional to the weight * at design time, the
| weight of the aircraft is minimized. thus, political and
| management forces cannot change it.
|
| just like software, each subsection that is bolted on has
| different weights; but if you average it out it is a good
| measure of progress. and cost.
| ecnahc515 wrote:
| And if I build a paper/balsa wood airplane that's 1 pound
| and can carry a mouse?
|
| It all depends on what the actual "airplane" (product)
| that's being built is.
| kragen wrote:
| Not if they have the same wingspan; the "1000lbs"
| airplane is 0% done because it will never fly.
| ddalex wrote:
| sure, because they are measuring progress towards
| completion, rather then the ability to fly
|
| i.e. if a finished plane weights 10,000 lbs all put
| together, then a in-construction plane currently at 1000
| lbs is clearly further along towards completion then one
| at 1 lbs
| slingnow wrote:
| What were you trying to say? You realize a Boeing 747
| weighs over 400,000 lbs. And a tiny Cessna 172 weighs
| ~1500 lbs.
|
| If the planes have the same wingspan, it's likely they're
| in the same class, and weight is a perfectly reasonable
| measurement of completion percentage.
| tremon wrote:
| It's a nice aphorism, but it's a very bad analogy. Before
| the build of an aircraft is started, the target weight of
| the assembled product is (roughly) known. Therefore, in
| the process of building an aircraft, the assembled weight
| at least goes up from 0 to $target -- in an erratic
| fashion, but it's still a continuous measurement.
|
| I have never seen a program design specification that
| even attempted to quantify the lines of code of the end
| product, let alone be accurate.
| fitzn wrote:
| The initial comment was related to attribution for "who
| built" some piece of software based on lines of code. The
| analogous argument would then be assigning attribution
| for the built aircraft to whoever produced the heaviest
| components. Given that that would be illogical, I think
| the analogy is apt.
| [deleted]
| sangnoir wrote:
| LoC is a terrible metric - did they count the lines other
| engineers removed?
|
| I was half of a very productive duo on a greenfield project
| subsystem - a project I joined midway: my partner wrote a
| lot of code, I estimate ~70% of final lines in the code
| base were his. What the LoC count won't tell you is all the
| refactoring, deletion, tests and error handling code I had
| to add, because his code _only_ worked for the happy path.
| Can you say he was being 2x more productive than I was? I
| say no, because he was breaking the nightly build at least
| once a week before I joined, blocking the rest of the team,
| this ended when I added pre-commit tests.
| ncmncm wrote:
| When the numbers are large enough, the details don't
| matter much. Maybe he is really only a 250x engineer? A
| 100x engineer? It doesn't change the fact that without
| him no product would have been delivered.
| Aqueous wrote:
| no, no, no, no.
|
| if you deliver the product only by taking shortcuts that
| impede other engineers you do not get credit for
| 'delivering' the product.
|
| having been the next engineer to come along, this
| attitude drives me up a wall.
| sangnoir wrote:
| > It doesn't change the fact that without him no product
| would have been delivered.
|
| I agree. I'm only arguing that there are times when
| engineers who enable "10x/100x" engineering don't get the
| visibility they deserve, sometimes until after they quit.
|
| This hits close to home for me as I witnessed my partner
| being showered with praise for being "super productive"
| based on LoC alone, code which wasn't close to being
| production-ready. If you don't care about code quality,
| and want to be seen by management/people outside of your
| team as a 10x engineer with minimal effort: you can
| follow the same playbook.
| ncmncm wrote:
| Agreed. It is rare that you can get objectively
| meaningful numbers. So, while it is convenient that half
| the code delivered was his, that is not the meaningful
| measure.
|
| When I was in school, the standard for engineer
| productivity was 10 lines of tested code per day,
| averaged. Maybe we do better today, with fewer footguns
| and faster compilers. But we expect more meaningful
| results from a line of code, too.
| gonzo41 wrote:
| This is pretty much exactly true. Though I must say being a
| person who comes in and get plonked on the underperforming
| team. It'd be really progressive if the Alice character had
| to take on some fresh blood to share around the knowledge and
| let new people build rep. Nothing sucks more than being on an
| underperforming team.
| 3grdlurker wrote:
| It's incredibly reductionist to think that productivity is
| inherent to an individual when the world is never that simple
| and there are always a lot of factors involved in any
| outcome. Even the people that you think are "10xers" will
| stumble under the right circumstances, and the converse is
| also true about the people you think are incompetent.
|
| It's not so much that we built a culture that disallows these
| things to be said--I'm sure you have the freedom to say that
| to people if you're prepared for the consequences. It's just
| that it's such a hasty, unnuanced thing to say, and business
| decisions should not be made on the basis of rash remarks
| that aren't very well thought-out.
| Jensson wrote:
| > Even the people that you think are "10xers" will stumble
| under the right circumstances, and the converse is also
| true about the people you think are incompetent.
|
| Right, the 10x engineer isn't benching 10x more than you or
| running 10x faster than you, nobody thinks that 10x
| engineer means 10x at every possible task.
| 3grdlurker wrote:
| But then you have to ask what metrics are being used to
| define a 10x engineer. You'll see that everyone has a
| different version of that and therefore whether a 10x
| engineer exists solely depends on the ontological
| argument for a 10x engineer. By the end of the day 10x is
| subjective because teams have different needs.
| Jensson wrote:
| If you can replace an entire team of 10 engineers paid to
| work on something with a single engineer then that
| engineer is a 10x engineer, as long as the "10x engineer"
| didn't originally write the things they work with. That
| is my definition.
|
| > By the end of the day 10x is subjective because teams
| have different needs.
|
| Replacing 10 salaries with 1 salary isn't subjective at
| all.
| 3grdlurker wrote:
| Of course it is subjective. This is literally what you
| said:
|
| > That is my definition.
|
| You obviously care about optimizing for salary expenses.
| Most companies have room to hire more people who can do a
| few things well, so their definition of 10x would be
| different because they'll have different expectations of
| their employees.
|
| And really, if your definition of a 10xer is some poor
| fool who's willing to take the job of 10 people for a
| single person's salary, good luck finding someone who
| wants to spend their lives living that way.
| Jensson wrote:
| > And really, if your definition of a 10xer is some poor
| fool who's willing to take the job of 10 people for a
| single person's salary, good luck finding someone who
| wants to spend their lives living that way.
|
| Right, they are paid more. The going rate for good people
| is around 1.5x up to 10x for exceptional cases.
|
| Edit: And I am not talking about minimizing cost of
| salaries, I am talking about how much a good software
| engineer should demand. If he can replace 10 salaries
| with one then he has a lot of leverage he should use to
| get a higher salary, if the company isn't paying him then
| he should leave for a company that appreciates his
| skills. Plenty of companies pays premium money for
| premium talent.
| 3grdlurker wrote:
| I mean, if all you're saying is that "better programmers
| deserve better pay", then you're not exactly saying
| anything groundbreaking and the concept of "10xer" is not
| going to be necessary to make that point. It should also
| be noted that the salary that you get isn't just a
| product of your talent but also of how well you sell
| yourself. Amongst many other factors, of course.
| Jensson wrote:
| Salary isn't just a factor of skill, but willingness to
| pay high salaries is the same as belief that skill
| matters a lot. A manager who doesn't believe in high
| developer skill variation will not pay significantly
| above market rate, while a manager with strong beliefs in
| skill variation will pay huge amounts for the right
| people. Therefore I see any arguments against 10x
| developers as an attempt to supress wages, likely
| managers who wants to hire good developers without paying
| them more than average developers, or developers who are
| jealous of others salaries. Luckily a lot of companies
| acknowledges that talent matters a lot and pays a lot for
| it, and today the highest valued companies in the world
| belongs to that group.
| mostertoaster wrote:
| So y'all don't disagree with the main point.
|
| There are some specific individual engineers who will get
| a specific individual task, faster than some other
| specific engineers.
|
| If those same specific engineers get done many general
| tasks faster than another group of specific engineers on
| general tasks than they are just better in general. If
| some other specific task gets done by the other specific
| engineers better then it is just different domains.
|
| Either way the individuals matter.
| 3grdlurker wrote:
| So a fast programmer is necessarily better than one who
| takes a little more time but pushes out stabler code?
| mostertoaster wrote:
| Touche, same quality just one done twice as fast let's
| say. Just a hypothetical.
| topkai22 wrote:
| Nah, it's beyond that. I know a dev that is the most
| brilliant ux dev I've ever met. He can create beautiful,
| dynamic, understandable UIs literally 20x than I can.
|
| However, he is just medeicore at must other tasks-
| constructing a common data model, scaling the backend or
| analyzing the data be is slower than I am, if he engages
| at all.
|
| More recently I told my manager that I was intimated by
| how effective one of my coworkers was at his job (data
| science and BI.) He laughed and said my coworker
| basically thought the same of me (doing more standard
| software engineering.
|
| Highly effective engineers are often only effective at
| limited aspects of the business of software engineering
| and it takes a good team structure of diverse talents to
| make everyone effective, even in the domain of software.
| Jensson wrote:
| That was my point, arguments such as yours are just
| arguing with strawmen. 10x is compared to another
| professional in the same domain. Saying that the engineer
| isn't as effective at another domain as a professional of
| that other domain is arguing with a strawman.
| Jetrel wrote:
| It's not really a strawman considering it's EXACTLY what
| most companies are trying to do: make programmers
| fungible across domains. Critically; they're doing this
| because they typically have no visibility into these
| skillsets from the managerial level, and they typically
| only have one or two programmers "in a given domain" on a
| team - even in a very, very large company. The company
| would _like to_ pretend these people are fungible, and
| can be interchangeably swapped out, but the reality is
| they have no immediately replacements on the team.
|
| There's no sense in doing an apples-to-apples comparison
| when you've only got one apple, an orange, and a pear.
| Swizec wrote:
| > will stumble under the right circumstances
|
| Exactly. Not every task or goal fits every person equally
| well. A good leader understands this and does their best to
| find that fit.
|
| But it is in my experience not considered okay to talk
| about this too openly because people get offended.
|
| You wouldn't ask your best engineer to lead a marketing
| campaign or your best marketer to design your servers.
| They're smart and would figure something out eventually,
| but who gets the task matters.
| [deleted]
| csande17 wrote:
| > It's not so much that we built a culture that disallows
| these things to be said--I'm sure you have the freedom to
| say that to people if you're prepared for the consequences.
|
| When people say that "you aren't allowed to say" something,
| they don't mean the government uses magical mind control
| rays to prevent your mouth from physically producing the
| words. "Consequences" _are the mechanism_ by which speech
| is prohibited in societies without access to magical mind
| control rays.
|
| (Not to pick on you specifically; I've heard this line a
| lot lately.)
| 3grdlurker wrote:
| I mean, I get your point about the government but now
| you're just complaining about how being insensitive to
| other people has the consequence of them fighting back.
| [deleted]
| teddyh wrote:
| Now you're moving to assume that everything that has
| consequences is due to somebody being insensitive. It
| could also be, for example, that the person initiating
| consequences is entirely too sensitive.
| 3grdlurker wrote:
| So you're gonna go around the office to point fingers and
| tell on people that they're not 10xers, and then call
| them too sensitive if they react? You're talking in
| abstracts but if you put what you said in context (ie
| this discussion) it doesn't make sense.
| teddyh wrote:
| > _So you're gonna go around the office_ [...]
|
| This discussion is not about me, nor did anyone advocate
| that behavior. You are making up scenarios in your mind
| about what other people in this thread are thinking and
| saying, but these things are all imaginary on your part.
| philipswood wrote:
| I remember finding a site (a design patterns repository
| page of all things) that explained the nuance of different
| people having different expected outcomes on different
| domains well.
|
| But despite searching for it for years I haven't been able
| to find it again - web searches tend to be bad at finding
| things that you found before, again.
|
| Anyway, this was described as the "movie producer pattern"
| (maybe it was director)
|
| I remember it going something like this:
|
| As opposed to the factory worker pattern which describes
| people who perform simple tasks that are straightforward
| and are easy to learn and perform and are hence
| interchangeable, it is more accurate to use the movie
| producer pattern.
|
| A producer will have shown his or her abilities in a
| specific set of movies, each with a certain style and
| genre, which will lend credence to their ability to perform
| similar work in a similar genres. It's clear however that
| the specific director will make a large impact to the final
| movie and will have a personal touch.
|
| For engineers, Susan, who has spent the last decade honing
| her skills on language VM implementations is expected to be
| an all around star resource, but would probably be a more
| trustworthy choice for more VM work as opposed to
| implementing a graphics engine or database.
|
| (In analogy to a director with a string of science fiction
| movies who might not be the best choice for a romantic
| comedy)
| MrPatan wrote:
| What you cannot say is that there are 0.1x engineers.
| visarga wrote:
| Maybe a mix of x0.3 and x3 engineers.
| jseban wrote:
| In my experience there are plenty of -10x engineers.
| astrange wrote:
| That's acceptable if they're interns/juniors. If you only
| hire the best people for the job, you're never going to
| get any new people.
| zweifuss wrote:
| 1x is defined as the least productive engineer in a team.
| But I know what you mean. Sometimes a team can be more
| productive with fewer people.
| xmprt wrote:
| I'm "10x" when working on one part of the system that I'm
| extremely familiar with but "1x" when it comes to other
| areas. Similarly, I have teammates who are "10x" in those
| other areas but wouldn't know where to start when it comes to
| my specialty.
| grayclhn wrote:
| You make it sound like you shouldn't get credit for knowing
| where you provide the most value and putting yourself in
| position to be most effective. :)
| [deleted]
| RNCTX wrote:
| > But we've constructed a corporate culture where this is not
| allowed to be said. So we bend over backwards to pretend
| everyone is equal and capable of the same things in all
| areas. Then we secretly make sure somehow by magic the truly
| critical projects are routed to the people and teams with
| more reliable outcomes.
|
| Do you really think that was the motivation? That someone is
| going to bat for Bob at Alice's expense?
|
| Or do you think it more likely that "equality" is another way
| of saying both Bob and Alice will _never_ threaten someone in
| management enough to cost them even a minute of sleep on any
| given night, and that 's all management really cares about at
| the end of the day.
| wokwokwok wrote:
| The irony here is that the point of the article isn't that
| "10x engineers" do/don't exist, it's that "things are more
| complicated than that".
|
| Assigning arbitrary labels (like 10x engineers...) so it's
| "easy to understand" results in over simplified models that
| lead to faulty decision making based on invalid assumptions.
|
| ...treating everyone equal is perhaps _also_ a faulty
| assumption, but it's _easy_ , and dealing with complex
| systems is hard.
|
| Maybe instead of bitching about equality, which is just a
| symptom, we should promote using _complex models_ instead of
| easy trivial ones.
|
| ...because just using _different_ easy trivial modes is
| stupid; it won't get you any better outcomes.
| MattGaiser wrote:
| Even if there aren't 10x engineers, there are still engineers
| with different levels of skill and knowledge in different
| areas.
|
| One of the best engineers I ever worked with was terminated
| (he was a contractor) as he spent his career on the backend,
| was told he would work on the backend, and they assigned a
| complicated React feature to him over his objections that he
| had no knowledge of the framework or frontend dev in general.
| sangnoir wrote:
| Isn't the "10x" label contingent on engineers being
| functionally indistinguishably, except some are allegedly 10x
| more productive? Specialization is what I figure has highest
| impact on turnaround times in a team setting. Just because an
| engineer is the most familiar with a component/subsystem -
| which allows them to make changes _to that subsystem_ faster,
| doesn 't make them an all round 10x engineer.
| PeterisP wrote:
| IMHO it's also an useful illustration that being able to
| replace people is asymmetric.
|
| It may be that Bob can do Joe's specialization at half
| speed, but it's plausible that Joe can't do Bob's
| specialization properly at all, even after a year of
| training; so replaceability only works one way.
|
| And I have worked with engineers that could do improvements
| to an unfamiliar component/subsystem _faster_ than the
| current engineer who is the most familiar with it; i.e.
| their time of learning+adaptation+implementation was faster
| than the other persons ' implementation alone. And it's not
| that the other engineer was incompetent, they were quite
| reasonable.
| Jensson wrote:
| It refers to people with the same experience with the
| system. For example, lets say you have two persons working
| with a system and have worked with it for two years. One of
| them is 10x as productive in that system than the other.
| Neither of them had experience with such systems prior to
| this, so both were equally productive when they started,
| but one of them grew much faster and is now 10x the other.
|
| Of course if you took those two and put them to work at a
| new system both would have 0 productivity initially as they
| learn the new system, but as they grow the differences
| starts to appear and soon you have a very stark contrast
| again.
| tomnipotent wrote:
| A 10x'er is by definition an outlier. It would be absolutely
| silly for a business to build its planning on the existence
| of outliers in its staff, unless the company is small (< 20)
| and that individual is a co-founder or someone you can really
| rely on.
|
| People leave companies for other opportunities even when they
| like their current job. I have to plan for that, whether it
| hurts someone's ego or not.
| wyclif wrote:
| _HR didn 't care that the person made the company more money
| than HR saves by doing location adjustments for all
| international employees combined because HR at the company
| had no notion of the value of an employee, only the cost,
| title, level, and location_
|
| This is common in large, dumb corporations: HR is the Blob.
| And if you are being recruited by a company that exemplifies
| that kind of culture, run away, far, far away.
| Agentlien wrote:
| It may be a culture thing, but across the three companies I've
| worked at every estimate has been explicitly assuming a
| specific person handles it. Sometimes we've even given several
| estimates for the same task depending on who it gets assigned
| to. No one has ever found this odd. It's just obvious that
| different people have different skills and familiarity with
| different technologies or parts of the project.
| rramadass wrote:
| This is how planning should be done. Gauge people's
| expertise, put them on the path they can be most effective
| and then ask for their estimates. Take that to upper
| management and negotiate.
| dspillett wrote:
| One problem with that is sometimes the estimates are done
| long before the work starts so when that item eventually
| gets to the top of the priority stack the person estimated
| for is working on something else instead. At this point
| things need to be re-estimated which can cause friction if
| the new estimate is longer ("but last time, you said..." or
| "when we asked Bob, he said...").
|
| What I've done in the past is give an estimate based on
| what a "standard" dev can be expected to do (everyone
| understands a junior is expected to be slower as they are
| new, that is why they are currently a junior and when they
| get up to speed they'll be promoted) with a comment on the
| ticket that the expected time will reduce by x if a named
| resource, or one of a group, is available to work on it.
| That way, medium term planning can be done on the basis of
| a "reasonable case" scenario and if the right people are
| available things will go better (and if there are multiple
| items in that state, short term planning will include
| deciding which ones being sped up, by using that person's
| time, confers most extra value).
| rramadass wrote:
| Right, things are always probabilistic when it comes to
| us Humans :-)
|
| I like to think of it like Algorithm Analysis; Best-Case
| (estimate by the expert mentioned above), Worst-Case
| (estimate by Noob who just joined the project) and Avg-
| Case (estimate by person who is already part of the
| project but is not responsible for that module). Add a
| fudge factor based on your reading of the circumstances
| and then haggle with Management. You now have a band with
| a upper bound and lower bound which can be realistic.
|
| PS: You may find Douglas Hubbard's _How to Measure
| Anything: Finding the Value of Intangibles in Business_
| useful in this regard.
| denton-scratch wrote:
| > things need to be re-estimated which can cause friction
|
| But, but ... isn't every estimate supposed to be
| provisional? Aren't you supposed to be re-estimating
| regularly?
| Agentlien wrote:
| That's exactly what I was thinking of when I said we
| sometimes give estimates depending on who it gets
| assigned to. "It'll take a day if X does it, but probably
| three if another SE does it".
| monkeybutton wrote:
| There's no need to be offended either. I will gladly estimate
| a task taking longer for me to do when I'm not the original
| author or would be using languages and frameworks I don't
| have much experience in. We just give the estimates and let
| the PO prioritize what they want.
| selfhoster11 wrote:
| That's brilliant. So much bike shedding about what complexity
| a task has could be avoided.
| dpweb wrote:
| In my manager days I simply assigned a factor to each team
| member based on the type of work, so one person may be baseline
| hrs * 1 and another hrs *.8
|
| This had to be accurate, as it's consulting, if the hours are
| wrong we lose money.
|
| But only a direct line manager can do this, anyone else won't
| have the knowledge of the staffs capabilities.
| dijit wrote:
| it's even more complicated by knowledge/experience in certain
| areas.
|
| Fire me into some unknown terraform and I'll be able to
| orient myself faster than someone who only does C# every day.
|
| Send me into my own terraform and I'll be faster still. Not
| all things are equal.
| ZainRiz wrote:
| Whenever I ask an expert how long it'll take someone new to the
| their code base to add feature Y, I mentally double whatever
| estimate they give and share _that_ instead.
|
| I haven't overshot the estimate yet.
| badtension wrote:
| In my experience it still makes sense to estimate together
| using the same story points (or T-shirts) when there are people
| ranging from almost no experience to very senior ones working
| on a project.
|
| 1 SP for a senior may take 1h of his time and for a junior that
| would be 2-3 days but it's still 1 SP - a relatively simple
| task. This is in contrast to a fallacy of recalculating SPs to
| time-based units cause if we do that we might as well just
| estimate in hours/days.
|
| It's about agreeing on some baseline first (what does 1, 2, 5
| SP task look like?) and going on from that. We just need to
| remember that velocity will be different for different people
| so team capacity calculation is going to be all over the place
| but I think this approach can be useful.
| Kalium wrote:
| I got a harsh lesson about this in one of my very first jobs.
|
| A senior engineer on my team had built a rather complicated
| system. He was accordingly intimately familiar with all aspects
| of it. So when he estimated something on that system, it came
| with nearly all the discovery work already done.
|
| The PM proceeded to take an estimate from this person, hand it
| to a brand new hire, and expect them to deliver on that.
| Needless to say it could have gone better for me.
| radicalbyte wrote:
| That engineer is Senior in title only. Unfortunately this is
| a common pattern - a mid-level developer will play "hero",
| make a mess that only they understand, and - if given the
| title/responsibility by immature management - proceed to
| royally screw their team.
|
| Actual Seniors have the experience and foresight to handle
| this properly. Either build code with enough
| documentation/tests that others can understand it, or make an
| onboarding/mentoring plan for team mates, or estimate based
| on a teammate doing the work.
|
| In this position: the engineering manager should remove the
| fake Senior from the team, that will force them to get up to
| speed.
| nzmsv wrote:
| Up to speed on their way out the door if they have any self
| esteem at all.
| jseban wrote:
| Yeah why do people have this view on programmers I just don't
| understand, every other single effing job in the world
| requires training and ramp-up, except programmers? And the
| fact that programming is depending on a unique pre-existing
| really complex code base further speaks against this.
|
| When my product owner quit, the new guy was working in
| parallel for 2 months to learn the ropes, noboby bats an eye,
| but a programmer is productive from day zero and all
| programmers have exactly the same output. It's so wrong
| jart wrote:
| If you wrote a novel and wanted your friend to write the
| final chapter, then would you need to train them in your
| novel beforehand? Not that much different from programming.
| marcus_holmes wrote:
| We're just the nerds who push the nerd-buttons. We don't
| need to understand how it works, or why it should be this
| way not that way, or what the margins are. Just push the
| nerd-buttons and the damn thing work like it does in my
| head! All the hard work has been done by the ideas people
| who had to do all the creative stuff and make all the hard
| decisions. Now it just needs to be put into the computer-
| thingies and work!
|
| /s, obviously
| markus_zhang wrote:
| I think it depends on the culture of the company. Some
| companies do allow engineers say a month to catch up.
| hyperman1 wrote:
| I think they underestimate the value of specific knowledge.
| A builder that can build X meters of wall every day van do
| that reasonably independent of the building site. X will of
| course vary when you give a new kind of stones. The problem
| with programming is every job has its own kind of stones.
| mhb wrote:
| And they overestimate it when writing job ads.
| BenoitEssiambre wrote:
| I find that doesn't really capture the difference. In
| programming, the building part is fully automated. You
| press play or type a compile command and wait. If someone
| wants a build estimate, you should give them the time it
| takes to compile an deploy. Code is blueprint. Writing
| the code is all engineering, R&D, design and architecture
| and it usually entails figuring out how the system will
| interface with countless protocols, legacy systems,
| details of user's lives etc. It's nothing like building
| something that is already fully planned. It's a lot more
| like researching and planning all the details.
| rramadass wrote:
| >I think they underestimate the value of specific
| knowledge
|
| This is the crux of the issue. When it comes to
| "Knowledge Work" almost every step sooner or later
| becomes a specialization. For example, I used to sneer at
| the role of a "Build Engineer" until i was forced to take
| up that role in one project. The combination of HW
| Platforms, OS versions, config switches, build flags,
| magic incantations etc. quickly gave me a new found
| respect for a job which i had considered "trivial".
| spoils19 wrote:
| I don't understand why you would sneer at a role in the
| first place, without at least taking some sort of look
| into what they have to do.
| rramadass wrote:
| You have missed the point of the anecdote.
|
| It is that one tends to underestimate the complexity
| involved in a particular job which has evolved well
| beyond its initial "trivial" requirements. Hence the need
| to guard consciously against such tendencies particularly
| in domains where you may not be competent.
| onion2k wrote:
| _The PM proceeded to take an estimate from this person, hand
| it to a brand new hire, and expect them to deliver on that.
| Needless to say it could have gone better for me._
|
| This is a really good thing to learn from, although I doubt
| it felt like it at the time. The key thing that every junior
| dev needs to take from it is that it's fine if things don't
| take however long the estimate is _so long as you 're
| regularly communicating with the PM_. PMs hate surprises.
| They need to know exactly what the state of the project is at
| any given moment. For them to think that a story is
| progressing on track when it's not is very, very bad (in
| their minds; it doesn't actually matter most of the time.)
|
| If you work on a story that's estimated to take 3 days and
| come back after 3 days saying "It's not done yet. I'm only
| half way through. I had to learn a ton of stuff!" then that
| knocks out loads of other things, and people get pissed off.
|
| If you work on a story that's estimated to take 3 days, and
| in the stand up on day 2 you say "I think I'm going quite
| slowly because I'm having to learn a lot, and I don't think
| I'll deliver this in 3 days" then your PM will (...should?)
| respect that you're keeping them informed. The senior might
| even step up to help you get there faster.
|
| Practically all the actual work a PM does is communication.
| If you're not communicating with them then you're blocking
| them. No one likes that.
| lifeisstillgood wrote:
| >>> Practically all the actual work a PM does is
| communication.
|
| Practically all the actual work a PM does can be replaced
| with a script and dashboard
| onion2k wrote:
| _Practically all the actual work a PM does can be
| replaced with a script and dashboard_
|
| That is entirely true if you have an organised,
| disciplined dev team that communicates well.
|
| Good luck with that.
| kayodelycaon wrote:
| This isn't true even with a organized, disciplined team.
| What happens is the responsibilities of get divided out
| to other people on the team. Usually not the entire team,
| so some people are stuck with unacknowledged overhead.
| nzmsv wrote:
| Unacknowledged overhead happens even with a PM present.
| Usually it's work that is absolutely critical to getting
| a project done but a PM would tell you it's a waste of
| time if you brought it up with them.
| lifeisstillgood wrote:
| Thank you. Another vital point - trying to tell people
| the real critical path is over there but no-one agreed it
| in the plan is .. ahh well
| subsubzero wrote:
| For small tasks, yes this works. For larger feature work
| that involves cross-team collaboration, including legal,
| security etc, a pm is a godsend.
| lifeisstillgood wrote:
| meh. The problem is authority. PM / manager as described
| above is a _co-ordination_ issue. Often administrative as
| well.
|
| Either the company is imposing administrative burden a
| that it can remove with a little effort and scripting, or
| again it is co-ordination - which software usually excels
| at.
|
| We can endlessly debate specifics but yes, there are many
| corporate environments that are almost impossible to
| navigate without full-time skilled administration - it
| that is a choice by the company not an inherent law of
| nature.
|
| I seem to recall a Microsoft anecdote where someone
| released an internal form for developers to fill out, and
| billg personally sent round collecting the form telling
| people that sort of thing was not the Microsoft way. Far
| be MSFT from an ideal but bureaucracy is a _choice_.
|
| Edit: my take on hierarchy and decision making is that it
| is clearly "obvious" that in war and times of stress
| there is only enough time for one person, the "hero", to
| review the battlefield and make decisions, which everyone
| else then follows. The problem with that is throughout
| human history that idea has literally had no better than
| 50/50 chance of succeeding.
|
| I am very much short on Project management,
| administrative management as authority and generally
| anything that points away from democracy.
| BobbyJo wrote:
| > I think I'm going quite slowly because I'm having to
| learn a lot, and I don't think I'll deliver this in 3 days
|
| Their first question after you say this will be "well, how
| long will it take?" Whether or not you actually have any
| idea how much time you'll need, you'll have to give an
| answer, and on that blows the schedule up too much will be
| strongly frowned upon.
|
| Now you've realized you're working for a crappy PM/EM who
| wants you to do their job for them, since they should have
| already known that the estimate from the first engineer
| will be nowhere close to the reality from the second.
|
| The best managers I've had have been the ones that rarely
| need time estimates. They know enough about what's going
| on, and the comparative skill levels of the engineers, to
| give reasonable estimates themselves in most cases.
| ebiester wrote:
| That is a function of time in company and continuity of
| team more than skill of manager.
| BobbyJo wrote:
| I disagree. I think skill of manager plays into it more
| than anything. I've seen managers come on board and
| within 3-6 months were able to operate like this. They
| focused on learning the technology and getting to know
| the people before they started actively managing. These
| were large, long running teams they were joining too.
| siva7 wrote:
| I think most of us have been in your situation in the early
| days of our career. I still remember these PMs after all
| those years as rather inexperienced or incompetent and try to
| make sure that it does not happen on the teams i oversee.
| astura wrote:
| This is just extremely (almost comically) bad project
| management - nobody should take a senior engineer's estimate
| and apply it to a new hire or jr engineer.
|
| I've never been a PM but from my planning discussions with
| mine all have adjusted for seniorness, familiarity with the
| codebase, and skillset. When I give an estimate I am only
| asked to give it for myself, it's the PMs job to adjust.
|
| I guess I've been lucky because I've never had a PM that did
| that poor of a job. Maybe because it's because I've almost
| exclusively worked at companies that provide work to a paying
| customer, because that environment really depends on good
| project management.
| exolymph wrote:
| It's not even necessarily about skill, could easily be that
| someone is already spearheading a higher priority or whatever.
| chairmanwow1 wrote:
| This comment made me laugh because it's so delightfully
| insightful. You are absolutely right and I've never thought to
| pose the question.
| csee wrote:
| Realizing this is important for retention. It's damaging when
| upper management falsely thinks people are interchangeble, which
| is a common view among non-technical types and HR. This leads to
| 10x people feeling underappreciated and resentful, ultimately
| causing them to resign for higher compensation and more
| appreciation elsewhere. It can literally destroy small companies
| if an individual's unique contribution isn't properly understood
| and valued.
|
| Managers should err away from language about "the group", "the
| team" or "collective" and really drill down to the level of
| individuals as much as is practical. This is the correct
| resolution for most decision making. "The team" is just an
| abstraction that's useful to a small extent for a certain class
| of decision making, but not beyond that.
| 908B64B197 wrote:
| > It can literally destroy small companies if an individual's
| unique contribution isn't properly understood and valued.
|
| It's generally cheaper to poach engineers than to buy a
| company. Just food for thoughts.
| throwawaygh wrote:
| Is this really true for small companies?
|
| A senior at FAANG is worth sometimes well north of 500K/yr.
| There are plenty of folks strewn about small software
| companies that do similar work to a senior or even
| staff/principal at a faang at wildly huge discounts.
|
| It's hard to find numbers for the value of small software
| businesses (OP's quote), but this article [1] puts the number
| at $667k. If that's true, the engineer is _SUBSTANTIALLY_
| more expensive than the business (you 're not just renting
| the business for a year).
|
| [1] In the period between 2013 and 2016, the average sale was
| $667,000. While some sales were obviously much higher, and
| some were actually a bit lower, this must be an encouraging
| figure for a business owner to see.
| PragmaticPulp wrote:
| > A senior at FAANG is worth sometimes well north of
| 500K/yr. There are plenty of folks strewn about small
| software companies that do similar work to a senior or even
| staff/principal at a faang at wildly huge discounts.
|
| Those discounts are why it's easier to poach the employees.
|
| If a company has 10 engineers earning $200K/year, why would
| you buy _the company_ for $667K per person and then pay
| _the employees_ on top of that?
|
| Just offer the employees $500K/year and they'll stream
| right over.
| throwawaygh wrote:
| Oh, I misinterpreted GP. Yes, agreed: for small software
| shops, the key senior ICs are probably worth more than
| the company itself.
| 908B64B197 wrote:
| And when acquiring an existing company, the buyer is
| typically interested in keeping a lot of the engineering
| staff. I've only seen a few acquisitions where there was
| no interest in keeping the engineering staff (North comes
| to mind; this one was strictly for Google to get its
| hands on the patent the company had acquired from Intel).
| quickthrower2 wrote:
| There are only so many $500k spots available. If every
| engineer in the world said "I'm moving to SF and applying
| to Google" and assuming visa allowed that you'd see
| Google paying a lot less for talent! Which means that
| while some people earning 200k are underpaid, they can't
| all be underpaid.
| pm90 wrote:
| Big Tech and most established companies make billions in
| profits off software products developed by engineers.
| Engineering Software Products is a highly specialized
| skill and absolutely isn't compensated to the same degree
| as its impact; Silicon Valley was the first to realize
| and reward this somewhat adequately (IMO still not
| enough).
|
| It's really great for management types that they've
| managed to restrict the median compensation at fairly low
| levels; this is also the case for software outside of the
| well known tech hubs.
| throwawaygh wrote:
| The larger worry for petite capitalists is not
| competition with large tech, but rather the possibility
| that senior engineers at small firms realize that they
| _are_ the firm and have enough savings to jump ship,
| build an mvp, and cannibalize the old business.
| big_big_data wrote:
| Not everything is just about the salary
| Jensson wrote:
| Salary is per year, buying a company is a one time cost.
| Retention agreements are a part of the purchase so they
| know the employees they got will be forced to stick
| around if the purchase goes through.
| philipswood wrote:
| Gelled teams are an actual thing though.
|
| A good team can be better at something than all it's seperate
| members.
| Jensson wrote:
| And a bad team can be worse at something than all it's
| separate members.
| [deleted]
| hinkley wrote:
| What I've experienced at companies on a death spiral is that
| there are a few people everyone can agree are useless, and
| beyond that you start picking people based on your poor
| understanding of how the sausage is actually made.
|
| Once someone really useful has been let go, you have the sudden
| realization that your situation isn't that different than
| theirs. If management can misunderstand Tim's value, they sure
| as hell can misunderstand yours. At which point everyone's
| productivity is compromised by existential dread, and the
| wheels just start coming off faster.
| quickthrower2 wrote:
| Yeah been there, and instaquit. That company seems to be a
| shell now.
| hinkley wrote:
| This experience contributed greatly to How I Learned to
| Stop Worrying and Love the Severance Check.
| lewisl9029 wrote:
| This is also why I really love working with software, because
| it's one of the greatest force multipliers on the potential
| impact of an average individual I can think of.
|
| We don't have to be once-in-a-decade level genius visionaries or
| hire a gigantic team with millions in funding to build something
| that can make the lives of millions of people tangibly better,
| while capturing some/most of that value in return to improve our
| own lives. People from all over the world are doing this every
| day and telling their stories and sharing their learnings on
| places like https://www.indiehackers.com/ and
| https://bootstrappers.com/.
|
| Maybe one day we'll reach a point of diminishing returns where
| all software that can possibly be built by an individual/small
| team that adds non-trivial value has already been built, but
| that's just more motivation for me to try harder today while it's
| still very much possible.
| sdenton4 wrote:
| > "where all software that can possibly be built by an
| individual/small team that adds non-trivial value has already
| been built"
|
| That's why we make new JavaScript frameworks.
| InitialLastName wrote:
| > build something that can make the lives of millions of people
| tangibly better,
|
| That's why the brightest minds of a generation are dedicated to
| making surveillance advertising more effective.
| mro_name wrote:
| humans are herd animals after all. So big orgs are reluctant to
| listen to indiviuals but their leaders. They wouldn't do a thing
| but listening otherwiese - there's just too many individuals.
| Held a 5min talk about that 2018
| https://txt.mro.name/35c3/35c3-dissolving-gafam_--_480p.mp4
| na85 wrote:
| Did we ever figure out why he wants the computer that comes in
| the smallest box?
| djrockstar1 wrote:
| This still keeps me up at night.
| jodrellblank wrote:
| Can you not just imagine?
|
| Luu: "I want the computer with the smallest box"
|
| Sales rep: "Boxes are nothing to do with computer performance"
|
| Luu: "I understand. Still, please humour me?"
|
| Rep: "But there are sneering people on HN who think you think
| you're better than them. Somehow this should be important to
| you"
|
| Luu: "Anyway, moving on, I want to buy a computer"
|
| Rep: "No. Not until you explain."
|
| Luu: "Fine, I want to ship it to my mom in Alaska and want to
| minimise shipping cost."
|
| Rep: "Ah! Gotcha! Apple will ship it for you, to anywhere"
|
| Luu: "I don't want to use your shipping, I need to customise it
| first"
|
| Rep: "Ah! Gotcha! iCloud sync will transfer her data when she
| signs in"
|
| Luu: "I can't use that, I want to install custom new things"
|
| Rep: "Smallness often comes at a cost premium. You might find
| that a bigger computer has a little extra shipping, but overall
| comes out cheaper"
|
| Luu: "I'm paying for the computer, but my mom is paying for the
| shipping. It's more important for me to minimise shipping cost
| than computer cost"
|
| Rep: "If you're going to pay part of a more expensive computer
| cost, why can't you pay part of a more expensive shipping
| cost?"
|
| Luu: "When my mom sees the shipping price on the parcel, she
| will send me that amount of money, she can't afford it, and I
| don't want to argue with her about it."
|
| Rep: "She can't afford shipping but you're not paying for it?
| You're not paying for food or rent?"
|
| Luu: "What I am and am not paying my mom for is irrelevant. She
| doesn't want to live off me, but will accept a gift, but also
| wants to pay her way when she can, and I want to respect her
| wishes. This is the agreement we came to."
|
| Rep: "You don't want to have a small discussion with your mom
| to save money? She won't change the agreement to save you
| money?"
|
| Luu: "I won't let her change the agreement to save me money, if
| it makes her feel like she didn't contribute and then she feels
| bad using the gift"
|
| Rep: "Luu, I..."
|
| Luu: "This could go on literally forever. The people on HN are
| internet people who thrive on cynicism. There is no resolution
| to this which will satisfy them, nor is that a goal I am trying
| to meet. This is not what I came here to discuss. Will you
| please help me find the computer with the smallest box in
| exchange for money, for reasons which I am perfectly happy to
| agree are irrelevant and irrational, but nevertheless am
| sticking with?"
| na85 wrote:
| >Can you not just imagine?
|
| Of course I can, but I want to hear the horse's reason from
| the horse's mouth.
| kragen wrote:
| Did you try asking?
| 1penny42cents wrote:
| OP touches upon a critical point of human reasoning: we have a
| bias towards simplicity.
|
| We favor the legible (as the article calls it), the tractable,
| the countable, the fungible. At certain levels of complexity,
| seeing reality as it is is just impossible. This complexity can
| be in terms of the subject itself, or the
| organizational/communication overhead required to tackle that
| subject.
|
| This bias towards simplicity is more often optimal than not. As
| he noted, the variance in performance becomes unbearably huge as
| you try to get more precise.
|
| The thing is that it's easy to pick out where simple models are
| wrong. The more complex the subject, the more edge cases there
| are, the fatter the tails are, etc. But it's harder to replace
| those models with new ones that increase precision while
| retaining sufficient efficiency. So just as simple models account
| for the cost of an employee without accounting for their value;
| he critiques those models for their precision without accounting
| for their efficiency. It's not as easy to predict/calculate value
| as it is to calculate cost.
|
| So while he's right in saying "these models are wrong", people
| won't be persuaded until they hear "these models are better". And
| "figure out the optimal solution in every individual context" is
| not a better model, not given the complexity of our work and the
| limited resources we have.
|
| Anyone taking the message here as "managers are idiots", are also
| oversimplifying things. They feel the moral high ground of being
| right, and it can be helpful to highlight where our models are
| wrong. But we also need to replace them with better ones, which
| is much harder than critiquing the best usable-but-imprecise ones
| we have.
| 5cott0 wrote:
| so do margins
| bobm_kite9 wrote:
| My takeaway is that danluu is saying that, at the small scale,
| people understand how individuals contribute to teams. But at the
| large scale (like the HR department) we don't.
|
| At the small scale, we're able to apply systems thinking - a team
| can be viewed as a system composed of a set of interacting parts.
|
| However at larger scales, systems thinking becomes unwieldy - the
| interactions increase quadratically. There, we fall back to the
| Law of Large Numbers [1].
|
| "Fungibility" and the related failures arise as a result of this.
|
| [1]: https://en.wikipedia.org/wiki/Law_of_large_numbers
| noduerme wrote:
| Oddly, though, most critical moments in history have been
| shaped by (highly error-prone, but non-fungible) individuals,
| acting on their own.
| quickthrower2 wrote:
| Good Job we don't all work for one company
| bobm_kite9 wrote:
| The law of large number works well for some things (say, shoe
| sizes) and fails to work for others (e.g. income
| distributions, which follow a power-law).
|
| So it's not odd at all that it would fail to adequately
| account for people. It's just sad we don't have anything
| better. Can't we find something better?
| ZephyrBlu wrote:
| Power laws apply to individual output as well:
| https://dariusforoux.com/prices-law/
| smilekzs wrote:
| Something along the lines of what was described in this article
| has recently been forced upon my team. You could imagine how that
| turned out. Hint: not very differently from the outcomes in the
| article...
| mr_tristan wrote:
| I've experienced a corollary to this: individuals don't
| instantaneously gel into teams. I've found places that try to
| solve hard problems by "finding good folks and putting them
| together on a 'squad'". Or, deciding to reorganize and just
| breaking up teams and mashing them up in weird ways.
|
| What I have seen work: swapping managers. Leaving the team intact
| but bringing a new manager in can actually change execution a
| lot. But this is just not how a lot of businesses like to think.
| jll29 wrote:
| Indeed, exactly as you say, people are _not_ interchangeable - we
| know that already since communism relied on that false premise,
| viewing individuals as just "means of production", and utterly
| failed.
|
| HR as a function has increasingly become an obstacle rather than
| a managerial support function in recent years. Instead of
| personal relations with trusted, long-term people staff,
| employees and managers get mailing lists attended to by
| outsourced cheap labor call Center agents. It is CPOs' and CEOs'
| fault that they let greed cut into employee well-being that much,
| and of course once one company does that, all other corporations
| adopt the same nonsense, since they all copy playbooks.
| zem wrote:
| the last paragraph made me realise, i indirectly owe my current,
| amazing job to that. i was on a team at work which was fine, i
| wasn't hyped about it or anything but my boss was good and i had
| found an interesting subarea of the product to work on. then i
| got taken off it and moved to another product that absolutely did
| not motivate me in any way. stuck it out for a couple of
| quarters, finally talked to my boss about being put back on the
| old product. he talked to his boss, who said no way, we need
| people working on the new product. that finally gave me the kick
| in the pants to apply to change teams to work on something i was
| really enthusiastic about, and i've been here ever since.
| [deleted]
| markus_zhang wrote:
| For large corporations I think it inevitably people with a C
| title regard troopers in the trench as mere numbers, just as a
| general does. He has to because his mindset doesn't allow
| otherwise. For such a large entity to survive, the leader has to
| have a "collective" mindset.
|
| My recommendation is to move to smaller companies/organizations
| so that individuals may be treated more independently (regardless
| of whether their job matters or not).
| cushychicken wrote:
| _the head of HR thought that the company 's ~5% attrition was
| "unhealthy" because it was too low and in another, HR thought
| that the company's attrition sitting at a bit under 10% was too
| low_
|
| Can someone explain to me why fewer people quitting is seen as an
| unhealthy metric?
|
| Retaining employees seems like something companies should want to
| try to prioritize above all else, especially in this market.
| csee wrote:
| Depends how good your hiring is. At the places I've worked, I'd
| want to see 0.1 (involuntary) attrition at least, given that
| mishires happened 1 in 10 to 1 in 5 times. A low attrition rate
| in the context of lots of mishires means we're not firing
| people quickly enough.
| tharkun__ wrote:
| While I agree that one shouldn't keep mishires around I
| wonder how you established that the rate of mishires is
| 10-20%. Seems like a bit of a chicken and egg problem. You
| don't know the actual rate if managers aren't firing the
| mishires. If you pressure managers into randomly firing
| 10-20% of their people you can't calculate the rate. In fact
| 50% of one team might be mishires while another is 100% made
| up of great engineers.
| csee wrote:
| I knew the rate because I was on the ground working with
| the underperformers. But as to how to translate this into
| HR policy in a large org, I have no idea.
| tharkun__ wrote:
| I would venture that you really can't if you want to be
| accurate and fair.
|
| You were on the ground, which to me implies that you had
| a local view of the rate. In your area the observed rate
| of mishires apparently was around 10-20%. If you were in
| another team/part of the org you might have thought 50%
| or 0%.
|
| My guess is that HR does exactly this sort of thing.
| Someone did a study once and averaged numbers that were
| obtained 'somehow' and that is then simply applied.
|
| Like stack ranking. Everything is a normal distribution,
| right?
|
| If you ask me: What large orgs are not good at is doing
| what actually makes sense. It's too much work and there
| is so much that could go wrong anyway. The way out are
| blanket policies implemented by drones, bean counters,
| the odd psychopath etc.
| csee wrote:
| I observed the local rate, correct. I didn't really make
| a claim that a large org would be exactly the same as my
| local rate, so I agree with you that it could differ. But
| honestly, I do believe it would be over 0.1 for most
| orgs, just based on my experience with people in college
| and other areas of life. Competence at a high level is
| really rare and most people just are really not good at
| complicated tasks, even many graduates from top schools.
| tharkun__ wrote:
| I definitely would agree that a lot of people in large
| orgs are unfortunately like that. I can corroborate that
| from having been in many of those. I can also attest to
| the fact that most managers don't deal with this. There
| is a lot of moving people around or simply ignoring the
| problem.
|
| Now like my earlier sibling mentions, just because
| someone isn't a top performer at their current job at the
| current time doesn't mean they can't be great in another
| area or can learn. I have (and had) a bunch of people on
| my teams that were/are not senior people but they have a
| smart brain on their shoulders, are inquisitive and
| learn. Sure they don't know our stack fully, they don't
| have the exact same opinion on how to write code etc. but
| they are able to learn and adjust and maybe teach us
| where our customs aren't the best as well. And we teach
| them too.
|
| I'm speaking of practices like at large banks where
| people have been hiding doing nothing but being on
| Facebook all day for 10 years and all that has happened
| is that every project manager tries to avoid getting
| these people assigned to their projects.
| kmonsen wrote:
| Maybe it was the environment, that a lot of these people
| could be better if supported the right way? Or to say it
| simply (and please understand I know nothing about you so
| it is not meant as a criticism of how you personally
| work), maybe it was because they worked with you?
|
| I would also say that throwing x% and hiring again does
| not work well. The pool you are hiring from is people
| that are not happy somewhere else. You are not getting a
| 90% chance of finding a "good" person.
| SkyPuncher wrote:
| It implies that the company isn't pushing their employees hard
| enough.
|
| In otherwords, if managers are doing their job "correctly" they
| should either (1) be pushing their staff so hard that 1 in 10
| of them quit every year (2) weening out the the poorest
| performer.
| wombatpm wrote:
| Weeding as in remove undesirables
|
| Weening is the process if transitioning from milk to solid
| food as in babies and puppies
| tjalfi wrote:
| Peopleware calls this the Spanish Theory of Management[0].
|
| _Historians long ago formed an abstraction about different
| theories of value: The Spanish Theory, for one, held that
| only a fixed amount of value existed on earth, and therefore
| the path to the accumulation of wealth was to learn to
| extract it more efficiently from the soil or from people's
| backs. Then there was the English Theory that held that value
| could be created through ingenuity and technology. So the
| English had an Industrial Revolution, while the Spanish spun
| their wheels trying to exploit the land and the Indians in
| the New World. They moved huge quantities of gold across the
| ocean, and all they got for their effort was enormous
| inflation (too much gold money chasing too few usable goods).
|
| The Spanish Theory of Value is alive and well among managers
| everywhere. You see that whenever they talk about
| productivity. Productivity ought to mean achieving more in an
| hour of work, but all too often it has come to mean
| extracting more for an hour of pay. There is a large
| difference. The Spanish Theory managers dream of attaining
| new productivity levels through the simple mechanism of
| unpaid overtime. They divide whatever work is done in a week
| by forty hours, not by the eighty or ninety hours that the
| worker actually put in._
|
| [0] https://blog.bryanbibat.net/2009/08/31/spanish-theory-of-
| val...
| detaro wrote:
| some arguments I've seen (not endorsing any of those) are
|
| a) it makes you inflexible (i.e. you cant readjust by
| constantly hiring people that fit whatever your new goals are
| better)
|
| b) it means you are to easy on people and keep low performers
| around
|
| c) b) means it also makes trajectory upwards harder for good
| employees, so the good employees are more likely to be the few
| who quit
| dustintrex wrote:
| It's Neutron Jack's "rank and yank" philosophy, which says you
| should fire the bottom 10% performers of your org every year:
| https://en.wikipedia.org/wiki/Vitality_curve
|
| Of course firing low performers is quite different from high
| performers leaving, but HR doesn't see or care about these
| distinctions.
| pixelrevision wrote:
| My guess would be either stack ranking or concern about the
| Dead Sea effect.
| paxys wrote:
| It's the same kind of bullshit as teams being penalized for
| meeting 100% of their goals because it means that their goals
| weren't aggressive enough. I can't say whether the strategy is
| effective or not, but MBA types seem to love it.
| andrei_says_ wrote:
| MBAs I think see it as an indicator that they are not using g
| the resource at capacity.
| rStar wrote:
| mbas see whatever they see for whatever reasons they do.
| it's usually posturing and signaling to other mba types,
| often with delusions of grandeur and napoleon complex, not
| height based.
| PeterisP wrote:
| The argument essentially is that it hints to there being an
| exploitable slack in the system.
|
| If you treat bargaining with employees as a zero-sum game
| (which it really isn't, but some companies do treat it that
| way) then the other party being very satisfied with the bargain
| indicates that they would be also willing to get a worse offer.
| So if all the employees are extremely satisfied with the
| compensation/effort ratio, that indicates that you could either
| lower the compensation some or extract more effort until
| they're satisfied "just barely enough".
| djsavvy wrote:
| > But many effective interventions cannot have their impact
| demonstrated ex ante in any simple way because, among other
| reasons, the composition of the team implementing the
| intervention is important, resulting in a randomized trial or
| other experiment not being applicable to team implementing the
| intervention other than the teams from the trial in the context
| they were operating in during the trial.
|
| This sentence really confused me, and I spent a couple of minutes
| trying to parse it. For anyone else reading, I think "not being
| applicable to team" is supposed to say "not being applicable to
| teams".
| rStar wrote:
| individuals matter, or, why aren't we all treated as the special
| special snowflakes we so obviously believe ourselves to be.
___________________________________________________________________
(page generated 2021-11-16 23:02 UTC)