Good advice here on when (and when not!) to hire the first product manager in a startup. This is also a good reminder to “let PMs be PMs”…

PMs are the strategy arm of this process, and should be empowered to own the roadmaps for how they’ll better the business, not just the execution of getting things built. In an ideal world, PMs will have better decision-making and execution than you within their domains due to focus and proximity to customer needs. This is how you scale. If you continue to hold all of the strategic decisions close to the vest and use PMs as glorified interns, you’re wasting all of the focus that they could be bringing to bear.

There’s some good insights in this year’s 2023 State of DevOps Report. It’s well worth skimming through. Things like this aren’t exactly surprising, but it’s nice to have some data around it:

Teams with generative cultures, composed of people who felt included and like they belonged on their team, have 30% higher organizational performance than organizations without a generative culture.

Ed Zitron’s newsletter is kind of a hate-read for me because his vitriol knows no end and it can be a lot… but I think he did pretty well in his response to Marc Andreessen’s latest essay:

This is Andreessen’s dream—a continual race to the bottom where the tech industry is incentivized not to solve problems, but to find ways to make already-solved problems cheaper to solve so that venture capitalists can make money.

That’s a good quote, but please don’t stop there. The whole essay is the best rebuttal I’ve seen so far.

This is a thoughtful, well-argued essay by Benedict Evans about where we’re at with LLMs.

Whenever we get a new tool, we start by forcing it to fit our existing ways of working, and then over time we change the work to fit the new tool. We try to treat ChatGPT as though it was Google or a database instead of asking what it is useful for. How can we change the work to take advantage of this?

This is an older post from Lorin Hochstein but it’s new to me, and really insightful. It’s about how to best use our knowledge about the past behavior of a software system to figure out where we should invest our time to improve the system—and how the common method of error budgets is generally not a good way to do this:

I’m skeptical about relying on predefined metrics, such as reliability, for getting insight into the risks of the system that could lead to big incidents. Instead, I prefer to focus on signals, which are not predefined metrics but rather some kind of information that has caught your attention that suggests that there’s some aspect of your system that you should dig into a little more.

So basically, vibe-based incident analysis is where it’s at.

This is a great document outlining the communication principles followed by GitHub Engineering. I’d say this is broadly applicable to teams and organizations—not just Engineering. I love this point about making work visible:

Capturing and exposing processes through URLs also helps make your work more visible. So work in the open and proactively share your work to the widest extent practical. As we continue to grow as an organization, points of collaboration will become even more important as we try to reduce redundant work. Avoid hoarding information: Like in any production system, observability is key. And if you make something useful, find a way to make it available so others can benefit from it too.

Good points here from Teresa Torres about deadline-driven development, especially the need to take change management slowly:

If your stakeholders are insisting you use date-based roadmaps, I wouldn’t engage in the ideological war about deadlines and predictable work. Instead, start with a feature-based roadmap. Give your stakeholders what they are asking for, and over time, you can introduce opportunities and outcomes.

Some great advice here on what to do when teams stop talking to each other. Starting with why it’s a big problem when that happens:

Teams that don’t talk to each other outside of transactional topics are barely teams at all. High-trust, high-engagement teams outperform, and those teams live and die on their ability to talk to each other. If that’s broken, your team is broken.