Inside the Globus INK: a mechanical navigation computer for Soviet spaceflight. Dang this thing is beautiful. And what an amazing piece of engineering.

Youth Spies and Curious Elders. Life goals: “Waters is what I call a Curious Elder — someone who manages to retain their curiosity as they age and stays interested in what young people are up to. The curious elder isn’t interested in judging youth, they’re interested in learning from them.”

The Thoughts of a Spiderweb. This is a fascinating article about animal cognition but I am especially blown away by the idea of spiderwebs being “an extension of the spider’s cognitive system” because I’m reading the sci-fi novel Children of Time right now and that is how the spiders communicate in the story.

Audi’s new EV is a luxury SUV with augmented reality that doubles as a pickup. I can’t decide if I love this or hate it.

Prisoners Usually Can’t Have Cell Phones. See How People Use Them Anyway. “Some men use their phones to take online classes, posing as regular students in the free-world, a ruse that only works in the age of Zoom classrooms and online meetings.”

It’s the Coolest Rock Show in Ann Arbor. And Almost Everyone There Is Over 65. “The show always starts at 6:30 p.m. and ends at 9 p.m., in time to get to bed at a reasonable hour.” Sign me up! (NYT Gift Link)

How ‘The Last of Us’ changed gaming, strained relationships and spawned an empire. Probably my favorite read of the week. “‘The Last of Us’ always felt like a mission statement, a game that wanted to prove that big-budget action shooters could not only have a sense of gravitas but could advance the medium in narrative, gameplay and representation.”

In his article Engineering Maturity Model Mike Fisher shares how he thinks about the importance of different team capabilities when building software organizations. Despite how some maturity models—such as the Capability Maturity Model (CMM)—have been misused in the past, Mike encourages us to look past the process and focus on the principles. Here’s the important part:

[The layers] aren’t stages in that you’re never really finished with any of them but you do need to have the ones at the base stronger and more developed than the ones further up or else you are certain to run into problems. […]

While I do think of this kind of like a maturity model, they are not stages that one achieves and moves on from. These are areas that one must keep returning to and keep investing in, always from the bottom up. Getting over your skis and investing too much in the top, which is very tempting for startups, is fraught. Too many product development teams without continued investment in the infrastructure or deployment pipeline can slow everyone down, proving Brooks’s Law. The important task for Engineering leaders is to determine when and how much investment gets made into each of these layers.

To put it another way, if the base of your infrastructure and deployment pipeline is shaky, an increased focus on product development is eventually going to bring the whole house down. Click through to the article to see Mike’s full model.

Hot on the heels of yesterday’s post Meetings for an effective engineering organization, I bring you more meeting content! In You can’t just cancel 76,500 hours of meetings Becky Kane makes some good points about the context of meetings within an async culture:

Reducing meetings is just one piece of creating an async-first culture.

She gives some examples of other pieces that are harder but even more important in having a lasting impact on engagement and productivity:

• Decentralizing decision-making so people don’t have to wait for permission and deliberation before acting
• Delineating clear areas of responsibility so people feel individual ownership to move work forward

You can read the post for the other examples, they’re all very good! As with most of these kinds of topics it’s really valuable to think about them not in isolation, but as a system. It’s not about whether meetings are good or bad, it’s about how meetings fit into the culture and system of planning and delivery that the organization operates in.

Becky’s illustration of what “async” really means is a perfect example of this:

It seems like the topic of meetings is on everyone’s minds again as we start the year. Will Larson has some good perspective from the engineering org viewpoint:

Some engineers develop a strong point of view that meetings are a waste of their time. There’s good reason for that perspective, as many meetings are quite bad, but it’s also a bit myopic: meetings can also be an exceptionally valuable part of a well-run organization. If you’re getting feedback that any given meeting isn’t helpful, then iterate on it, and consider pausing it for the time being. It may not be useful for your organization yet, but don’t give up on the idea of meetings. Good meetings are the heartbeat for your organization.

He goes on to recommend six core meetings for every organization to start with. The “weekly team meeting” is one I’ve become a fan of as well. Getting the entire team on a call every week has the potential for being a giant time-waster, so getting the purpose right and facilitating it tightly is essential here. For us, the purpose is:

• See each other’s faces at least once a week. I wasn’t sure if the team would feel like this goal is a waste of time, but it absolutely is not. Since we’re all remote, “let’s just chat for a bit” is such a great way to start the week.
• Discuss blockers/issues. This is not a status meeting where everyone goes around the room and tells us where they’re at. We have an agenda in Google Docs that anyone can add to. The goal is to bring up any issues that the team is struggling with so that we can all figure out the best way to help.
• Company updates. This is also the opportunity for the leadership team to make sure the entire team has all the information and context they need to do their work effectively.

There’s one more thing about this that I highly recommend: every meeting is facilitated by a different team member. We have a schedule that we cycle through with a clear guide on what it means to facilitate—and of course, an option to opt out. This keeps the meetings interesting and everyone invested.

Previously, on meetings:

• When meetings are outlawed, only outlaws will hold meetings.
• Things they didn’t teach you about Software Engineering.

Good post by Vadim Kravcenko on Things they didn’t teach you about Software Engineering:

Although it may sound surprising, the primary focus of a software engineer’s job is not writing code but rather creating value through the use of software that was written. […] Elegant code, best practices, smart solutions, design patterns — these are done for the sake of your fellow software engineers who will work on the codebase after you rather than helping you fulfill the purpose of bringing value.

And speaking of meetings:

It’s all interconnected, and the meetings are where the information is shared. As a software engineer, you are responsible for some part of this information sharing, so it would be irresponsible to hinder it. You might not like it, but the information must be shared for the system to remain efficient.

Via Chris Coyier I found this great post by Karl Sutt on How to communicate effectively as a developer. I especially appreciate him pointing out the importance of communicating clearly in short-form writing like Slack messages. His example of “low-resolution” vs. “high-resolution” writing in that context is a useful reminder for all of us:

In both cases, the example on the left is what I call “low-resolution writing”. There is very little context, too much reliance on pronouns and unclear references. The writing is not emphatic—the reader has to spend extra energy to work out what is being said. The examples on the right, on the other hand, try to make the reader do less work, even though it is more effort for the writer. The writer clearly has thought about how the message will be read.

This idea is similar to what Erin Meyer refers to as “high-context” vs. “low-context” communication in her (excellent) book The Culture Map: Breaking Through the Invisible Boundaries of Global Business. She explains in this HBR article:

I compare cultures along the Communicating scale by measuring the degree to which they are high- or low-context, a metric developed by the American anthropologist Edward Hall. In low-context cultures, good communication is precise, simple, explicit, and clear. Messages are understood at face value. Repetition is appreciated for purposes of clarification, as is putting messages in writing. In high-context cultures, communication is sophisticated, nuanced, and layered. Messages are often implied but not plainly stated. Less is put in writing, more is left open to interpretation, and understanding may depend on reading between the lines.

Choosing the right communication style for the right context is an important skill for everyone, but especially product (and other) leaders. If we assume too much context is known, people will misinterpret what we mean with our words.

Brad Frost argues that design tools are holding us back because “they require a specific toolchain in order to function”. Instead, what we need is closer collaboration:

Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers should collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.

Ben Nadel proposes A Good Samaritan Law For Engineers At A Software As A Service (SaaS) Company:

How can we instill in our people the unwavering conviction that they have the freedom to create a better user experience?

One idea that popped into my head was to create a Good Samaritan Law For Engineers: an explicit promise by the company that no engineer will ever be fired for attempting to, in good faith, help a user or create a better user experience. And, I don’t mean as an implicit piece of the Tribal Knowledge; I mean as an explicit, codified part of the culture — an entry in the employee handbook — a poster, up on the wall, that any employee can look at and point to and use in their decision-making algorithm.

This should, of course, be true for everyone in an organization, not just engineers. But I like the point about codifying it — making it a principle that’s published, well-known, and ingrained in the company culture.

Megan Quinn’s post on Development Cadence starts off really strong:

The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders.

And then it only gets better from there. Her point about being “flexible on scope, fixed on time” is spot on:

One way to establish a good development cadence is to commit to a predictable launch schedule and avoid slipping by pushing out features, not time. Some organizations commit to launching every month with the notion of ticks (small feature releases/fixes) and tocks (bigger, marketable moments).