alt.hn

1/12/2025 at 7:27:07 PM

If we had the best product engineering organization, what would it look like?

 https://www.jamesshore.com/v2/blog/2025/the-best-product-engineering-org-in-the-world

by kiyanwang

1/13/2025 at 10:00:18 AM

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.

by abc-1

1/13/2025 at 10:30:45 AM

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.

by wodenokoto

1/13/2025 at 12:30:06 PM

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.

by Xcelerate

1/13/2025 at 3:31:53 PM

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.

by mempko

1/13/2025 at 10:01:38 PM

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?

by pc86

1/14/2025 at 12:24:09 AM

Valve does run circles around every competitor it has.

by jdlshore

1/13/2025 at 9:06:04 PM

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!

by ryandrake

1/13/2025 at 9:53:59 PM

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)?

by pc86

1/13/2025 at 11:29:51 AM

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.

by miki123211

1/13/2025 at 12:31:50 PM

> 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.

by Zanfa

1/13/2025 at 5:59:31 PM

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.

by rohit89

1/14/2025 at 1:12:37 AM

> It was FOMO.

> Just like every other company

What other companies (besides Apple and a few startups that were specifically in the metaverse space) went in on the metaverse?

I think this was very much unlike AI and crypto, where everybody wanted a piece of the pie. Meta seemed a lot more invested in this than most of the other tech players, which makes FOMO an unlikely explanation to me.

by miki123211

1/13/2025 at 3:11:42 PM

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.

by Clubber

1/13/2025 at 4:46:54 PM

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.

by zqy123007

1/13/2025 at 4:27:28 PM

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.

by wavemode

1/13/2025 at 6:02:41 PM

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.

by rohit89

1/13/2025 at 11:03:48 AM

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."

by short_sells_poo

1/13/2025 at 11:14:41 AM

> 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.

by robertlagrant

1/12/2025 at 10:41:17 PM

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.

by Sevii

1/13/2025 at 2:40:08 AM

> 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.

by saghm

1/13/2025 at 5:26:37 AM

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.

by xwolfi

1/13/2025 at 6:57:45 PM

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.

by saghm

1/13/2025 at 8:25:53 AM

Nothing teaches you to swim like being thrown in the middle of the atlantic.

by pyrale

1/13/2025 at 3:17:13 PM

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.

by Sevii

1/13/2025 at 7:06:36 PM

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.

by saghm

1/13/2025 at 1:47:47 PM

> 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".

by wesselbindt

1/13/2025 at 4:30:08 AM

> 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.

by infomaniac

1/13/2025 at 12:41:07 PM

If it was using MyISAM relations are in question.

by chupasaurus

1/13/2025 at 1:56:20 PM

SQL, and therefore MySQL by extension, isn't relational.

by 9rx

1/13/2025 at 8:58:15 PM

He typed smugly, confident that everyone reading this will appreciate his pedantry that totally contributed to the conversation

by snapcaster

1/13/2025 at 9:07:21 PM

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.

by 9rx

1/12/2025 at 10:46:48 PM

> Amazon does not use relational databases

Huh?

by rrr_oh_man

1/13/2025 at 1:38:01 AM

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.

by vamega

1/13/2025 at 2:37:49 AM

So they do joins in code rather than SQL? Wouldn't that risk hiding scaling problems?

by emmelaich

1/13/2025 at 3:11:59 AM

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.

by grogenaut

1/13/2025 at 3:56:35 AM

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 ....

by mickael-kerjean

1/13/2025 at 11:16:49 AM

How did you run explain queries on DynamoDB? Or may be you mean something different and I misunderstood you?

by redditor98654

1/17/2025 at 2:45:11 AM

I ran explain on the original mysql implementation. The basis of the migration project to dynamo was mysql couldn't cope with our scale but that was bullshit

by mickael-kerjean

1/13/2025 at 2:07:13 PM

That doesn't make sense, you have to specify the index when you're using Dynamo.

by bdavisx

1/13/2025 at 2:21:32 PM

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

by scarface_74

1/13/2025 at 5:57:38 AM

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.

by scarface_74

1/13/2025 at 7:30:05 AM

Amazon Retail has multiple systems to allow you to basically use SQL across databases (eg Datapath).

