[bushido]

Interestingly, they landed on a conclusion which I have often argued against these days [0]. Code is absolutely cheap, and previously, it was the most important resource that we guarded.

Entire job descriptions and functions were built to guard the engineer's time. Product owners, product managers, customer success, etc., all shielded the engineers who produced code because that was the scarcest resource.

With that scarcity gone, we really need to be thinking about the entire structure differently. I'm definitely in the we still need people camp. The roles are wildly different, though. We can't continue doing the same job that we did with a slight twist.

[0] https://dheer.co/gatekeeping-on-a-different-stage/

[datadrivenangel]

I partially disagree for two reasons:

1. Code is absolutely cheap, but good, correct, non-vulnerable code is much cheaper than it was a few years ago but is still not free, especially in a large application.

2. Requirements management is less important when the cost of software is lower because iteration is cheaper, but bad customer communication can absolutely result in negatively useful software, and there is a skill to understanding what people want and need that takes a lot of time to use well, so in many cases a product manager can still help do useful work... most won't though.

[bushido]

That's partly the harness for me. I do believe product managers are still important, but they're important in deciding what gets shipped, not what gets built.

Engineers are still important. They're important in building the harness to ensure that anything which is being built/shipped is of sufficient quality.

In my opinion, testing/QA/etc is now the core product.

But the best code that you'll get is literally connecting to the pain point the customer was saying to the agentic workflow that is building your product.

Bad customer communication in my experience is the result of every person who handled the convo pre-engineers posturing the message trying to make sure the next person is motivated to get it to the next gatekeeper.

This is all very biased based on my own workflow though.

[rawgabbit]

According to Block. https://block.xyz/inside/from-hierarchy-to-intelligence. There will be three generalized roles in tech:

     Individual contributors (ICs) who build and operate capabilities, the model, the intelligence layer, and the interfaces. They are deep specialists and experts in a specific layer of the system. The world model provides the context that a manager used to provide, so ICs can make decisions about their layer without waiting to be told what to do.
     Directly Responsible Individuals (DRI) who own specific cross-cutting problems or opportunities and customer outcomes. A DRI might own the problem of merchant churn in a specific segment for 90 days, with full authority to pull resources from the world model team, the lending capability team, and the interface team as needed. DRIs may persist on certain problems or move elsewhere to solve new ones.
     Player-coaches who combine building with developing people. They replace the traditional manager whose primary job was information routing. A player-coach still writes code or builds models or designs interfaces. They also invest in the growth of the people around them. They don't spend their days in status meetings, alignment sessions, and priority negotiations. The world model handles alignment. The DRI structure handles strategy and priority. The player-coach handles craft and people.

To give a sports analogy. The player-coaches are the coach who rose through the ranks and now gets to choose and develop the other players on the team. The individual contributors are functional specialists e.g., defender, halfback, forward etc. The DRI "own" specific scenarios e.g.: penalty kicks, throw-in at the corner etc.