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.

I’ve always been adamant that Product and Engineering are in a partnership, not a “healthy tension” relationship. So I very much agree with this post:

The problem is in the assumption that Product and Engineering teams inherently have different goals. They don’t. Both teams are responsible for the growth and stability of the company, for revenue and scalability. Neither can succeed without the other. When we assume otherwise, we sell each side short.

How to Scale Yourself Down has some really interesting advice on how to go from leading a team at a bigger company to rolling up your sleeves at a startup. A couple of my favorite quotes:

Avoid process out of practice. Leaders who are successful in a startup are the ones who naturally reinvent their own toolboxes, and question what the process is trying to accomplish before establishing something that might be too heavyweight.

However, process is a double-sided coin. “There’s often an overcorrection when leaders move from big companies to small startups. Folks want to shake off that big company feeling and run hard in the other direction. And while the idea of no process sounds fantastic, issues emerge if you don’t start adding at least a little bit of it early on,” he says.

And:

To me, a well-made decision is one that you can explain how and why it was made. Ingraining this in the culture early on will support transparency as the company grows, promote consistency, and reduce politics. In essence, ‘don’t blame me, blame the framework’.