I’m not sure about AWS.

by yazaddaruvala

1/12/2025 at 11:01:33 PM

Friends say they typically use Dynamo and that using a relational database requires approval from a vp (because of scaling concerns).

by deskglass

1/13/2025 at 2:32:48 AM

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_oracle...

by hyperliner

1/15/2025 at 5:43:44 PM

Kicking out Oracle might have to do with factors outside the usage of relational databases...

by rrr_oh_man

1/16/2025 at 5:43:19 PM

[dead]

by hyperliner

1/13/2025 at 2:25:40 PM

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.

by zug_zug

1/13/2025 at 3:37:23 PM

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.

by devin

1/13/2025 at 8:53:30 AM

> 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

by switch007

1/13/2025 at 10:04:31 AM

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.

by Rygian

1/14/2025 at 5:11:46 AM

>"We sort of had to collectively admit we were wrong on the premise that you will be happiest if you work on something you personally want to work on the most," Valve developer Robin Walker tells Keighley, soundly rejecting the ethos that Valve has publicly carried as a torch for some time. The studio used a new Half-Life [Alyx, 2020] project as a way to focus the entire studio—even though, as we've previously reported, that project began life with more modest expectations in terms of length and content.

https://arstechnica.com/gaming/2020/07/valve-secrets-spill-o...

by Maxious

1/13/2025 at 7:39:43 PM

> 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".

by InitialLastName

1/13/2025 at 1:36:51 PM

To be fair - it says “tactical” decisions - not all decisions.

by pjm331

1/12/2025 at 8:48:12 PM

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.

by lubujackson

1/12/2025 at 10:19:33 PM

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."

by Sevii

1/13/2025 at 6:40:03 AM

> FAANG level people

"FAANG" isn't a "level", it's just a cluster.

by numbsafari

1/13/2025 at 1:48:51 AM

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.

by holografix

1/13/2025 at 2:39:13 AM

> 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.

by khazhoux

1/13/2025 at 4:25:19 AM

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.

by noirbot

1/12/2025 at 9:47:18 PM

The recent book The NVIDIA Way is about that org’s culture that prevent FAANG incentives from creeping in to destroy productivity.

by adastra22

1/12/2025 at 9:15:32 PM

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?

by zeroonetwothree

1/12/2025 at 9:37:16 PM

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.)

by Trasmatta

1/13/2025 at 3:13:42 PM

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.

by ebiester

1/12/2025 at 10:16:54 PM

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.

by llm_trw

1/13/2025 at 2:34:33 AM

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.

by skeeter2020

1/13/2025 at 3:41:27 AM

Maybe that other dev has a unique ability you should reward. Sound awesome. Focus on that.

by ggregoryarms

1/12/2025 at 9:22:31 PM

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].

by jprete

1/13/2025 at 1:54:32 AM

Gut feeling uses all your internal predispositions and biases.

by fshafique

1/13/2025 at 2:36:08 AM

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.

by skeeter2020

1/13/2025 at 4:28:02 AM

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.

by noirbot

1/12/2025 at 10:16:30 PM

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.

by Sevii

1/12/2025 at 10:38:01 PM

Or you may find they write higher quality code - less bugs, more performant code, or so on.

by bigs

1/12/2025 at 11:14:10 PM

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.

by Salgat

1/12/2025 at 9:19:45 PM

You can measure productivity by measuring the success, but that's kinda useless for day to day software engineering management.

by throw5959

1/12/2025 at 9:43:02 PM

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.

by ChrisMarshallNY

1/12/2025 at 10:01:51 PM

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?

by pinkmuffinere

1/12/2025 at 10:04:58 PM

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).

by ChrisMarshallNY

1/13/2025 at 2:37:29 AM

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.

by skeeter2020

1/13/2025 at 11:27:30 AM

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.

by ChrisMarshallNY

1/12/2025 at 9:41:58 PM

How do you define success? If a product bombs, is that because of the engineering or the product design?

by Trasmatta

1/12/2025 at 9:56:03 PM

I don't think it's possible to answer generally. Track what matters for your business.

by throw5959

1/13/2025 at 2:38:54 AM

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.

by skeeter2020

