I loved the story of the honking Waymos when it came out, and I’m glad it got the classic “but what does it all mean!?” treatment from The Atlantic:

Watching the Waymos circle the lot under the cover of darkness—and occasionally getting stuck in an endless loop—scratches a childish itch, akin to the fantasy of watching one’s toys come alive at night. In one video, the cars, bathed in taillight red and trying to exit, give off an aggressive vibe. In others, they seem clumsy. What do robots do when we can’t see them? Tung’s webcam answers the question. The stream makes it easy to spin up fictionalized, anthropomorphized yarns about the cars, because it feels like we’ve caught them in a private moment.

This whole story reminds me of scene from I, Robot where Will Smith’s character discovers a bunch of decommissioned robots in a junkyard just… standing around doing nothing. Well, until they don’t… But no spoilers.

I am a big believer in “moving at the speed of trust” with teams. You cannot shortcut the work to build strong relationships—and I’m afraid there is no roadmap or deadline for that. Sometimes it’s easy, sometimes it takes longer. But don’t skip this work. Move at the speed of trust.

Ben Kuhn shares some good tips around this in Trust as a bottleneck to growing teams quickly. I particularly like these two:

• Overcommunicate status. This helps in two ways: first, it gives stakeholders more confidence that if something goes off the rails they’ll know quickly. And second, it gives them more data and helps them build a higher-fidelity model of how you operate.
• Proactively own up when something isn’t going well. Arguably a special case of overcommunicating, but one that’s especially important to get right: if you can be relied on to ask for help when you need it, it’s a lot less risky for people to “try you out” on stuff at the edge of what they trust you on.

And speaking of communication… Also see Arne Kittler’s Part 4: Clear Communication, part of a series on “Clarity for Product Managers”:

Lengthy texts dilute your message or even discourage your counterparts to deal with them in the first place. Focus on the main points you want to make and provide the context that’s necessary to understand them as quickly as possible. When asking for information or a decision, be clear about what’s unclear.

Lorin Hochstein shares a characteristically solid systems-thinking take in CrowdStrike: how did we get here?:

Systems reach the current state that they’re in because, in the past, people within the system made rational decisions based on the information they had at the time, and the constraints that they were operating under. The only way to understand how incidents happen is to try and reconstruct the path that the system took to get here, and that means trying to as best as you can to recreate the context that people were operating under when they made those decisions.

The “no root cause” concept is something I’ve been thinking about a lot as I’m working on a particularly complex project at work. Somehow we constantly forget that things usually are the way they are not because of a single “mistake”, but because of a the culmination of a bunch of legitimate reasons.

Systems get the way they are because of decisions made in good faith based on the data available at the time. And the worst thing you can do as a new person coming in to improve things is to hunt for a single “root cause” to fix. That’s just not how software (or people!) work. So take the time to understand Chesterson’s fence. Go ahead and draw boxes and arrows until no one disagrees any more about how the system works. And then figure out which parts can be improved, and in which order.

PS. Also see How Complex Systems Fail:

Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

I love this reflection about personal resilience from Mandy Brown:

That is, we grow not only up—not only skyward—but down, into the roots, back to that from which we came and to which we will, one day, return. We become, in time, more rooted and resilient, more capable of surviving the storm, less easily shaken away from ourselves by idle wind or rain. When I think about growing down instead of up, I think about becoming centered, about knowing what work is ours to do (and, critically, what work is not), about a slow, steady power rather than a rash and inconstant one. After all, as anyone who’s ever lived among city trees can tell you, neither brick nor concrete nor iron can stop a root as it seeks out water. We should be as steady in our search for that which nurtures our own lives.

Charity Majors makes some really interesting points about the consequences of “replacing” junior engineers with AI:

By not hiring and training up junior engineers, we are cannibalizing our own future. We need to stop doing that. People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.

Also:

To state the supremely obvious: giving code review feedback to a junior engineer is not like editing generated code. Your effort is worth more when it is invested into someone else’s apprenticeship. It’s an opportunity to pass on the lessons you’ve learned in your own career. Even just the act of framing your feedback to explain and convey your message forces you to think through the problem in a more rigorous way, and has a way of helping you understand the material more deeply. And adding a junior engineer to your team will immediately change team dynamics. It creates an environment where asking questions is normalized and encouraged, where teaching as well as learning is a constant.

Lots more in the full article, it’s well worth a full read.

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.’