I really don’t know how much more data we need about this. It’s almost as if RTO is not about productivity at all…

Bloom and Han reported last week in the journal Nature that, over the subsequent two years, hybrid workers showed no difference in performance grades or promotion prospects compared to office-bound colleagues; the company’s computer engineers, for example, did not differ in their coding output across the two groups.

Hybrid workers, however, reported higher job satisfaction and were less likely to quit, especially if they were non-managers, female, or had long commutes. The authors conclude that “a hybrid schedule with two days a week working from home does not damage performance”, adding the result would probably extend to other organisations.

Some solid points in this article from Jason Knight. On product-led vs. sales-led (but could also refer to engineering-led) organizations:

To be honest, my strong opinion is that if you have to worry about who’s “leading” anything, then you’ve got bigger problems to worry about than who’s leading. If your entire company is aligned around what’s important and how to get there, then anyone could “lead” you there. This is supposed to be a collaboration, not a dictatorship. If one team “leads” and others don’t agree with where they’re being led, fix that! I generally find that misalignment is one of the most important problems to solve in any struggling company.

Hard agree with that one. I don’t believe in “healthy tension” between product and engineering. Just like I shy away from the traditional hierarchical view of “bosses tell employees what to do”. Whether it’s Product and Engineering or Manager and Teammate… it’s about partnership and helping each other (and the company) grow. We have to reframe this idea that adversarial relationships somehow create better teams and products.

This is a fun bit of gaming history:

The thing about games, particularly Japanese games, is that they exist in a symbiotic relationship with manga and anime. When I spoke to Uemura-san, the engineer of the NES, he said ‘Once hardware developed to the point where you could actually draw characters, designers had to figure out what to make. Subconsciously they turned to things they’d absorbed from anime and manga. We were sort of blessed in the sense that foreigners hadn’t seen the things we were basing our ideas on.’

Emma Sarappo has a fascinating review of a new book about the Challenger space disaster (gift article). It is the first global disaster I was old enough to witness and experience in real time, and I’ve never been able to get those images out of my head. This review (and book) shines a horrifying light on the many human failures (mainly due to hubris) that resulted in this tragedy:

These issues—faulty O-rings, foam strikes—were understandable. Theoretically, with study and ingenuity, they were fixable. The problem was not really a lack of technical knowledge. Instead, human fallibility from top to bottom was at issue: a toxic combination of financial stress, managerial pressure, a growing tolerance for risk, and an unwillingness to cause disruption and slow down scheduled launches.

(Side note, tell me that last sentence doesn’t remind you of software development sometimes…)

Also, the astronauts knew what was happening:

The astronaut assisting them into place and finishing final preflight checks “looked down into her face and saw that her Girl Scout pluck had deserted her,” he writes. “In her eyes he saw neither excitement nor anticipation, but recognized only one emotion: terror.” She would fly for 73 seconds before the shuttle broke apart in a fireball and a cloud of smoke. After that gut-wrenching instant, and more seconds of stunned silence, a NASA public-affairs officer would speak the understatement that would become famous: “Obviously a major malfunction.”

I’ve been pretty bad at sharing what I’m reading over the past couple of weeks, so I wanted to do a quick roundup post of some articles I have found helpful recently. I keep wanting to write longer posts about each, but it’s just not happening due to time constraints, and I need to clear out that queue, so here goes!

Unexpected Anti-Patterns for Engineering Leaders

Insightful post by Will Larson with some great advice for all leaders, including a reminder that it’s not a good idea to extract yourself from the details completely:

New engineering managers are often advised to “step away from the code.” But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.

The Busy Trap: How to Distinguish Being Busy from Being Productive

This one deserves a thorough read, because it talks about maximizing throughput in systems—and it’s not about making sure everyone on the team is at 100% capacity:

The real bottleneck isn’t in doing the work but in the waiting—queues that turn days of development into weeks of delay. This insight shifts the focus from individual busyness to process efficiency and the smooth flow of work from start to finish. Our findings debunk the myths that more planning, parallel tasks, and pull requests guarantee better outcomes. Instead, they emphasize the need for streamlined processes and effective collaboration to enhance true productivity. Let’s prioritize making each moment count towards faster, more efficient delivery, moving beyond mere activity to meaningful progress.

