[HN Gopher] If we had the best product engineering organization,...
___________________________________________________________________
If we had the best product engineering organization, what would it
look like?
Author : kiyanwang
Score : 199 points
Date : 2025-01-12 19:27 UTC (1 days ago)
(HTM) web link (www.jamesshore.com)
(TXT) w3m dump (www.jamesshore.com)
| lubujackson wrote:
| What an amazing article on "de-FAANGing" the perverse
| org/incentive structure of most startup/tech places. Would love
| to see more of this type of leadership in the real world.
| adastra22 wrote:
| The recent book The NVIDIA Way is about that org's culture that
| prevent FAANG incentives from creeping in to destroy
| productivity.
| Sevii wrote:
| I like how he says he doesn't need FAANG level people. Then his
| next paragraph describes working at FAANG.
|
| "We're an inverted organization. That means that tactical
| decisions are made by the people who are doing the work, not
| managers. (In theory, anyway, we're not perfect.) So we're
| looking for people who have peer leadership skills, who are
| great at teamwork, who will take ownership and make decisions
| on their own."
| holografix wrote:
| Exactly right. People who have "leadership" skills are the
| ones that pay attention to their own leadership and are
| manage up more than anything else.
|
| They usually repackage people's work around them into their
| own, take ownership and defend loudly their territory
| (project ownership) and methodically build relationships with
| leadership. Having "leadership skills" and being good a team
| work are often orthogonal to each other.
| khazhoux wrote:
| > People who have "leadership" skills are the ones that pay
| attention to their own leadership and are manage up more
| than anything else.
|
| No, it's actually people who can put together a technical
| plan and drive its execution with other engineers, or who
| can clarify complex problems esp. when there are
| conflicting opinions, or who can see problems before they
| become disasters and organize the right group of people to
| take care of it...
|
| There are many examples of leadership, which have nothing
| to do with the sour view of managing-up or taking credit
| for others' work.
| noirbot wrote:
| I mean, that's the sour way to put it. As someone kinda
| stuck in that sort of position now, I own a project and
| have been able to do very little of the work _because_ I 'm
| spending 90% of my time making sure leadership actually
| makes decisions so I can get the decisions my team needs in
| order to proceed. I'm spending hours in meetings with other
| teams to get them to prioritize our dependencies and data
| access needs.
|
| If you're not lucky enough to have management that's
| exactly technically aligned to your project _someone_ has
| to be managing up and paying attention to leadership or
| else expectations will be totally off from reality.
| supriyo-biswas wrote:
| This is not a sour way to put it; extreme levels of
| information hoarding, cookie licking[1] and building and
| defending fiefdoms were the norm from what I saw at my
| time at a FAANG.
|
| [1] https://devblogs.microsoft.com/oldnewthing/20091201-0
| 0/?p=15...
| numbsafari wrote:
| > FAANG level people
|
| "FAANG" isn't a "level", it's just a cluster.
| gpi wrote:
| That was a breath of fresh air. Thank you James.
| zeroonetwothree wrote:
| There's a weird disconnect because on the one hand I agree you
| can't measure productivity and on the other hand we all know that
| some engineers are vastly more productive than others. So what
| gives?
| throw5959 wrote:
| You can measure productivity by measuring the success, but
| that's kinda useless for day to day software engineering
| management.
| Trasmatta wrote:
| How do you define success? If a product bombs, is that
| because of the engineering or the product design?
| throw5959 wrote:
| I don't think it's possible to answer generally. Track what
| matters for your business.
| skeeter2020 wrote:
| if it's successful, it's because of sales. If it fails,
| engineering didn't build the right thing / was too slow -
| it really doesn't matter.
| ChrisMarshallNY wrote:
| I tend to go by _results_ , and for me, "results" means
| shipped* code that is used and accepted by end users**, can
| be maintained and extended***, and doesn't generate trouble
| tickets.
|
| * MVP doesn't count.
|
| ** Can include users inside the organization.
|
| *** It's OK if it requires senior-level ongoing support. I
| think expecting it to be maintained by monkeys is a bad idea.
| pinkmuffinere wrote:
| To me, "MVP doesn't count" feels like a crazy take -- in
| many roles, the _only_ ask is to produce a series of
| different MVP's. I guess maybe the definition of "MVP" is a
| bit squishy, and these people-who-ship-MVPs themselves make
| MVP-MVP's, which shouldn't count as shipped?
| ChrisMarshallNY wrote:
| I spent most of my career, shipping finished product,
| which, in many cases, probably could have benefitted from
| an MVP-like "tuning phase," but we called that "beta." I
| think MVP generates more useful feedback, but I _really_
| don 't like thinking of an MVP as "shipping software."
|
| I also worked for hardware companies, where shipping
| stuff had some pretty serious stakes, and learned how to
| make sure we got it as good as possible, before getting
| it out the door.
|
| I like the idea of evolutionary design, and "tuning," but
| I think it's a bad idea (for me) to deliberately ship bad
| software as an end-product.
|
| _(Also, MVP, by definition, generates lots of trouble
| tickets. I am allergic to trouble tickets. It 's totally
| a personal thing, but I live by it)._
| skeeter2020 wrote:
| saying "MVP doesn't count" implies that you throw it away
| and then right "the perfect system" at some point. If
| you've ever had an MVP land you know that's not how it
| happens.
| ChrisMarshallNY wrote:
| I _write_ "as close to perfect" as I can get. I know that
| "The Perfect is the enemy of the good" is a popular meme,
| but I have found that "The perfect is something to strive
| for" has been useful, for me.
|
| In fact, my way has been working for me, for decades.
|
| I'm quite aware that many folks do it differently, and
| that's one reason that I try to "keep it in the I," and
| write about how _I_ do it, and talk about the bar that
| _I_ set, for myself.
|
| Most of the software I write, is free software that
| Serves a pretty small demographic. It can have a fairly
| outsize influence on the lives of the people that use my
| software, and I really care about the end-users of my
| work, so I tend to set a pretty high personal bar.
|
| I'm quite aware that I don't have many of the stressors
| that beset commercial software houses, so I sincerely
| don't feel "snooty." In fact, I feel profoundly grateful
| to be in a position, where I can follow my muse.
|
| I really would like it if folks wrote better stuff, but I
| am also aware of the culture, and how that's next to
| impossible, these days.
| jprete wrote:
| Those are two different concepts hiding in similar words. You
| can't [numerically or precisely] measure productivity, but some
| engineers are vastly more productive [such that you can easily
| tell the difference without a formal measurement].
| fshafique wrote:
| Gut feeling uses all your internal predispositions and
| biases.
| skeeter2020 wrote:
| you don't need to rely on gut feeling and risk bias. You
| can stop looking for the "productivity metric" and instead
| bet on <some> measure, then track the change over time.
| It's the only thing that's ever worked for me.
| noirbot wrote:
| Sure, but which measure you pick is itself a gut feeling
| and biased. It's the easy way to miss people doing
| whatever sort of work that you aren't measuring that may
| be what's letting everyone else excel at what you _are_
| measuring.
| Trasmatta wrote:
| We all "know" that, but there are also some engineers that only
| give a very strong illusion of being more productive.
|
| Maybe engineer #1 is constantly pushing up code. In the time it
| takes them to merge 15 PRs, engineer #2 opens only 1 - but
| maybe they thought really deeply about the problem, and their
| approach actually saves the team hundreds or thousands of hours
| of future development work vs how engineer #1 would have solved
| the problem.
|
| Part of what makes this so hard to measure is the long tail
| effects of development decisions. (Incidentally, that's also a
| source of burnout for me - the constant mental overhead of
| worrying about the long term implications of what I'm doing,
| and particularly how they effect other people. It's very
| challenging.)
| ebiester wrote:
| The problem is that the vast majority of code will not have
| long term implications so long as it reaches a minimum of
| design, performance, and does its job without bugs.
| Consistency of patterns is more important than the optimal
| pattern for most decisions.
|
| There are some core areas of the application that are much
| more important, but they are often the earliest data
| structures and built before the problem is known. You will
| not know how your code will change, so make it as consistent
| as possible with the rest of the system until you know more.
| Sevii wrote:
| You can measure productivity with correlated metrics. The issue
| has always been that the metrics which are easy to track don't
| line up incentives with the actual business goals. A group of
| 10 people who write 200k loc per year are probably more
| productive than a group of 10 people who write 10k loc per
| year. If you took those metrics and then did an investigation
| of the people in your company writing 10k loc you might find
| that they are slackers or that they write assembly.
|
| The issue is when metrics are used to stack rank teams with no
| thinking put into it. You can't treat correlated metrics like
| direct metrics. A logger might be evaluated based on how many
| trees he cut down in a day. There is no comparable way to pay
| software engineers piecemeal.
|
| Metrics are good, but people want to use them without thinking
| or taking context into consideration.
| bigs wrote:
| Or you may find they write higher quality code - less bugs,
| more performant code, or so on.
| llm_trw wrote:
| The engineers are only productive because they have the support
| structure in place.
|
| The most productive fpga engineer I ever hired was so hopeless
| with git that I had to hire a second software engineer to
| babysit him.
|
| After I left both of them got fired and the product they were
| ahead of schedule on when I left had slipped 2 years behind
| before it finally got cancelled three years later.
| daz0007 wrote:
| a weird disconnect... of any true innovation or even reality...
| such vague objectional blandness...
|
| "They'd beg to work for us" - what the f8ck.... if they were
| the best they would not beg anyone how degrading...They would
| be there for a mission or wanting to improve something about
| themseves or other parts of the world.
|
| There's nothing here apart from Agile coach wanting to get some
| more work.
|
| 1984 was released in 1949, if anyone thinks these words /
| values really mean what is writen wow. People, Internal
| Quality, Lovability, Visibility, Agility, Profitability...
| Salgat wrote:
| It's an extremely complex mixture of many factors (which can
| vary wildly between two different productive engineers), and
| trying to make that into some magical formula ends up creating
| a system that can be gamed to superficially appear productive
| to managers.
| skeeter2020 wrote:
| I have an incredibly productive staff developer. Not only does
| he work _a lot_ , he also produces, and it's very high quality.
| He also does a relatively poor job of upskilling his teammates,
| and is a little rough when mentoring. This is not intentional
| (i.e. he's not a jerk).
|
| Overall I don't know if, in the context of a staff developer,
| he's vastly more productive than say, another dev I have who
| produces less but levels-up his team better than almost anybody
| I've ever seen.
| ggregoryarms wrote:
| Maybe that other dev has a unique ability you should reward.
| Sound awesome. Focus on that.
| mrbluecoat wrote:
| +1 for Extreme Programming. I've been a fan from the beginning
| when Agile was all the rage and my recommendations for XP were
| met with blank stares.
| Trasmatta wrote:
| I'm glad that it works for some people, but I did not like the
| forced pair programming in XP at all. And I found adherents to
| XP were even more cult like than Agile teams.
| Salgat wrote:
| Does XP and pair programming actually require two people to
| be simultaneously working together at the same time? My
| understanding is that this includes one person who codes
| while another person looks at the results and reviews them
| afterward. The two are still working closely together and
| exchanging feedback, just at different points in the process
| in an iterative loop.
| NomDePlum wrote:
| My understanding is that original meaning was that pair
| programming requires the pair work together at the same
| desk and machine.
|
| With the ability to share screens/IDEs remotely the need to
| be at the same desk may have shifted, but working together
| is intrinsic to pair programming I believe.
|
| The original text went into some detail about making the
| desk work for 2 people, and having screwdrivers available
| to do so, which for some reason always amused me.
| p_l wrote:
| No, the point is that both "driver" and "navigator" (as
| some pair programming referred to the roles) are looking at
| the coffee simultaneously, just one has the keyboard at the
| time.
|
| This is extended to "mob" programming where you have whole
| team of "navigators" and one person at keyboard.
| skeeter2020 wrote:
| resist the oxymoron of agile zealot - the first rule is do
| what works for YOU
| Sevii wrote:
| I appreciate that they have a programming philosophy that they
| want people at the company to adopt. A common problem I see at
| companies that don't have onboarding is that people join the team
| with assumptions from previous jobs but you never level set them
| with the company. So 12 months down the line the new guy wants to
| change the process and you have to repeat the same discussions
| about what agile means for the nth time.
|
| Amazon does a good job of training new hire on the 'Amazon way'.
| Amazon does 6 pagers, they do design docs. Amazon does SOA.
| Amazon does not use relational databases. Everything has an API.
| Because of the 'Amazon way' and the training they do new team
| members understand at least some of the context and expectations.
|
| Is it the best way? Probably not but no one knows what the best
| way is anyway. At least they have a way. Saves a lot of effort
| compared to every new hire relitigating the process and
| architecture.
| rrr_oh_man wrote:
| _> Amazon does not use relational databases_
|
| Huh?
| deskglass wrote:
| Friends say they typically use Dynamo and that using a
| relational database requires approval from a vp (because of
| scaling concerns).
| hyperliner wrote:
| Related: Amazon kicked out Oracle from the company.
|
| Somewhere along the same timeline, the operational
| recommendation for teams was to not use relational
| databases.
|
| https://www.theregister.com/2019/10/16/amazon_ditches_oracl
| e...
| vamega wrote:
| Relational databases are not the preferred storage mechanism
| at Amazon. If a team wants to use an OLTP relational database
| it's possible that it will be a decision they will need to
| defend at any kind of design review.
|
| Of course there are relational databases running OLTP
| workloads, but it's far away from the norm. There was a
| program a while ago to shift many RDBMS systems onto
| something else.
| emmelaich wrote:
| So they do joins in code rather than SQL? Wouldn't that
| risk _hiding_ scaling problems?
| grogenaut wrote:
| It can but it's usually more obvious what's happening
| with code and how to fix it. Amazon wants you to think
| about the scaling issues while building as they don't
| want to lose the area under the customer curve on the far
| right.
|
| The theory is that with rdbms you have a magical box that
| scales vertically until it doesn't. And when it doesn't
| all you can do is scale back the customers until you fix
| it with sharding or a re-architecture. Basically you tend
| to hang yourself with indexes and transactions. Also
| generally when an RDBMS fails it fails down to like 30%
| throughput.
| mickael-kerjean wrote:
| I recently finished a contract at a company who has gone
| full on dynamo with the idea that if we have slow queries
| and dynamo is good for Amazon, then it's good for us too.
| I've ran some explain on the queries causing issues and
| of course those queries didn't leverage indexes like they
| thought ....
| redditor98654 wrote:
| How did you run explain queries on DynamoDB? Or may be
| you mean something different and I misunderstood you?
| bdavisx wrote:
| That doesn't make sense, you have to specify the index
| when you're using Dynamo.
| scarface_74 wrote:
| You can do scan operations and if they use PartiQL it
| hides whether you are using indexes.
|
| I usually have an explicit DENY for dynamodb:Scan for the
| IAM role used to access the DDB table
| scarface_74 wrote:
| Look up design patterns in DynamoDB. If you know your
| access patterns and you often do with well defined
| microservices. You don't need to do joins.
| yazaddaruvala wrote:
| Amazon Retail has multiple systems to allow you to
| basically use SQL across databases (eg Datapath).
|
| I'm not sure about AWS.
| saghm wrote:
| > Amazon does a good job of training new hire on the 'Amazon
| way'. Amazon does 6 pagers, they do design docs. Amazon does
| SOA. Amazon does not use relational databases. Everything has
| an API. Because of the 'Amazon way' and the training they do
| new team members understand at least some of the context and
| expectations.
|
| As a counterpoint, a huge part of Amazon's culture (or at
| least, AWS's) in my experience was the emphasis on operations
| and the fact that they didn't have any separation between
| SREs/on-call engineers from the people who implement their
| services, and at least for me as someone who had never been on-
| call before in any meaningful capacity (due to my previous job
| working on a libraries rather than services), the training for
| it was basically non-existent on the two teams I spent time on.
| The "training" I did receive essentially consisted of being put
| on the rotation once to shadow, where I was able to sort of see
| what the actual on-call person did but didn't really have any
| explanation for how to know how to do them other than being
| told to read the runbooks, which were not really written in a
| way that was easy to understand for me as someone who was so
| new to learning all of the internal AWS tooling and ops in
| general. The next time I came up on the rotation, I was
| expected to be able to manage on my own, which essentially
| meant that literally no matter what occurred, I ended up having
| to escalate because I wasn't knowledgeable enough to fix
| literally anything within a timeframe that would have been
| reasonable.
| xwolfi wrote:
| Which is the only way to learn tbh, you can receive as much
| positive reinforcement imaginable, nothing prepares you for a
| large scale incident like living through one, building the
| connections you need to solve it, getting the shame of your
| life, and losing sleep over your failure.
| pyrale wrote:
| Nothing teaches you to swim like being thrown in the middle
| of the atlantic.
| saghm wrote:
| I'm not really sure what you mean by "positive
| reinforcement", but I don't think it's possible to disagree
| more with this sentiment. "building the connections you
| need to solve it, getting the shame of your life, and
| losing sleep over your failure" isn't a strategy for
| teaching for something; it's a coping mechanism for someone
| trying to brute force their way through something that they
| weren't adequately trained for.
|
| Most people seem to think it's fine for companies to
| offload the entirety of the burden of learning to
| individual employees, and maybe I'm an outlier in this
| regard, but to me, this seems more like a cop out to avoid
| trying to actually solve the problem at the cost of the
| employee's emotional health. I'm not surprised that
| companies default to this, but it's also not surprising
| that burnout is so common in our industry when this is
| considered the "best" or "only" way to do things.
| wesselbindt wrote:
| > they didn't have any separation between SREs/on-call
| engineers from the people who implement their services
|
| I.e., treat DevOps as a way of working, rather than a role
| meaning something akin to "Ops person who knows terraform, or
| k8s, or Ansible etc".
| Sevii wrote:
| My team didn't add new members to the oncall rotation for
| about 6 months to ameliorate this issue. But starting oncall
| at first is rough and even with months of context on our
| systems people usually take a few rotations before they
| really figure it out. We expected new members to have to
| escalate.
| saghm wrote:
| I don't think this really ameliorates the issue much; it
| just pushes the problem down the line. IMO this is a big
| part of why people transfer internally to different teams
| so much at Amazon, and that masks the problem even further.
| If by six months of on-call rotation you expect someone to
| be self-sufficient, but they only start after six months on
| the team, they'll have been on the team a year by that
| point, and people either transferring or leaving the
| company after a year on average isn't going to be
| immediately obvious as a problem, but if people start a few
| weeks in, you're going to have 5-6 months of noticing that
| there are issues when that person is on-call, and if that
| happens more than a few times, the trend will be
| noticeable.
| infomaniac wrote:
| > Amazon does not use relational databases
|
| This is false, at least in my very thin exposure to the
| company: I interviewed for a team last year which was
| maintaining EC2 SSH keys using MySQL.
| mnahkies wrote:
| I watched an interesting talk from the RDS team about how
| they dogfood RDS the other day https://www.pgevents.ca/events
| /pgconfdev2024/schedule/sessio...
| chupasaurus wrote:
| If it was using MyISAM relations are in question.
| 9rx wrote:
| SQL, and therefore MySQL by extension, isn't relational.
| snapcaster wrote:
| He typed smugly, confident that everyone reading this will
| appreciate his pedantry that totally contributed to the
| conversation
| 9rx wrote:
| A lot to unpack in this comment.
|
| 1. Wherein do you find the smugness? It does not speak to
| any person, let alone the first person.
|
| 2. What would give the impression that comments on the
| internet are written for others? Carly Simon once
| recorded a popular song about this type of falsehood.
|
| 3. It remains that SQL isn't relational. That is why it
| "won", after all. Relations are too complex for the
| layman to understand. Tables are much more familiar to
| the people in charge and arguably a better model for most
| business problems.
| mft_ wrote:
| A great post, well worth reading. The principles in the section
| on 'people' are applicable to any organisation in any industry.
|
| I especially liked the simple 'career ladder' example, for a)
| focussing on mostly on behaviour rather than knowledge, and b)
| for being simple to use and track progress with. (I've never seen
| anything like it in any of the large organisations I've worked in
| to date.)
| theideaofcoffee wrote:
| This was a really great read, lots of insight and things to think
| about.
|
| But it's also depressing to see how good things could be and how
| poorly (IME) most orgs are run now. I know I've seen the exact
| 180-degree opposite of almost everything mentioned here: no team
| leadership or empowered people, no clear path to the next level
| for those interested, lack of communication, no emphasis on
| internal quality, overall pathological product choices (or lack
| thereof) and on and on. I'd kill to be part of an org that puts
| this much thought into everything.
| joeldo wrote:
| > There's more details here than I can explain today, but you can
| use the QR code to find a detailed article, including the
| documentation we use for the skills.
|
| Why not just provide a clickable link given this is an article on
| the web?
| jh00ker wrote:
| > This is a transcript of my keynote presentation for the
| Regional Scrum Gathering Tokyo conference on January 8th, 2025.
|
| Because the images are slides from a presentation that the
| audience could scan.
|
| >Thank you for listening.
|
| The text of the article appears to be the "talk-over."
| philbo wrote:
| The clickable link is in the right margin just underneath the
| (first) QR code image:
|
| https://www.jamesshore.com/v2/blog/2024/update-on-software-e...
| nine_zeros wrote:
| This is a very nice post - not because the actual suggestions are
| good, but it demonstrates what a really technically sound VP
| looks like.
|
| In most large tech companies, VP level people are so detached,
| delusional, and unskilled in engineering, that they end up
| undervaluing what engineers really do. They are unable to explain
| it beyond stack ranking them.
|
| As an example, this post talks about how simplicity and
| maintenance brings value. But my VP literally fired people who
| did not produce new complex impact.
|
| Just goes to show why so many people hate the big tech industry
| as employees. It is being run by charlatans who abscond from any
| real leadership.
| gwern wrote:
| OP is an example of how AI-generated images are usually clutter.
| Not only do the images not add anything meaningful to the text,
| and arbitrary parts of the images could be deleted or randomized
| without affecting the reader's understanding, most of them could
| be randomly shuffled without anyone noticing. (Which makes them
| worse then clipart/stockart: if an article swapped the 'hacker
| hoodie' stockart with the 'neural net brain circuit' stockart,
| some readers would at least briefly be confused.)
| blululu wrote:
| Came here to say exactly this. The "author" didn't even bother
| to use a decent quality image generator. The first image I saw
| maxed out my AI slop filter and I stopped reading. Made me
| wonder how much of the article was written by ChatGPT.
| drcwpl wrote:
| Agree wholeheartedly, it was unfortunate that the author did
| not use a good image generator, or even correctly prompt
| Dall-E to get better images, his take on using AI then became
| rather flimsy. I gave up at this point!
| LudwigNagasena wrote:
| Saying that you can't measure productivity is a pseudo-truism and
| a cop out of doing your job.
|
| How do you measure productivity = how do you decide whom to
| promote; how do you decide whom to fire; how do you decide how to
| distribute bonuses; etc.
|
| If you can't measure productivity, you can't do your job as an
| engineering manager. It's not a question that should have been
| asked 3 months into a job. It's a question that should have been
| asked during the hiring interview.
| skeeter2020 wrote:
| I think I agree with you - definitely about the cop-out part.
| It's kind of the wrong question; it's not "how do you measure
| productivity?" but you have some hypothesis, "what do you
| optimize?" If you're right, it might help you win (maybe you
| win or lose regardless) and you get credit. If you keep
| experimenting, you might get better or worse, adjust and
| repeat.
|
| I'm sick of these (implicitly) absolute measurement questions.
| I pretty much refuse to look at anything other than the delta.
| n4r9 wrote:
| So... how do you measure productivity? The engineering managers
| you refer to probably _attempt_ to measure productivity, but
| may well fail to correctly identify high and low performers.
| LudwigNagasena wrote:
| There are quantitative measures like story points velocity,
| time to merge, code churn, etc. Those can be simply measured
| but also simply gamed, so they should be used with caution.
| There are qualitative measures like code maintainability,
| satisfaction of stakeholders, communication skills, system
| design skills, etc. Those have to be assessed using peer
| feedback, stakeholder feedback, 1-on-1's, activity during
| calls and meetings and so on. Those are harder to measure,
| but also harder to game.
| n4r9 wrote:
| In my experience, not only are quantitative metrics
| gameable, but they depend greatly on accurate estimates
| (which just shuts the problem along) and tend to bias
| towards rushed implementations. You also have to be very
| careful to consider what duties the person has beyond pure
| coding, which can become time-consuming as they grow in
| seniority, such as mentoring juniors, engaging with product
| teams, or supporting product enquiries.
|
| The qualitative measures you mention describe "quality"
| rather than "productivity" (rate of good output). Both are
| aspects of performance, but are definitely distinct.
|
| I suspect that the best you can do for productivity is kind
| of a halfway house, where - as part of their feedback - a
| more senior developer indicates whether the _rate_ of
| implementation met /exceeded/fell below expectations.
| 9rx wrote:
| _> If you can't measure productivity, you can't do your job as
| an engineering manager._
|
| Why not? You could _feel_ productivity instead, which is also
| arguably the better approach as it more emotionally appealing
| to those paying the bills than measurement is. That is how
| people do it in the real world. Nobody is measuring
| productivity in this business, even if they want to pretend to
| themselves that they are.
| raldi wrote:
| What's the clickbait headline refer to? I can't find any mention
| of the company in a skim of the article.
| dang wrote:
| I've replaced the clickbait title with a more representative
| sentence from the article.
| paulcole wrote:
| > Everybody wants the best people in the business.
|
| A fundamental mistaken belief.
|
| Who wants to pay for the very best people when the 97,000th best
| person will do? Also how can you decide who the best people are
| when you can't even measure their productivity?
| gijoeyguerra wrote:
| ...starts off by saying you can't measure productivity. Then
| proceeds to explain how to measure productivity. Very sneaky.
| weinzierl wrote:
| Interesting, but not surprising, that _Agility_ only made place
| 5, way behind _Quality_. It will soon be a quarter of a century
| since the Agile Manifesto has been published. It would be sad if
| we hadn 't progressed since then.
| heeton wrote:
| The article uses "Internal Quality" which has a specific
| definition for them. And their definition of agility is not
| derived from the manifesto or Agile.
|
| Indeed, they list Quality immediately followed by customer
| happiness ("loveability") which is aligned with XP, the
| practice supported in the article.
|
| The agile manifesto isn't the only way to deliver good results
| in software.
| sisve wrote:
| I did not understand it as an ordered list? Just a set of 6
| items. Did i miss anything? What makes you conclude that this
| is a priortized list? Profitability is number 6. Who cares
| about internal quality if you are not making money in the long
| run
| agos wrote:
| if you'll allow some negativity, I wouldn't expect a talk at a
| "Scrum Gathering" to care much about the Agile Manifesto
| switch007 wrote:
| > We're an inverted organization. That means that tactical
| decisions are made by the people who are doing the work, not
| managers
|
| I've worked at various places where this was supposedly the
| system.
|
| Guess who had budgets, hiring powers, went to leadership
| offsites? Yeah not the ICs. It usually just means the C level
| will smile and nod while "listening" to your feedback instead of
| ignoring you completely
|
| Has anyone worked at a true inverted company where centuries of
| classical power structures are thrown out the window?
|
| I feel it can never be properly implemented unless in eg a
| cooperative
| Rygian wrote:
| The "Valve Handbook for New Employees" was an interesting read.
| I still don't know how much is fact and how much is fiction,
| but I liked some of the ideas there.
| pjm331 wrote:
| To be fair - it says "tactical" decisions - not all decisions.
| InitialLastName wrote:
| > Guess who had budgets, hiring powers, went to leadership
| offsites?
|
| To be clear, those are strategic decisions "what are our goals
| and how do we allocate resources to achieve them". Tactical
| decisions are "what specific actions do we take to use
| available resources to achieve goals".
| magic_smoke_ee wrote:
| First, it would be worker-owned co-op with very little turnover
| and intense competition for the few roles that get filled.
| abc-1 wrote:
| I always feel like these manager types have drunk deeply from the
| koolaid for some reason. It's a lot of words and processes that
| they usually cargo culted from somewhere else. A lot of it seems
| to boil down to "don't be an idiot" and "actually care about your
| work". They always have this air of superiority because they're
| high up on the org chart. Like CEOs who think they're the chosen
| ones, when plenty of people could do it just fine. I laugh hard
| when people like Zuck say software devs will be replaced by AI,
| not realizing an AI CEO probably wouldn't have burnt 30 billion
| on a terrible metaverse flop.
| wodenokoto wrote:
| Would it have bought instagram and whatsapp? Would it have
| identified major social media trends in competitors that
| couldn't be bought and outcompeted them at their own game?
| Would it have suggested developing your own ad platform or just
| should banner space per cpm?
|
| There is a lot to not like about Meta and Zuckerberg, but
| saying he's a bad business man is a little silly. Metaverse was
| a wrong and expensive move, but it was a wrong move they could
| afford.
| miki123211 wrote:
| IMO metaverse was a _bet._
|
| It's perfectly fine to take a bet that you're not 100%
| convinced will pay off (professional poker players and
| traders understand this on a very deep level), as long as the
| potential upside is massively larger than the downside.
|
| Zuck understood that Meta could take the hit if the metaverse
| bet didn't pay off, but that they'd be massively better off
| if it did, and they had their own platform. Apple's blatantly
| anticompetitive behavior around ATT was a prime example of
| what happens when your business is reliant on "platform
| overlords."
|
| I'm not fully convinced that the metaverse era is over,
| though. If they can get Orion costs down and put something of
| that quality into serial production, I think they still have
| a chance there.
| Zanfa wrote:
| > IMO metaverse was a bet.
|
| It was FOMO. They had no vision, they had no plan, it was
| clear that it was only a thing because it was a buzzword at
| the time. Just like every other company stuffing crypto-
| adjacent things everywhere. It might have been a bet, but
| it was obvious that it was a really terrible one.
| Clubber wrote:
| Reminds me of Ballmer buying Nokia or Cook buying Beats
| (or whatever the company was called.) Cook's bet might
| have worked out a little better than Nokia.
| zqy123007 wrote:
| Not really. FB was choked by Apple and trolled by Google
| for so long, Zuck understood his position without a
| hardware platform in the furture. XR seems to be a
| reasonable bet which he already have an edge. If he won,
| he won big.
| rohit89 wrote:
| I do not know where this notion that Meta has given up on
| the metaverse comes from. Mark continues to talk about
| AR/VR at every opportunity and Reality Labs continues to
| invest big on it. The metaverse is a bet but its a 10
| year bet that has not been played out yet.
| wavemode wrote:
| No. "Bet" implies some sort of clear vision or value
| proposition. Metaverse was a dream.
|
| It's okay to dream. It's not okay to burn billions of
| dollars on dreams with no proof of concept or business
| plan. Set aside the question of whether or not it's a bad
| idea - that's just plain bad execution.
| rohit89 wrote:
| The Orion is the proof of concept. The metaverse that
| Mark is thinking of is as ambitious as Musk's Mars plans.
| And it is something that requires large amounts of
| capital and time.
| Xcelerate wrote:
| Exactly. I've never understood this criticism. A good CEO (in
| terms of the business) is able to make significant,
| groundbreaking decisions but is also able to reverse course
| quickly if those decisions aren't working out (anyone
| remember the Facebook phone)?
|
| Unless the CEO is psychic, they're necessarily going to make
| a lot of bad or wrong decisions. The key is being able to
| recover quickly and move on to the next thing. A bad CEO
| makes no big decisions for fear of being wrong.
|
| When FB bought Instagram for $1B, there were a lot of talk
| show hosts riffing on Zuckerberg for making one of the
| stupidest business decisions of all time. A lot of executives
| who got to their position by corporate ladder climbing have
| personalities that would be terrified of that sort of
| widespread criticism. They would never make the kinds of
| decisions that might possibly put them in the unenviable
| position of being made fun of on national television.
| mempko wrote:
| The assumption that hierarchical organizations are
| inevitable blinds us to more effective ways of organizing.
| When we look at companies today, their feudal-like
| structure means CEO decisions naturally have outsized
| impact - but this is a product of the system, not inherent
| necessity.
|
| Take Meta's acquisitions of Instagram and WhatsApp under
| Zuckerberg. While these proved strategically valuable,
| framing them as evidence of unique CEO insight misses a
| crucial point: Many others in the organization likely would
| have made similar choices given the same position and
| information. The success stems more from the concentrated
| decision-making power than from individual brilliance.
| What's fascinating is how we conflate organizational
| structure with individual capability. When good outcomes
| emerge from hierarchical systems, we rush to credit the
| person at the top rather than examining how the structure
| itself shapes and amplifies their decisions. This creates a
| self-reinforcing cycle: hierarchical success is used to
| justify more hierarchy.
|
| But imagine if we distributed decision-making power more
| broadly, tapping into the collective intelligence and
| diverse perspectives of entire organizations. Research on
| collective intelligence and successful worker cooperatives
| suggests groups often make better decisions than
| individuals, especially on complex issues. Companies like
| Valve and Morning Star have demonstrated that flat
| organizations can be both innovative and profitable. The
| real opportunity lies in reimagining organizational
| structures that harness our full human potential - not just
| that of a select few at the top. By questioning our
| assumptions about hierarchy, we open ourselves to
| discovering more dynamic, equitable, and effective ways of
| working together.
| pc86 wrote:
| This is a common refrain I've seen on HN when this topic
| has come up before, but there's a problem with it. The is
| a _huge_ difference between (1) "flat organizations can
| work" and (2) "groups make better decisions than
| individuals, and this disparity is even larger on complex
| issues."
|
| If #2 is true shouldn't an organization like Valve run
| circles around every single competitor it has since
| they're all dinosaurs with hierarchies and Valve isn't?
| ryandrake wrote:
| I think questions about whether a CEO is "good" or not are
| kind of impossible to answer, because you can't test the
| answers. All we can observe is the current reality and the
| decisions they've already made. There is no way to observe
| the other alternate universes where Zucc _didn 't_ buy
| Instagram, and/or the universes where he bought something
| else. Did the company do better or worse in those
| universes? No way to know.
|
| Also, sometimes people say things like "Only [ceo's name]
| could run [company]. Look at their results!" This is just
| survivor bias. Who could know whether someone else could or
| couldn't run Facebook (or Tesla, or whatever)? Who can say
| with certainty that out of the 8+ billion people on the
| planet, only one particular guy could run the company, and
| that particular guy happened to be the guy who indeed ran
| it? What an improbable coincidence!
| pc86 wrote:
| Not being able to test alternate universes sans Instagram
| acquisition doesn't mean that it's not impossible to tell
| whether a CEO is good or not, you just have to make a
| qualitative argument for why they are or not.
|
| Buying IG was a good move because it has paid back
| Facebook's shareholders multiple orders of magnitude.
| Isn't the goal of the CEO to steward the company and to
| make shareholders returns (wether public or private)?
| short_sells_poo wrote:
| I wholeheartedly agree with your thoughts, with perhaps the
| exception of the CEO. Or rather, the CEO needs to be someone
| who will be followed by the rest of the organization. Their
| decision making could be replaced by an AI, probably more
| readily than the specialist engineers in fact, but it comes
| back to humans being tribal. Would the middle management follow
| an AI overlord? Would the engineers buy into the AIs decisions?
|
| The CEO's job is to decide on the future direction of the
| company, and then convince both the owners and the employees
| that this is a good direction. The first part is easy to
| replace with AI, the second part isn't. At least not for now.
|
| I guess taken to the limit, the CEO will become replacable the
| moment that the employees have been replaced with AIs, because
| that that point there's nobody left to lead really. One could
| actually argue that this is tantamount to the CEO cutting off
| the branch they are sitting on. After all, once all the
| employees are AIs, what's to stop the shareholders from saying:
| "Hold it right there Steve/Jeff/Mark/etc, why are we paying you
| big bucks? You can be replaced with an AI that will make much
| better decisions, and there are no employees left to lead
| anyway."
| robertlagrant wrote:
| > I guess taken to the limit, the CEO will become replacable
| the moment that the employees have been replaced with AIs,
| because that that point there's nobody left to lead really.
|
| This seems very software-centric. You can do this today -
| e.g. Red Bull famously outsources basically everything but
| marketing[0], so they already have very few employees.
| However they do have a lot of suppliers, and that all needs
| managing.
|
| [0] Their marketing is either simple TV ads or incredibly
| complex stuntwork and extreme sports.
| zug_zug wrote:
| I don't usually love this type of post, but this one is the
| exception - very valuable.
|
| Just the section on how to rewrite alone communicates something
| incredibly valuable that grumpy-engineers like myself have great
| trouble getting others to understand.
|
| I don't have my mind made-up on XP, I've never worked at a place
| that actually supported collaboration (often workers spoke
| different first languages, vastly different experience levels,
| had minimal social graces, were uncomfortable asking questions),
| but I think it _could_ exist with great effort and would have a
| lot of upsides.
| devin wrote:
| It is likely a bit of nostalgia on my part, but one of my first
| gigs had an owner that was focused on XP being the way we
| worked, and given how junior the team was overall, I think it
| produced excellent results and made for a fun, lively
| atmosphere.
| NoMoreNicksLeft wrote:
| > It was September 2023 and my CEO was asking me a question. >
| "How are you measuring productivity?"
|
| This is sort of like your girlfriend asking you "how much do you
| love me". Except if you answer wrong, it's still more likely that
| your girlfriend will stay with you than that you'll keep your VP
| of engineering job.
| languagehacker wrote:
| The advice seems reasonably good but I needed to bail on the post
| because of the cartoons. The anime crossed with precious moments
| style of illustration is just too creepy and inserts a lot of
| doubt to me personally on the authoritativeness of the author.
| RainyDayTmrw wrote:
| This pervasive corporate fiction tires me out so much. Everyone
| says they hire the best candidate, they are leaders in their
| area, etc. It feels very much like dystopian literature, where
| everyone knows the thing to be false, but is compelled to say it
| is true nevertheless.
| cynicalsecurity wrote:
| An article full of buzzwords and a semi-amusing story of how a
| manager successfully bullshitted a delusional CEO. Okay.
___________________________________________________________________
(page generated 2025-01-13 23:02 UTC)