upvote
This tension is why I refer to myself as a product engineer. Teams where non-technical product managers (ie. your "product team") become feature factories that eventually drown in their own tech debt. Teams where navel-gazing engineering managers (ie. your "engineering team") have too much power end up with premature platformization, and beautiful architecture diagrams while user needs go unmet.

The key is to understand that computers exist to serve human needs, and the less code / UI / hoops to solve a problem the better, and to think end-to-end. If you are able to do that, most systems built by committee have a lot of low-hanging fruit that can be improved without much sacrifice. In practice, political realities and operational concerns may come in the way, but I firmly believe this is the only way to successfully operate as an engineer, and it will only become more important in the age of AI.

reply
And I feel that stuff like agile is now even more important than before. Now it’s role should be more about protecting customers from bad changes and following whole processes through where you actually measure the impact. It’s just too easy to do those 100k lines changes to products because it’s some vice presidents pet project.
reply
deleted
reply
If you build your platform well, then you can execute fast, but also safe.

I push "money and data are sacred"; if we lose either of those, someone cries. Build the platform slow and fast. Governance, scaling etc sits here.

Provide reference APIs and let the product team one shot whatever they want and need, build fast and experimental, but your platform enforces constraints.

Best of both worlds (though feels like we're back in backend vs frontend development)

reply
>If you build your platform well, then you can execute fast, but also safe.

this is extremely true, but it seems less and less like anyone wants to invest in a solid platform and just wants to jump to executing fast and unsafe. and then pretends that ai can definitely do both when the experience is quite a bit different.

reply
I have seen at least one example develop in real time. You typically spent years building before you had a platform, then lack the enthusiasm from senior leadership to invest the next 12-18 months with no new features and hard to quantify - maybe no - returns. Then you get displaced by newcomers who are "platform native"; what this really means is their engineering misteps haven't been discovered yet, or even if they guessed correctly the world has turned and made their previously correct solution now a failing one. And now we have something called "AI-native" that is going to solve this once and for all with some sort of magic, and you can't lead these companies unless you truly believe in the magic.
reply
“ You typically spent years building before you had a platform, then lack the enthusiasm from senior leadership to invest the next 12-18 months with no new features and hard to quantify - maybe no - returns.” —> this is failure from the team and especially people who should do product management job on that team.
reply
I'm lucky I guess, I feel like the product team is on "my side" with respect to building a resilient system. They understand that bad architecture shows up as a fragmented and friction-full UX.

The demand for new features come from sales and executive people who want to check more boxes on a customer's checklist.

reply
Ultimately your paycheck exists through deals that involve those boxes on checklists. It doesn't simply materialize out of thin air. If there are no deals, it doesn't matter how robust and elegant the architecture is.
reply
Features don’t usually come from product teams. They come from above: some Head Of, VP Of, and the like. Those people only ask, they know very little about execution. They want their wishes come true in a timely manner
reply
They have been vibecoding via a harness of human LLMs this whole time.
reply
I think this is the key to some of this debate.

Management/Product/Product Engineer - When you are responsible for getting the work done then you look for any and every option to speed it up.

Owner/Platform/Senior Engineer - When you are responsible for ensuring it works and can be maintained then you have to pay attention to how to build it, aka the trade offs

reply
Well support teams are even closer to the customer than product and I think they would advocate for perf/stability over more features.
reply
How would that change when support teams themselves are replaced by LLM agents
reply
Any evidence that this can be done without terrible self-harm to the business?
reply