How to Communicate When Trust Is Low (Without Digging Yourself Into A Deeper Hole)

Lots of things in this post that I found very relevant and helpful. I especially have a… well, “growth edge”… in this area:

To the best of your ability, try to resist reading layers of meaning into textual communication; keep it simple, overcommunicate intent, and ask for clarity. And if someone is asking you for clarity, help them do a better job for you.

And related…

You vs. the forgetting curve

My friend and former colleague Fio with another excellent newsletter edition about why we should be ok with having to repeat ourselves a lot:

And it’s not that other people forget because they are selfish or don’t care—it’s because we plonked a bit of information at the top of their forgetting curve […] Because the forgetting curve exists, being an effective communicator might well require us to share the same information multiple times, at the right intervals, across different channels, without ever assuming that our teams and stakeholders will magically remember everything after the first iteration.

Principles of Engineering Culture at Wealthfront

I love (most of) these principles, but especially this one:

We believe our organization is most healthy when engineers, not management, propose and drive platform improvements. New products and problems are often brought to engineering teams to solve, but then technical leadership of these teams interweave these priorities with necessary infrastructure as part of their platforms’ continued advancement in engineering quality. While it is the team’s job to propose and defend these improvements, it is then management’s job to internally align and clear the path for the improvements to happen. The alternative would be for management to command infrastructure projects that teams then find time to execute. Such management decrees are avoided as they lead to poor trade-offs and unhappy teams.

Clarity for Product Managers: Part 1, Directional Clarity

Great series by Arne Kittler. This quote stood out to me because I’ve been surprised at how many people I’m currently interviewing for roles on my team cannot succinctly describe what value PMs bring to an organization:

Imagine you meet your CFO in the elevator: How well can you briefly and convincingly tell them what you are doing and why, and what the company will gain from it?

The Moral Economy of the Shire

On the non-work side of things, I adore real-world critiques of fictional worlds, like this one:

The implication in both books and movies is that most Hobbits spent their time either farming or enjoying leisure time, but this makes little sense, when one considers what we know about premodern agriculture and what little of life and culture in the Shire.

We have to realize that Bilbo and Frodo were independently wealthy…

Bilbo and Frodo are both gentlemen of leisure because the Baggins family is independently wealthy, and that wealth almost has to come from land ownership, because there isn’t enough industry or trade to sustain it. They can afford to go on adventures and study Elven poetry because they draw their income from tenant farmers renting their land.

I’ve linked to and written about the importance of 1:1 meetings before, and here’s another reminder:

The long game of building a thriving team is in showing up for your people week after week, and intentionally holding that space. You will not always see the value in each 1:1 right away. Your people might need help, too, to understand how to use them effectively. But over the long run, the benefits of an engaged and thriving team are immense.

I’ve been guilty of this before, but I’m making a new commitment to myself and my teams. Even if you “don’t really have anything this week”, keep the meeting. It’s in the consistency of showing up that trust and relationships build.

As someone who is currently reading Slow Productivity and also watching Shōgun, I concur with this point from Austin Kleon:

During a recent phone call, my friend Matt Thomas told me he likes to take a high/low approach to balancing his input, which started when he was in grad school reading dense theoretical texts by day and chasing them with movies like Fast Five at night. I’ve currently got a good combo going: I’m reading Middlemarch and binge-watching Bridgerton. (As the poet Donald Hall wrote in Essays After Eighty, everybody who works with their brains all day needs to lighten up a bit at night: "Before Yeats went to sleep every night he read an American Western. When Eliot was done with poetry and editing, he read a mystery book.”)

You don’t say…

Before providing employees with solutions to manage their stress, Fleming recommends that employers do more to tackle the ways in which their business might be causing the stress. A Deloitte survey of US workers, in 2022, found three systemic factors had an “outsized impact” on wellbeing: leadership behaviour; job design; and organisational working practices. It prompted the researchers to conclude that “perks and programmes”, alone, achieve little.