[HN Gopher] James Shore: The Best Product Engineering Org in the...
___________________________________________________________________
James Shore: The Best Product Engineering Org in the World
Author : kiyanwang
Score : 61 points
Date : 2025-01-12 19:27 UTC (3 hours 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."
| 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.
| 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)._
| 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].
| 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.)
| 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...
| 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.
| 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?
| 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.)
___________________________________________________________________
(page generated 2025-01-12 23:00 UTC)