I didn’t realize that there’s a strategy backlash going on in some corners of the internet, but Packy McCormick has a good defense of the importance of having a good strategy:

Execution without strategy is wasteful and tragic. Just as “Companies that have the best products, most talented people, and fastest growth are precisely the ones for which moats are most important,” companies that are the best at execution are precisely the ones for which strategy is most important. They’re the only ones that have a shot. The better you are at execution, the faster you can run in any direction. A good strategy helps you run fast in the right direction.

He also provides a good summary definition of what strategy is, based on the (must-read!) book Good Strategy Bad Strategy: The Difference and Why It Matters:

A strategy is a high-level plan to achieve one or more goals under conditions of uncertainty, designed through recognizing the challenge (diagnosis), setting a direction to overcome it (guiding policy), and detailing steps to implement the policy (coherent actions).

The biggest problem I’ve seen in organizations that struggle with good strategy is that everyone wants a strategy but it’s very hard to figure out how to get started with its creation. It is such a lofty, nebulous concept, and everyone has a different idea of how to go about it. So it’s really important to define what it is and what it’s for, and get broad agreement on that, before starting to create a strategy. To put it another way, make sure you define the black hole words.

For more on this, check out my (very long) case study on Collaborative Product Strategy Development.

Since I prefer reading over watching, I appreciate Dave Rupert’s summary of this video about AI/LLM responsibility in his post Uncovering a new class of responsibilities:

Three rules of technology outline their nearly hour long talk:

1. When you invent a new technology, you uncover a new class of responsibilities
2. If that tech confers power, it starts a race
3. If you do not coordinate, the race ends in tragedy

It’s those last steps that are the concerning ones. If we fail to respond to #1, we end up with #3.

Here’s a good reminder that Incidents can’t be prevented, but learned from:

But approaching incidents with a mindset of learning makes it an exciting rather than painful situation. Because you’ll know you’ll never run out of sources for learning. And once you’ve realised what a good source for learning incidents are, it’s maybe even time to take a good look whether shallow incident data like “mean time to detection” and “mean time to resolution” (or the maybe worst offender of all “mean time between failure”) are actually helping your team approach incidents as a learning opportunity or maybe are incentivising an approach that foregoes learning for a better look of those metrics.

I like Tracy Durnell’s Reading Philosophy in 17 Guidelines, especially this one:

Treat my To Be Read list as a stream to dip into, not a to-do list. I know I won’t get to all the books on my TBR.

It reminds me of an article from 2011 that I come back to often—The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything:

Now, everything gets dropped into our laps, and there are really only two responses if you want to feel like you’re well-read, or well-versed in music, or whatever the case may be: culling and surrender.

Culling is the choosing you do for yourself. It’s the sorting of what’s worth your time and what’s not worth your time. It’s saying, “I deem Keeping Up With The Kardashians a poor use of my time, and therefore, I choose not to watch it.” It’s saying, “I read the last Jonathan Franzen book and fell asleep six times, so I’m not going to read this one.”

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time, and that this fact doesn’t have to threaten your sense that you are well-read. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.”

Here’s a great post by Camille Fournier about The Product Culture Shift, and how every part of an engineering culture needs to change when product managers are added to traditional software infrastructure organizations.

To start, let’s be clear about one thing: as tempting as it might be, just hiring product managers won’t fix this problem. Even if you could find enough good product managers who want this type of job, which you can’t, product managers are only useful when they are paired with willing engineering teams. If the engineering teams don’t feel a sense of ownership for delivering a great product to their customers, product managers are unlikely to close that gap, and they will more likely turn into glorified backlog groomers than true product leaders.

Excellent post by danah boyd, reminding us that with social networks it all comes down to nurturing the network dynamics, not the technical features.

That’s the thing about social media. For people to devote their time and energy to helping enable vibrancy, they have to gain something from it. Something that makes them feel enriched and whole, something that gives them pleasure (even if at someone else’s pain). Social media doesn’t come to life through military tactics. It comes to life because people devote their energies into making it vibrant for those that are around them. And this ripples through networks.