How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat.

I know Apple has a reputation for good UX but I think it's carry over from a different era and it's trending down.

I bought my kid an iPad for Christmas and set up parental controls, then could not disable it without another iPad (which I don't have).

There are many forum threads concluding you just have to factory reset.

I couldn't believe how many little unintuitive things I bumped into setting it up.

His learnings from 14 years at Google. Surely we've all learned things working for employers or with engineers that don't do a thing well.

In 14 years he probably also experienced great engineers come and go and start other successful businesses they very likely did not run exactly like Google.

I'd love to read this article but the website is cancer. I keep clicking dismiss on mobile and it takes me to another website.

Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.

Given the way most templates about Web Components are going it feels like a dirty secret that you don't need to use Shadow DOM at all when building Web Components and that it actually feels nice to build Web Components without it.

Following "easily defeated" with "teaching everyone" gave me an audible chuckle.

Or use a checkbox and stop trying to make toggles a thing, since they just don't translate to digital as well.

If it helps, it's not for you.

Execs can't do this themselves because they don't have the information they need, and are trying to be predictable and compete in a market. So think about it as an ELI5 exercise where you're infantilizing up, or as it's more commonly and professionally referred to, managing up, or more plainly, helping the business make better decisions.

Helping the boss convince the market he made better decisions.

I often feel the frustration when I'm writing some data-crunching report-extraction thing, of the knowledge that the output of it will be some administrator squinting shrewdly at it and thinking himself better informed. Then he'll do pretty much whatever he would be doing anyway.

And that's the better case. I suspect in many cases they don't look at the information they ask for at all.

Maybe with a shitty boss and a complacent environment. Help them not squint at it and make a gut decision. Why not instead ensure the objective of the report is clear, there's a meaningful target around which to hinge on a decision, and present the data in a way that helps make the decision? And in lieu of the time or resources to do that, work on those problems?

Well, since I recently quit, I suppose that's what I'm trying.

Or building things that help retain current customers vs acquire new customers so sales has something to sell.

The bigger problem as I've seen it is engineers that don't see themselves as part of the business, either because of the culture or personal choice around lack of focus on soft skills.

All too often engineers spend zero time understanding the market and customers, and scaled agile, as it's typically implemented and managed, definitely doesn't help.

> All too often engineers spend zero time understanding the market and customers,

From my perspective the problem is that companies invest zero time in training engineers about the market and companies, and instead just treat engineers like assembly line cogs that produce business value on-demand.

Upper funnel/lower funnel, depending. And don't forget the future employees that take notice of a culture that would allow for such an exercise. To me, it communicates good product management, roadmaps, and healthy financials to allow the room to breathe.