Morgan Housel:

Reading is a chore if you insist on finishing every book you begin, because the majority of books are either a) adequately summarized in the introduction, b) not for you, or c) not for anyone.

Slogging through to the last page of these books – a habit likely formed early in school – can turn reading into the equivalent of a 10-hour work meeting where nothing gets done and everyone is bored. And once you see reading through that lens, your willingness to pick up another book wanes.

I’m taking inspiration from this and skimming more of my book pile.

Jason Cohen:

The trick—useful everywhere in life—is to estimate values using only orders-of-magnitude, a.k.a. powers-of-ten. No “low/high ranges,” no precision, not even any digits other than a 1 followed by a quantity of 0s.

It’s often necessary to roll out organisational changes in a business, e.g. new reporting structures, goal setting frameworks, or planning processes. Each change introduced requires time for people to adapt and normalise.

When businesses introduce a series of changes in quick succession, people deal with them like a swimmer facing a tight set of waves. As they adjust to the wake of one change, they are immediately destabilised by the onset of another.

This situation can make it difficult for people to build their capability and improve performance. Leaders spend most of their coaching effort on dealing with the impact of the changes rather than improving an individual’s performance.

If you find managers in your team are spending the majority of their time coaching people through change it’s likely a sign that you are trading off rolling out change over coaching performance.

I’ve journaled in various forms over the years ¹.

About ten years ago, I migrated my journaling to the Day One app.

I love how Day One is available on my Mac and my iPhone. I post text, photos, audio, links, or quotes as they pop into my head. I tag posts and even store posts into separately themed journals.

In the last six months, I’ve added reviewing my journal to my morning ritual.

Each morning, before I knock out the day’s Wordle, I review the posts “on this day” in Day One.

It’s been a delight.

On some days, I have posts dating back ten years. It’s like jumping into a time machine to a previous life. Reading back over challenges at work, holidays we’ve taken, or photos of my family always brings a smile to my dial.

Once a month, I choose a random tag and review the journal posts under that. It’s illuminating to see the evolution of my mood or feelings on a particular topic over time.

Regularly reviewing my posts has made writing posts feel more valuable too.

So yeah, journaling is like a tricked-out DeLorean.

Jacob Kaplan-Moss:

What’s a transition file?

It’s a document that you prepare for whoever ends up succeeding you in your role. It should contain all the information you’d want them to know to ensure as smooth a transition as possible. Done right, the document should help them step into your role with a minimum of disruption.

Cam Daigle:

I’m hoping this system helps you have better meetings – that the people running the meeting feel like it’s worth their time to run them, and that the people in attendance feel like their presence there matters.

Tony Stubblebine:

Many things at Twitter were broken to the point that they could bring the entire site to a halt. Greg’s strategy, now distorted through multiple retellings and my own foggy memory, was to focus on short-term triage rather than long-term fixes.

Essentially, he realized that a collection of temporary, duct-taped fixes was the only thing that would give the Twitter team the breathing room to start working on longer-term fixes.

I think of this in school grade terms. Greg went looking for all the Fs and then turned them into Ds. Then he turned all the Ds into Cs and then all the Cs into Bs, etc.

Suggestions for how to make meetings worthwhile.

Ben Adam:

Amazon effectively operates like a federation of smaller companies. There are (extremely) large organizations, which break into divisions, and then into small, functionally independent teams.

A look at some manager onboarding processes.

Kevin Fishner:

At HashiCorp, we’ve grown from a few hundred to over a thousand people, so the goal is to build scalable systems that enable employees to do their best work and contribute to the outcomes of the company. For us, that’s shaped up into three specific systems: strategic planning, knowledge management, and communications.”

They also run a simluation to give their leaders a chance to practice.

“Using a firm called BTS, we run a business simulation where leaders get to ‘run’ the business for three years. Taking a simplified view of the company, we essentially build a game board based on our five-year financial model and this year’s three executive focus areas,” says Fishner.

Avishai Ish-Shalom:

To sum up: Variance is the enemy of performance and the source of much of the latency we encounter when using software.

To keep latency to a minimum:

• As a rule of thumb, target utilization below 75%,
• Steer slower workloads to paths with lower utilization,
• Limit variance as much as possible when utilization is high,
• Implement backpressure in systems where it is not built-in,
• Use throttling and load shedding to reduce pressure on downstream queues.

Coda Hale:

Most explanations of organizational success or failure are crap.

…

an organization doing work is just an incredibly complex, dynamic, distributed, parallel process.

…

As with writing highly-concurrent applications, building high-performing organizations requires a careful and continuous search for shared resources, and developing explicit strategies for mitigating their impact on performance.

…

The only scalable strategy for containing coherence costs is to limit the number of people an individual needs to talk to in order to do their job to a constant factor.

There are so many quotable sections in this piece.

Go and have a read if you think about organisations, how they work, and how to improve them.

Kelly Sutton:

A Campaign is a long-running effort to enact global change safely within a sociotechnical system.

…

Campaigns work well to address:

• Technical changes with large social components.
• Technical changes that require everyone to do a little bit of work.
• High-value or inevitable future worlds

Esther Derby:

Clarity enables patterns of coherent action across the organization. Contextual understanding supports initiative–people don’t have to wait to be told what to do. It speeds Decision Making as people closer to the work have the information to make more decisions in a reasonable way. Clarity reduces the need for supervision.

…

Smoothing the flow of work, organizing work and teams to reduce dependencies and handoffs, is management work.

Malte Ubl:

As software engineers our job is not to produce code per se, but rather to solve problems. Unstructured text, like in the form of a design doc, may be the better tool for solving problems early in a project lifecycle, as it may be more concise and easier to comprehend, and communicates the problems and solutions at a higher level than code.

Rands:

Process is documented culture. How a team gets a familiar thing done should be broadly understood by the team. This is how we fix a bug. This is how we do a code check-in. This is how a feature is designed. This is how executive sign-off occurs.

Process comfortably and efficiently describes the common path. Process does not define what to do when the indescribable occurs. A crisis or a disaster does not neatly fit into the common path; it’s when you need someone to swoop in, break the glass, and put out the fire.

Complex systems, cascades (from neurons up to people and then crowds), failures, too much efficiency, not enough slack, and toilet paper.

Dan North on how to break the rules when applying the Theory of Constraints.

Gergely Orosz:

Estimates matter because most people and businesses are date-driven.

Estimation is difficult but developing it as a skill is helpful for delivering software.

Roman Imankulov:

Rough consensus relies on the distinction between two types of objections:

1. “Not the best choice” feedback: “I don’t believe Solution A is the best choice, because XYZ. I believe Solution B would be better, but I accept that Solution A can work too.”

2. Fundamental flaws: “I believe Solution A is unacceptable because XYZ.”

…

A chair who asks, “Is everyone OK with choice A?” is going to get objections. But a chair who asks, “Can anyone not live with choice A?” is more likely to only hear from folks who think that choice A is impossible to engineer given some constraints. The objector might convince the rest of the group that the objections are valid and the working group might choose a different path.

Peter Coy:

The purpose of quadratic voting is to determine “whether the intense preferences of the minority outweigh the weak preferences of the majority,”

This is something I’d like to try in planning meetings.

We’ve repurposed the idea of a technology tree, popular in many strategy video games, and used that as a vehicle to communicate the Up product roadmap.

It’s effective.

David Gasca:

“Silent Meetings” are meetings where most of the time is spent working and not talking. When done correctly most of the meeting is spent silently working together.

Matt Linderman:

Instead of working with a thing you love, think about how to work in a way you love.

This is totally my bag.

John D. Cook:

The rule of three gives a quick and dirty way to estimate these kinds of probabilities. It says that if you’ve tested N cases and haven’t found what you’re looking for, a reasonable estimate is that the probability is less than 3/N. So in our proofreading example, if you haven’t found any typos in 20 pages, you could estimate that the probability of a page having a typo is less than 15%.

An improvisational approach.

Looks like a useful visualisation for projects.

John Allspaw:

In my experience, when an architecture review brings attention to a problem and proposed solutions from multiple perspectives, decisions become less controversial. When a decision appears to be obvious to a broad group (“Question: should we (or should we not) take backups of critical databases? Decision: Yes.”) how a decision gets made almost disappears.

Dan North:

Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.

Jesper Andersen:

In any kind of process planning in a factory, people know the price of running the plant at 100% utilisation: it gets sensitive to small errors. So nobody does that.

Nice QA checklist for launching a website.

A collection of information about the PagerDuty incident response process. Not only how to prepare new employees for on-call responsibilities, but also how to handle major incidents, both in preparation and after-work.

Envato teams are responsible for the operation of the systems they build.

My team is trying something different to help onboard new people. We’re creating a set of infrastructure koans for them to complete. The koans are tasks that—once completed—will help folks navigate our infrastructure and systems, and thereby acquire skills that are essential for supporting our services.

When someone joins the team a new issue is created in one of our team’s Github repos using the koans document as a template. Once the new team member has completed all of the koans they are added to the on-call rota and assigned a buddy who can help if things get tricky whilst on call.

The koans are not meant to be layed out step by step unless the task is complex or requires unusual knowledge. We hope this encourages folks to explore and internalise more than they would if following a todo list.

Some Example Koans

Set yourself up on PagerDuty and read through past incidents.

View metrics for each of our systems in New Relic.

• What is the average response time?
• What does CPU, Memory, and I/O utilisation look like on each server?
• What are the slowest transactions for the service? Dig into each transaction and see where the time is spent.
• Check the error analytics tab and look for any relationships between errors and past deployments.
• Check the availability and capacity reports.
• Look for trends in the web transactions and database reports.

Look up each of our services in Rollbar.

• What are the two most common errors being reported?
• Drill into the details of a recorded error.
• Are these errors we can live with? Should we create a task to fix them?

Open the AWS CloudWatch console.

• Look through the available dashboards and metrics.
• What CloudWatch alerts do we have configured for our production systems?

Open the AWS ECS console.

• How many task definitions do we have? How many available versions exist for each of them?
• Which systems make up each of our service clusters?
• How many repositories do we have in ECR?

Look through our Stackmaster templates and find the results of building stacks from them in CloudFormation.

Access our ELK cluster and run some queries.

Run queries against our production database replicas.

Decrypt some database backups.

SSH into various servers in our infrastructure.