This is excellent advice from Will Larson:

Many high-agency managers try to prevent executives from doing silly things, but it’s almost always more effective to translate their energy for a silly thing into energy for a useful thing. It also leaves the executive feeling supported by your work rather than viewing you as an obstacle to their progress.

He shares some practical examples in the post to illustrate the principle. Also relevant—Casey Winters’s story about executives sometimes wanting their rounded corners on images:

You are going to run into founders, CEOs, execs that want their “corners”, or seemingly irrational markets, product, features, etc. And it’s going to be your job to make those things happen. As a former product leader, I think every CEO or founder should be trusted when they ask for a corner. Now, if they’re doing it all the time, it might just be a bad leader, and you should get a new job. But I have learned to respect there is a thought process I can’t always see, an important reason they can’t always share with me that may make this the right call. So, now I just label certain ideas as corners in the strategy to teams. I can’t exactly lay out all the reasons this makes sense to do now or agree with the ones I’ve heard, but we’re going to do it anyway, and hope it’s the right thing.

I love this sentiment from Austin Kleon:

I am big on being a "curious elder”—and one way, I think, to expand the curious elder idea is to not just be curious about what young people are into, but to also share your curiosity about the world in a way that is generous but without expectation. To point out the things you think are good… just in case somebody, maybe even somebody younger, is looking for them.

I’ll go ahead and keep sharing the things I like, and I hope everyone else does too.

I like Erik’s thoughts about AI and coding in Replacing my Right Hand with AI:

I do think that AI will lower the bar for anyone to be able to create software, just like anyone can use Excel to do their own personal accounting. This is a good thing!

And:

Human engineers won’t go away. We’ll still be needed to drive high-level prioritization, understand the overall architecture and scope of the problem, and review the AI’s work, especially as systems get bigger. But we’ll spend much more of our time thinking about what to build, and much less on the repetitive “how” of building it.

On the Product side of this argument, there is Paweł Huryn’s Will We Lose Our Jobs to AI? Cutting Through the Hype. Short answer: no! But he makes some points about how we should adapt that I agree with, especially these two:

• Educate yourself in AI: You should understand concepts like fine-tuning and AI agents, but there’s no need to obsess over them. YouTube videos are perfectly fine unless you want to tie your career more closely to AI.
• Get interested in the business side of the product: How do your organization’s Sales, Success, and Support teams work? How exactly does your company make money? How do you acquire customers? What are the key acquisition, retention, and revenue metrics? How do these metrics differ depending on the customer segment? How have they changed over time? Who are your competitors? What’s unique about your strategy?

In short, use AI for the things that it is good at, and get better at the things that it’s not good at.

I loved the story of the honking Waymos when it came out, and I’m glad it got the classic “but what does it all mean!?” treatment from The Atlantic:

Watching the Waymos circle the lot under the cover of darkness—and occasionally getting stuck in an endless loop—scratches a childish itch, akin to the fantasy of watching one’s toys come alive at night. In one video, the cars, bathed in taillight red and trying to exit, give off an aggressive vibe. In others, they seem clumsy. What do robots do when we can’t see them? Tung’s webcam answers the question. The stream makes it easy to spin up fictionalized, anthropomorphized yarns about the cars, because it feels like we’ve caught them in a private moment.

This whole story reminds me of scene from I, Robot where Will Smith’s character discovers a bunch of decommissioned robots in a junkyard just… standing around doing nothing. Well, until they don’t… But no spoilers.

I am a big believer in “moving at the speed of trust” with teams. You cannot shortcut the work to build strong relationships—and I’m afraid there is no roadmap or deadline for that. Sometimes it’s easy, sometimes it takes longer. But don’t skip this work. Move at the speed of trust.

Ben Kuhn shares some good tips around this in Trust as a bottleneck to growing teams quickly. I particularly like these two:

• Overcommunicate status. This helps in two ways: first, it gives stakeholders more confidence that if something goes off the rails they’ll know quickly. And second, it gives them more data and helps them build a higher-fidelity model of how you operate.
• Proactively own up when something isn’t going well. Arguably a special case of overcommunicating, but one that’s especially important to get right: if you can be relied on to ask for help when you need it, it’s a lot less risky for people to “try you out” on stuff at the edge of what they trust you on.

And speaking of communication… Also see Arne Kittler’s Part 4: Clear Communication, part of a series on “Clarity for Product Managers”:

Lengthy texts dilute your message or even discourage your counterparts to deal with them in the first place. Focus on the main points you want to make and provide the context that’s necessary to understand them as quickly as possible. When asking for information or a decision, be clear about what’s unclear.

Lorin Hochstein shares a characteristically solid systems-thinking take in CrowdStrike: how did we get here?:

Systems reach the current state that they’re in because, in the past, people within the system made rational decisions based on the information they had at the time, and the constraints that they were operating under. The only way to understand how incidents happen is to try and reconstruct the path that the system took to get here, and that means trying to as best as you can to recreate the context that people were operating under when they made those decisions.

The “no root cause” concept is something I’ve been thinking about a lot as I’m working on a particularly complex project at work. Somehow we constantly forget that things usually are the way they are not because of a single “mistake”, but because of a the culmination of a bunch of legitimate reasons.

Systems get the way they are because of decisions made in good faith based on the data available at the time. And the worst thing you can do as a new person coming in to improve things is to hunt for a single “root cause” to fix. That’s just not how software (or people!) work. So take the time to understand Chesterson’s fence. Go ahead and draw boxes and arrows until no one disagrees any more about how the system works. And then figure out which parts can be improved, and in which order.

PS. Also see How Complex Systems Fail:

Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.