1/12/2025 at 10:18:01 PM

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...

by daz0007

1/12/2025 at 11:13:17 PM

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.

by theideaofcoffee

1/13/2025 at 3:11:08 AM

> 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?

by paulcole

1/13/2025 at 12:11:16 AM

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.)

by gwern

1/13/2025 at 4:23:57 AM

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.

by blululu

1/13/2025 at 7:38:29 AM

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!

by drcwpl

1/13/2025 at 9:44:11 AM

First, it would be worker-owned co-op with very little turnover and intense competition for the few roles that get filled.

by magic_smoke_ee

1/12/2025 at 10:29:32 PM

+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.

by mrbluecoat

1/12/2025 at 10:30:46 PM

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.

by Trasmatta

1/12/2025 at 11:16:21 PM

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.

by Salgat

1/13/2025 at 2:01:59 AM

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.

by NomDePlum

1/13/2025 at 6:16:40 PM

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.

by p_l

1/13/2025 at 2:40:12 AM

resist the oxymoron of agile zealot - the first rule is do what works for YOU

by skeeter2020

1/12/2025 at 10:47:41 PM

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.)

by mft_

1/13/2025 at 3:28:28 PM

> 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.

by NoMoreNicksLeft

1/13/2025 at 5:19:26 PM

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.

by RainyDayTmrw

1/12/2025 at 11:39:25 PM

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.

by nine_zeros

1/14/2025 at 7:07:31 PM

Ah, this looks to be my favorite "non-management" bullshit game: Put stickies of words like "People" "Process" "Love" "Care" "Profitability" "Quality" and so on, pick some of those words and build a stupid story around those words. The story is usually summarized as "we'll have the best of the best people, doing best of the quality, with best of the best profitability, spreading much love".

What about all the words that are not picked? That's for 2 years later, when they play the same game again.

Here's the last but least favorite part: beat employees into memorizing those words, have them graded against these words based on entirely subjective interpretations, and reward those who are good at playing this game.

Some people are just story tellers, not doers.

Then I look at the profile of the author of this blog. Yeah, makes sense.

by rdsubhas

1/13/2025 at 7:43:56 AM

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.

by weinzierl

1/13/2025 at 8:40:38 AM

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.

by heeton

1/13/2025 at 9:01:46 AM

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

by sisve

1/13/2025 at 9:20:28 AM

if you'll allow some negativity, I wouldn't expect a talk at a "Scrum Gathering" to care much about the Agile Manifesto

by agos

1/12/2025 at 11:16:13 PM

> 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?

by joeldo

1/12/2025 at 11:36:52 PM

> 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."

by jh00ker

1/14/2025 at 2:50:16 PM

reminds me of a teammate who pushed for fast tests and clean code. most of us thought it slowed us down, until a big production bug hit. he pushed a fix in 15 min / his tests made it easy to find and solve. after that, we all bought in. small changes can make a huge difference.

by fasten

1/12/2025 at 8:53:07 PM

That was a breath of fresh air. Thank you James.

by gpi

1/13/2025 at 3:45:06 PM

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.

by languagehacker

1/13/2025 at 2:22:53 AM

What's the clickbait headline refer to? I can't find any mention of the company in a skim of the article.

by raldi

1/13/2025 at 2:52:57 AM

I've replaced the clickbait title with a more representative sentence from the article.

by dang

1/13/2025 at 3:47:50 AM

...starts off by saying you can't measure productivity. Then proceeds to explain how to measure productivity. Very sneaky.

by gijoeyguerra

1/13/2025 at 6:13:58 PM

An article full of buzzwords and a semi-amusing story of how a manager successfully bullshitted a delusional CEO. Okay.

by cynicalsecurity

1/13/2025 at 1:51:00 AM

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.

by LudwigNagasena

1/13/2025 at 2:30:41 AM

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.

by skeeter2020

1/13/2025 at 8:02:40 PM

> 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.

by 9rx

1/13/2025 at 10:45:53 AM

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.

by n4r9

1/13/2025 at 6:15:40 PM

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.

by LudwigNagasena

1/13/2025 at 7:38:18 PM

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.

by n4r9

1/14/2025 at 12:51:05 AM

[dead]

by robinbrownford