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.

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.

Molly Graham makes a key distinction about good management in the post Manage the What, Not the How:

The key to exceptional management is to get great at defining the “what”. As a leader, you need to know how to create alignment, how to clarify what you expect, and how to communicate all of it. 

She goes on to explain that a big mistake she sees some managers make is to focus too much on how work is done. And when you do have to get involved in the “how”, do it through coaching:

When you intervene, you intervene with coaching. You can say, “That email you sent seemed abrupt,” or “You missed these two points that were important.” You can share examples to learn from. You’re giving feedback and then letting them try it again, not jumping in to micromanage.

I love the point Simon Sarris makes here about the importance of reading fiction, and how it’s useful for work purposes as well:

I also tend to stress fiction because I think, especially among my professional peers in the industry of software, that there is too great a fondness for non-fiction. I think this arises from a belief that superior knowledge of the world comes from non-fiction. This thought is attractive to people who build systems, but over-systematizing and seeing systems in everything can be a failure mode. Careful descriptions and summaries miss too much of the world. Hard distinctions make bad philosophy. Reading fiction helps you become an unsystematic thinker, something that is equally valuable but more elided by some engineers. It is easy to maintain an intellectual rigidity. It takes more care to maintain a loose poeticism of thought.

Allie Conti frames the remote work debate really well in this post. In short, how someone feels about remote work and “return to office” is extremely personal:

I’ve given you this narration of my personal experience because, for all the talk of productivity and metrics and company culture, the topic of returning to the office is intensely personal. My needs and desires, for a variety of reasons relating to my age, finances, circumstances, health situation, and lifestyle, might be very different from those of workers who fall elsewhere on any of those axes. Some working parents have said they might value flexibility at school-pickup time. Some workers of color have raised the benefit of being free from in-office microaggressions. Recent college graduates may want to go into the office to make friends. And of course, not all workers are able to work remotely. The physical space in which one works, or hopes to work, intersects with one’s most personal choices. It collides with and reveals what people value most.

It feels like we should find ways to cater for both types of preferences. Hybrid work environments are far from an ideal solution, but it is one way to meet in the middle.

Josephine Conneely has some excellent thoughts on the feared P-word in How Process Impacts Your Culture. I especially like going back to the purpose of adding process when evaluating what you have in place:

The aim of process in its purest form is to:

• Facilitate ease of doing work: Design methods for teams to effectively work together, make decisions, and achieve their goals.
• Reduce risk: Ensure company doesn’t fall foul of legal & compliance obligations or go bankrupt.
• Ensure consistency and fairness: Aim for all customers and employees to have a similar experience in their interactions with an organisation.

Some good tips here from Kax Uson on How to receive feedback—especially when you don’t agree with it:

Validate the feedback with other people. There will be times when we don’t really trust the feedback we receive, or in some cases, the people who gave them to us. This is normal. When this happens, it’s worth cross-checking the feedback with the people we trust. I like to think of it as getting a 2nd opinion vs immediately dismissing the feedback or overthinking it.

Here’s a good post from Gergely Orosz discussing Interesting Learnings from Outages. It covers internal vs. public postmortems, how investing in reliability can have bumps along the way, and how to make the difficult decision to try and fix something on the spot, or to do a lengthy restore. This point stood out to me:

“Move fast with autonomous teams” often builds up infrastructure debt. Reddit is a fast-moving scaleup where teams move fast, and it sounded like they had autonomy in infrastructure decisions. The wide range of infra configurations caused several outages, and the company is now paying down this “infrastructure debt.” This is not to say that autonomous teams moving fast is a bad thing, but it’s a reminder that this approach introduces tradeoffs that could impact reliability and will eventually have to be paid down, often by dedicated teams.