In the latest Platformer piece Meta doubles down on layoffs we see a perfect example of why stable software development teams are more effective than “agile teams” where people are seen as interchangeable cogs in a machine. When leaders think that people can be moved around between projects and “initiatives” at will and without knock-on effects, they run headlong into the basics of systems thinking, as shown here by Mark Zuckerberg’s realization:

In retrospect, I underestimated the indirect costs of lower priority projects. It’s tempting to think that a project is net positive as long as it generates more value than its direct costs. But that project needs a leader, so maybe we take someone great from another team or maybe we take a great engineer and put them into a management role, which both diffuses talent and creates more management layers. […] Indirect costs compound and it’s easy to underestimate them.

As a side note, this is honestly a pretty frustrating thing to read. It seems like such a basic software development concept—was there no one in Mark’s orbit that could tell him about the indirect costs of building VR headsets? And now that epiphany is costing Meta another 10,000 jobs. Ugh.

From How to Be a PM That Engineers Don’t Hate:

You see it everywhere: Engineers complaining about the product managers that they work with. Hating on PMs is kind of like complaining about your utility provider or the TSA—so universal that it’s always good for a light chuckle in the right circles. The PMs don’t know how the technology works. All they do is send emails and take credit. They’re meeting generation machines.

When I interview engineers my first question is always, “Tell me about your experience working with PMs.” I do it to calibrate what kind of PMs they are used to working with, or to put it another way, how much I should apologize for our profession before we continue…

Anyway, the linked post is less about that, and more about some things PMs can do to work more collaboratively with other teams—not just engineering. Lots of good, practical tips and examples here.

Jade Rubick resurrects an old engineering concept (and dead Wikipedia page!) in Steel threads are a technique that will make you a better engineer:

A steel thread is a very thin slice of functionality that threads through a software system. They are called a “thread” because they weave through the various parts of the software system and implement an important use case. They are called “steel” because the thread becomes a solid foundation for later improvements.

With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.

He explains this in detail in the full post, with lots of helpful examples.

Here’s an interesting article by Will Larson with advice on how to move past incident response to reliability in our products. Among other things it reminded me to watch out for “incident legalism”:

Incident legalism is when an incident response and analysis program—trying to better drive reliability improvements—becomes focused on compliance and loses empathy for the engineers and teams operating within the program’s processes.

He goes on to propose a more holistic, expanded model for reliability to help teams diagnose their systemic problems—and how to solve them:

Finally, you study the mitigated incidents, determining how to prevent them from recurring, and they become remediated incidents.

Mehul Kar says he’s not super excited about the “fediverse” in the context of social media. However, he sees a huge need for The Fediverse At Work. The issue? The lack of integration across all the tools we use at work has become incredibly tedious and hard to keep track of:

Sometimes there are Figma design specs, with their own set of comments. And Loom walkthroughs, also with comments and likes. And any number of other things over time. The combinatorial complexity of these tools across these platforms (not to mention emails) can be quite messy to track. It’s really hard to remember where a conversation took place. Coworkers often repeat the same text in multiple places, prefixing with phrases like “Shared this in Notion comment also, but…” or “Just left a review, but high level: …”.

He believes that a decentralized platform for all these tools to effectively talk to each other would be hugely beneficial:

Maybe the protocols that make up the Fediverse can help. What if, instead of sharing a Github Pull Request URL in Slack, your Slack team channel could instead be subscribed to the Github repository. Maybe new Pull Requests are broadcasted to followers, and replies from Slack users to those posts are sent as comments to the Pull Request in addition to being threaded in Slack. Maybe the Notion document is treated the same way. Maybe the Loom walk through is a reply to a Slack thread, and comments on the video appear in Slack. Maybe the Slack thread is a series of comments displayed on a Figma design.

There are more examples in his post. I really hope we can get to this type of philosophy for our work tools. It does sound a little bit like the problem that Luro is trying to solve.

Kathy Korevec started a series about her principles for building software/tools for developers. Since I work on Postmark—one such tool—I read the intro post with great interest. The second installment is on the principle she calls You are a chef cooking for chefs:

Developers are masters of building applications, so when you’re building tools and experiences for them, you’re cooking in their kitchen. You can marvel at the delight you bring to the experience because no one can appreciate your hard work more than another developer. Developers can spot inconsistencies, antipatterns, and hurdles a mile away, so you must pay close attention to these details. At the same time, they know the challenges, understand the concerns, appreciate the details, and can provide crucial feedback to make your product even better.

This is one of the main reasons why I love working on developer tools. It’s an audience that can be brutal critics. But for the most part they do that because they care and want to see the product succeed—not because they want to fight just for the sake of it. And because they care, feedback generally have a degree of specificity that is invaluable for troubleshooting, use case discovery, and improving the product.

Anyway, this looks like a fantastic series and I can’t wait to read the rest. You can sign up for Kathy’s newsletter here.

Marco Rogers has been an engineer and manager of engineers for 20 years. In this post he shares some short, practical (but not always easy to follow!) advice for engineers. A few of my favorites:

• Learn what the true scope of the project needs to be. Back away from “story points” and understand what the project needs to accomplish. More context about the goals will help you negotiate what’s in and what’s out of scope.
• Collaborate on designs. Designs never have the level of detail that matters. When you run into UX problems, work with people to develop a solution. Don’t just ask for more mocks. Own the details of what you’re building.
• Don’t just write code. Solve problems. Make sure you understand the value of your work and you talk to people about that. Not just “features”. For example, “this needs to ship by Fall because it’s our big strategic bet for the year.” Tell people how to achieve the strategic goal.

Read the rest of his post for the others.