Category Archives: Work

What gets consumed easily gets measured

What gets consumed easily gets measured, and what gets measured gets managed.

What gets managed, gets measured.

What gets consumed easily sometimes doesn't really mean much at all in the big picture but now it's the thing that gets measured, so you measure it.

And it gets managed.

Now there's a clear deviation between reality and the measurements, but what gets managed gets measured.

What gets measured gets gamed.

What gets gamed gets internalized in the unwritten tribal rules and regulations that exist somewhere just outside of what gets measured or managed, but what happens in Work Club stays in Work Club.

If this is your first time at Work Club, you have to perform as if you are working.


Meanwhile, we observe with straight faces as that which gets easily consumed gets measured, and what gets measured gets embedded in a PowerPoint slide, and it's basically law at this point.

What gets embedded in a PowerPoint slide is inviolable, you are committing a thought crime right now if you think otherwise.

Thought crimes will be recorded in your permanent record and you will be questioned very sternly and publicly as a warning to all those who might be likewise inclined, and let's not even talk about your performance rating.

Meanwhile, in one teleconference or another, maybe all of them, it's hard to keep up, the measurements are pouring in and the managements are pouring out.

It's really beautiful if you look at it from the right angle—like a great migration across some distant savanna, like salmon splashing up a river to spawn.

I didn't get a "harrumph" out of that guy.

We have to protect our phony baloney jobs.

What gets managed easily, gets measured.

What gets measured, gets consumed.

What gets consumed, gets excreted.

What gets excreted, gets consumed.

What gets measured, gets the whip.

What gets measured is the whip.

I am Jack's smirking metrics.


Inflexible afternoons

Trailhead: Seth Godin. "The most important meal of the day". Seth's Blog (2021-03-04).

Sort of like yesterday, Seth wrote something I was also thinking about today. In short: it's better to think about how a work day works—how your work day works—in order to have a better work day. Otherwise it's just a casual hell of unplanned reactions performed at inopportune times.

I've been trying to figure out ways to plan my day for years, with marginal results. I'm not surprised by it. Planning is often too brittle—do this during this half hour, do that during that hour—and reality shatters the plan into pieces. So planning has to be flexible to work. But I think flexibility is typically only concerned about the shape and size and number of tasks. That's only an aspect of work.

I like mornings. Early mornings are nice because they're clean and free. I can choose the number and intensity of external interruptions, for the most part. (Don't open email. Keep IM off. Et cetera.) And I am fairly well tuned to work then.

The other extreme: afternoons are trash. Wickedly hard to concentrate. Energy low.

"Datura flakes off from your lips
You've lost the swagger in your hips
Your eyes are turning blue to gray
Your skin feels soft and sagging down
Your arms drag across the ground
With each step you take"

—Murder By Death. "Killbot 2000". Who Will Survive and What Will Be Left of Them? (2003)

Coffee can slow the descent somewhat. What really seems to work best is going out for a run. It doesn't seem to give more energy as much as it... drains away the low energy. Then it fills back up again, and the time afterward is more full.

Some projects, during this eternal work-from-home, can be aligned to accommodate that. Others are fixed. To some extent, I can plan my day at work. In a typical week, the time breaks down into categories like meetings, work, figuring out what the work is, reactive communication, and thoughtful communication. Most meetings are fixed, and reactive communications—responding to some thing now—are fixed (but to variable times). Work—the actual doing of things—isn't fixed, but it does have to end by some time to get submitted. Figuring out what the work is and communicating are nice places to visit when I can.

The result is often a grind through the afternoon, then a run later. So I'm pumped and ready to go to make dinner.

(Dinner is the most important meal of the day.)

One on one

1-on-1 meetings are not my strength. For me, it's a direct relationship: the larger the crowd, the easier it is. 1-on-1 is the smallest, and worst, end of that equation.

It's so easy to take the measure of a crowd—what they respond to (good or bad), what kind of questions they ask, which songs they seem to like the most, whether they laugh or not, what bores them, etc. It's not a conscious thing for me. It's almost like hypnotism. I can feel—which I know means see and hear—when people in the crowd lean in, when the line goes taut and it's time to pull, when the line goes limp and it's time to cast again. It's difficult and I get nervous, but it's so much fun, and it doesn't feel like effort in the breach.

1-on-1 meetings are like a sandwich with extra stress hormones. Everything that makes speaking to a crowd easy—the collective hum, the collective silence, the collective movement—has been reduced to one input. I can imagine that this should be easy, but it's not—and moreover, because I expect that it should be easy and it's not, then there's the added panicfrustration caused by not being able to figure it out.

Mind you—I think they're a good format, and quite helpful, and I don't avoid them. (I have no employees that report to me, so it would be a matter of avoiding The Boss.) But. They're not easy. That's all about formal 1-on-1 meetings. Informal 1-on-1 meetings are also not that easy.

I know the solution. It's horrifying. And not surprising. The solution is to do it more often.

I'm also wondering about who does it best. Where do the best 1-on-1 meetings happen? (And what is "best"?) The context I'm thinking of is business, between the manager and the employee. But other fields seem like they might hold some keys to doing it well: doctors, salespeople, journalists, diplomats, 911 operators. There might be a vein to mine for approaches.

Some articles I found in the meantime:

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.

Automate and win

Today at work I gave a presentation to our division-wide systems engineering group at work about the why and how of automating some regular tasks that we do in our every day jobs. Over the past two years I had written some code (DXL, Python, VBA, etc.) to make some of the horribly boring and periodic work I do get itself done so I could work on other things I'd prefer to do. So many systems engineers turn into button-pushers and process jockeys. So many know the process but forgot all about the content. I don't want to be like that. Train some software to do the work, and you know the process and how to write software. Win-win.

It took a few years to learn how to code, and now I can use it. It was a painful—a terribly jarring experience for my ego. Kind of like getting out of shape physically. And like getting out of shape it's not hard to get back into shape. You just have to do it. Any idiot can do it—sometimes my life feels like an living testament to the ability of idiots to do things—but it takes time to do it. Unlike getting in shape, it's not clear where to get started. It's pretty clear how to run, but code? Where do you do that?

Anyway, the larger point is that it's not just that I don't want to be like a zombie, I don't want others to be like that either. At Big Corporation, when you start carrying that flag your life is a strange mix of being disliked by your manager (I got a below-average score on my performance evaluation for writing the automation code that saved the project and company money because it wasn't value-added to the project) and getting affirmative feedback from your peers (who know better than to rock the boat, but want the boat to be rocked a little).

I had some fun with the presentation. I can't post the whole thing here because it has some internal info, but I would like to share one slide that might be my masterpiece:

Look at that beautiful transition, from the depths of Lumbergh to the heights of what would you do if you had a million dollars.

And then there was this beautiful transition (you'll just have to imagine that the first three pictures were after a statement of the problem, and the fourth after the statement of the solution).

So it's a fine line between being clever and making a point. I've always tried, in these Big Corporate settings, to catch people a little off guard. There's a kind of protocol: stodgy, predictable, don't make me think too hard just give me some bullet points. Instead I'd like to kick in the door and let them know: there's a different way to do things. I'd like that to be my niche. I don't think one presentation establishes that, but I hope I planted a seed.