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

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.

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

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

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

> Amazon does not use relational databases

Huh?

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.

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.

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

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

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

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

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

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.

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.

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

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.

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.

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

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

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.

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.