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):

• Christopher Edwards. Maybe it’s time to stop saying “under promise and over deliver”. Medium (2019-12-28).
• John Cutler. The Problem With Underpromise, Overdeliver. Pluralsight (2018-02-28).
• Jessica Stillman. Why 'Underpromise and Overdeliver' Is Terrible Advice. Inc. (2014-06-02).
• George Bradt. Why You Should Under Promise And Over Deliver -- But Not By Too Much. Forbes (2017-08-15).

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:

• Jeff Bezos' 1997 shareholder letter is still relevant. Axios (2017-04-13).
• Charlie Kindel. One-Way and Two-Way Doors. cek.log (2019-06-27).
• Eilon, Samuel. "What is a decision?" Management Control. Palgrave, London, 1971. 135-162.
• Go Fast and Break Things: The Difference Between Reversible and Irreversible Decisions. Farnam Street Blog (2018-04-23).
• Frey, Dieter. "Reversible and irreversible decisions: Preference for consonant information as a function of attractiveness of decision alternatives." Personality and Social Psychology Bulletin 7.4 (1981): 621-626.

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.

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.