Category Archives: Work

Review in thirds

Trailhead: Stefanie Flaxman. Catch More Writing Mistakes with This Underutilized Proofreading Trick. Copyblogger (2015-07-01). (courtesy of Filament's Monday Morning Meeting, 2021-01-25)

The second suggestion in that article is: proofread backwards. Start at the end, then work back towards the beginning. Her point is that when you see the words you wrote in a different order, it's easier to spot errors. The words look fresh—not like words that you've read a hundred times before.

(Coincidentally, in the background, I just got Rob Walker's The Art of Noticing #62, How To Get a New Perspective, and it mentions "the fog of familiarity".)

But there's one more point I would add to that: it's tiring to read and review things, and over time you run out of energy, focus, attention. At some point, if you haven't quit, you're just trying to scrape by to get to the end, doing a progressively worse job.

In engineering, we have reviews for a variety of documents that we make—requirement reviews, test reviews, flight reviews, etc. A requirement specification for a complex aerospace system can easily run past 100 pages. Few people have the stamina to give page 100 the same time and attention as page 1. I've seen some reviewers just make comments about the cover page of the spec and leave it at that. (Thanks?) I've seen requirements at the end of a spec that referred to the wrong program, meaning that whoever put the spec together themselves didn't make it to the end to clean up the requirements they copy/pasted from another spec, nor did the reviewers who approved the thing before it was sent to us. I understand—reading a spec is murderously boring.

There is an easy solution, and it's one of my best review hacks. When I run a spec review, I recruit volunteers—some will start at the one-thirds mark, and some will start at the two-thirds mark. Then I have some assurance that the middle and end of the spec get some scrutiny.

That's it. It's a really superficial hack. It's not as good as putting in the work to make reviews better, but it helps.

Alice's adventures in metricsland

I was looking for something else entirely when I ran into this sequence from Alice's Adventures in Wonderland:

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where—” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

“—so long as I get somewhere,” Alice added as an explanation.

“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

Since I was thinking about metrics at work around that time, the correlation seemed obvious to me. I think we've all been there if we have to get our work performance measured: the boss wants you measure something, measure anything, just bring a number or, better yet, a chart with the line pointing up and to the right.

Is that the thing you should be measuring? Is that value you're tracking meaningful? Helpful? Is it going to be gamed by your workers because they know that it's (a) neither meaningful nor helpful and (b) they get rewarded if it points up and to the right and punished if it doesn't? Oh, you bet it will. And, in a sense, it should. It's a Catch-22. Only insane people would behave as if an insane system is sane, whereas deviation is a sign of sanity.

A quip from Marilyn Strathern (the de facto version of Goodhart's Law): "When a measure becomes a target, it ceases to be a good measure."


Here's the part I was originally looking for because I think it's also project related:

“But I don’t want to go among mad people,” Alice remarked.

“Oh, you can’t help that,” said the Cat: “we’re all mad here. I’m mad. You’re mad.”

Consume and produce ratios

Taking off from an earlier post, Consume and produce cycles (2020-08-20)...

Here's another riff from Matt Mullenwegg's interview with Shane Parrish on The Knowledge Project that had me thinking. (The earlier one: Make more decisions.)

[49:44, Matt Mullenwegg] I think a lot about that efficiency of time... I think one downside of synchronous communication is it's kind of 1:1, so the time that it's taking to communicate the information is also what it takes to consume it. That's kind of inefficient. On the other end of the spectrum is maybe a book that someone took a lifetime to write, and it can take you a few hours to read. That's a multiple thousands-to-one ratio, so that's really dense and valuable. And then probably the worst is things that take people a short amount of time to create and you a long time to consume.

[51:06, Matt Mullenwegg] This is why we always want really good notes out of meetings. By the way, if every meeting is transparent and has really good notes or a recording, people don't feel the need to be there, and so the meeting can be smaller, which also means it's more effective. Where it's not everyone is like, I'm not in this meeting and I'll have no idea what happened and my voice won't be heard.

There is a general, casual tendency to just sling documents or meeting invitations out into the fray. I'm done—[heave]. Then the people on the other side of that interaction have to catch the thing being heaved and make sense of it. Or, just as likely—they don't, because they don't have to make sense of it, really. If someone throws a bag of crap at you, you're going to dodge it reflexively.

I don't think it's a mean-spirited tendency to do it like that. There's not enough thought put into crafting and writing in technical work. (See also: Good writing would make work so much better.) People can do the hard analytical work, and then it feels like the job is done—smash it all together and ship it. It's efficient (maybe) for the person sending, but when you add up the extra time it takes for each of the receivers to consume it, it's inefficient for the whole system.

Ratios matter. System effects matter. That ratio of consumption-to-production is important. Spending an extra five minutes to write an agenda for a meeting and to make the invitation clear can easily save more than that for the whole team in reading and comprehending the message, in having a useful meeting, etc. The trick is developing the taste to know how and the patience to think from the receiver's perspective.

Underpromise and overdeliver, or not

I'm transferring jobs at the end of the month, from a systems engineering to a project engineering role, so I've been doing another read-through of The First 90 Days (notes) by Michael Watkins, to get ready for the switch.

In Chapter 4, about negotiating what success is supposed to mean with your new boss, there is this nugget of advice: underpromise and overdeliver. I don't know about that. I can think of situations where that's a good approach, but none of them with a boss that I respect.

If I was dealing with a customer, underpromise/overdeliver makes sense. There are real consequences—not just to you, but your project or company or to the customer—to picking an early date, or the expected date without margin, as a target and then missing it. The date you pick for deliveries is part of a real negotiation, contracts and agreements and all. You're not manipulating anyone by picking the expected date, or a date later than that for margin. (Things only break when there is no margin available to fix them.) You're negotiating, and you're getting agreement from the people receiving the thing you ship. And if you can pull off an early date and delight your customer? Congrats.

But internally, instead of externally? Intentionally selling someone on your own team a date that you know is wrong, just so you can score a big win, doesn't feel right. It's better to be honest and explain the margin up front. Maybe this kind of business book is targeted to career climbers who don't care about that. I think that starting a relationship with a foundation of lies—which is what it is when you know better and say something else—isn't the way to go.

A future post, perhaps, because it's something I do occasionally: get better at your predictions by writing them down up front, and then grading them later. Consider improvement instead of manipulation.


A few other, similar voices (you can go read Tom Peters if you want to hear that overpromise/underdeliver is good):

Make more decisions

Reversible and irreversible decisions—depending on where you work, one or the other doesn't exist. Reversible decisions are forbidden because it assumes the possibility of being wrong, or people assume that nothing is irreversible.

Matt Mullenwegg talked about this in a recent podcast episode of The Knowledge Project (Matt Mullenwegg: Collaboration Is Key; notes):

[73:38, Shane Parrish] What are patterns of people that make really good decisions? What do you see in these people and how do they think about things in a way that is transferable to other people?

[73:48, Matt Mullenwegg] You know, one of the best advice I got really, which was from—early at Automattic I actually hired a CEO, I consider him like a co-founder, Tony Schneider, he's like my business soulmate—and one of the things he taught me early on was: make reversible decisions quickly and irreversible ones deliberately. And I still return to that on a weekly basis. If it's a reversible decision, we'll probably learn a lot more by doing it. I find it so funny, in software especially, let's just build the first version, and build it to throw away maybe. But let's get that prototype out there. We could debate it for weeks or months, or do a million mockups. I have this old essay, "1.0 is the Loneliest Number". The oxygen of usage is required for any idea to survive, and so you want to get to that first version as fast as possible, and that learning is really, really valuable to the speed of iteration. So I like smaller reversible that happen frequently quickly, and without being attached to them a lot.

(And later he references Farnam Street's post about decision journals, which is out of scope here, but worth a read.)

I've found that smart people who are willing to be publicly wrong with decisions are few and far between. It's uncomfortable to be wrong and publicly wrong. And it's uncomfortable to violate consistency, even in the service of making better decisions. But it's the right way to go. Sufficiently complex decisions are often intractable—you're lucky if you can figure out what all of the variables are, let alone their values, let alone how they interact with each other. So you've got to do something to get from zero to a solution.

Experiment... why do people often think that word means "let's just try something and see what happens", or "hold my beer I'm going to try and jump over it"? Thought and preparation goes into experimenting, or it's useless. If you work in physical space, experimenting is often expensive in time and money and the opportunity cost of having your staff and facilities do something else. (Another post for another day.)

In my experience, at work, most information systems and team processes aren't set up well for reversing decisions. Sure, we have The Process that (supposedly) defines how we are allowed to design things, and we have Configuration Management which defines how we can change things. ("Things", in these cases are often requirement specifications, test procedures, software, hardware drawings, etc.) But The Process is often odious, and Configuration Management is the nun at the front of the class in a Catholic school. They're not built to try things quickly, explore the frontiers, and then back up and go in a different direction if needed.

That's only partially true. We could move faster and try things if we wanted to. What limits us is the way that we manage our information. When you really, really get down to it, what is a decision? It's a definition made by people at a certain time. A decision controls something. A decision can be encoded in nouns and verbs, i.e., variables, or classes and methods. If we thought of all the decisions that we captured in prose as being algorithms, or nodes in a larger graph, we could know what affected what, and try something, check the result, then decide to keep it or dump it. It's probably not easy to set up, but the problem seems easy enough to understand.

Even if we didn't make any changes to the way we operate, it seems like we should be able to submit experiment proposals to change control boards the same way we submit problem reports and change proposals—ask for explicit permission to try x on subset y for t time, report back with results, then commit to continuing the experiment or reverting it or accepting it as a change on the whole set of things.

(Apologies for the abstractions. That's what it's like to talk about work outside of work sometimes.)

Instead, we plow ahead with extensive planning and review, then take a systematic approach to planning things. That's good and often goes well enough—better than just winging it—but you're limited to what you know ahead of time, and many of the lessons you learn through applying the plan are chalked up to "lessons learned" for a future program, which may or may not be used ever. That paradigm is best for irreversible decisions.


More links:

Emotional management

Trailhead: Jeffrey Sanchez-Burks, Christina Bradley, and Lindred Greer. "How Leaders Can Optimize Teams’ Emotional Landscapes". MIT Sloan Management Review (2021-01-04).

I think I would have normally skipped by an article like this—or any article with the word "emotional" in the title. After 2020—I'll allow it. I spent what turned out to be most of 2020 just... angry at... whatever there was to be angry about. Maybe it wasn't straight-up fury, maybe just the final barbed tip of constant frustration, but it wasn't very healthy for anyone.

The falling-apart side of 2020 was an awful lot like having too much to drink: it didn't change who I was, but it did amplify certain parts of myself in clownish ways. Prone to frustration about things moving too slowly, about being left out of decision-making forums during normal times? 2020 amplified it. I don't know how that worked for others. I can't imagine the circumstances made other people's emotional states better on average. I can't imagine that having to organize a group of people in amplified states would be an easy task.

Emotional management is just part of coaching in sports, and likely in other arenas, I assume. Emotional identification and emotional management. You can't yell at every player to pick up the pace—some people feed off of it, some people hate it. And the people who feed off of it only need it when it's the right time, not all the time, depending on the circumstance. And the collection of team emotions combine to create another thing. And the combination of the team emotions and the environment create another—the environment at home, the environment in the arena, the environment in the world.

Something the article pointed out that I didn't consider was not just the collection of team emotions, but their distribution. In what cases does it make sense for the team to have emotions that are aligned or dispersed? I would have guessed that "aligned" is always the desired goal, but that's not necessarily right. It makes sense now that I think about it. Getting everyone on the same page emotionally makes sense if you're trying to get them to aim at a definite goal (Totterdell, Peter. "Catching moods and hitting runs: Mood linkage and subjective performance in professional sport teams." Journal of applied psychology 85.6 (2000): 848.). But if the goal is to come up with creative new ideas, then having people in different states is a fertile ground for new ideas. (Emich, Kyle J., and Lynne C. Vincent. "Shifting focus: The influence of affective diversity on team creativity." Organizational Behavior and Human Decision Processes 156 (2020): 24-37.)

Something new to think about: not just understanding how to identify the team's emotions, but considering how to arrange them to achieve the goal.