I suppose it it tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

—Abraham Maslow, The Psychology of Science: A Reconnaissance (1966)

This is a common quote, sure—"To a person with a hammer, everything looks like a nail". While reading Michael Watkins, The First 90 Days: Critical Success Strategies for Leaders at All Levels (notes), there was a reference to this line by Abraham Maslow, which is, according to the author, the original.

A week in review, 2018-W46



  • Oliver Burkeman, Why do we feel so busy? It’s all our hidden ‘shadow work’, The Guardian (2018-10-12) Automation was always supposed to take care of the tedious jobs, so we could enjoy more leisure time. In reality, it’s taken paid work away from humans, while also increasing their burden of shadow work, by transferring tasks from employees to consumers.
  • Sarah Baird, This Appalachian Nonprofit Puts Books In The Hands Of Inmates Who Need Them, Buzzfeed News (2018-11-12) "Part of what happens is that the letters themselves are so personal and idiosyncratic that they do a lot of the work undoing the [prison] stigma," Ryan says. "Any stereotype you might have will be eroded by reading the letters, particularly when drawing a beautiful rose on the envelope doesn't really fit with what you might think about a person in prison."
  • Janelle Walker, An Elgin home's odd addition, with a roof that opened to the sky, is found to be a Jewish sukkah, Elgin Courier-News (2018-11-14) "For me, it is more fun to restore it and find tenants that appreciate" living in a home with architectural and historic details, he said. For Savel, seeing the restoration work he and partner John Anderson have been able to do is the reward—as well as honoring a part of Elgin's history.
  • Ryan North, I’m a Computer Scientist. Here’s Why You Should Never Trust a Computer. Medium (2018-11-01) The real vote, the real power, still lies in the paper ballot. Without that paper trail, you're left trusting the computer. And nobody should ever trust a computer.
  • Richard Feynman, There's Plenty of Room at the Bottom, Engineering and Science 23:5 (1960-02) Now, the name of this talk is "There is Plenty of Room at the Bottom"—not just "There is Room at the Bottom." What I have demonstrated is that there is room—that you can decrease the size of things in a practical way. I now want to show that there is plenty of room.


  • ep. 8 | that brunch in the forest, Smithsonian Sidedoor (2018-11-14) Native Americans had held celebrations and dances around a harvest long before 1621. And Europeans in America had church-style services to give thanks since the 1500s. So how did Thanksgiving become the holiday about the brunch in the forest?
  • S 3 E 7 This Is Marketing, Akimbo: A Podcast from Seth Godin (2018-11-14) So it's tempting, in the old model of marketing, of average stuff for average people, to get rid of the tension, to make it super easy. But in fact, that's not going to help you. That we have to embrace the tension, and in fact cause the tension, because that's what we're doing when we show up and offering to make change. We're inflicting tension on the people we seek to serve. And the tension is, "Where you are now is fine, but where I will take you, where we will go together, is better. And the only way to you to better is to get you to leave fine behind."
  • Episode 876: Patent Deception, Planet Money (2018-11-14)
  • 410 – AJ Jacobs: Ten Superpowers of 'Extreme Gratitude', The James Altucher Show (2018-11-15) "The barista told me people just use her as a vending machine when they get their morning cup of coffee. Nobody looks her in the eyes."


Spotlight (2015)


Our reward for complaining about the heat all year...


The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration

Catherine D. Cramton, The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration, Organization Science 12 (2001-06). (pdf) (notes)

This paper was very interesting, especially since I just spent the year working on a team that was split mostly into two locations (St. Louis vs. Oklahoma City), with a few other players in other cities around the country. That's why I sought it out after seeing it as a cited paper in N. Sharon Hill and Kathryn M. Bartol, Five Ways to Improve Communication in Virtual Teams, MIT Sloan Management Review (Fall 2018) (notes). It's difficult to work on distributed teams and get it right, so I wanted some advice.

I've grabbed lots of notes, quotes, and references here.

Five problems to achieving a state of mutual knowledge were identified:

  1. failure to communicate and retain contextual information
  2. unevenly distributed information
  3. difficulty communicating and understanding the salience of information
  4. differences in speed of access to information
  5. difficulty interpreting the meaning of silence

(2) and (4) are obvious enough. Skip.

Point (5)—misunderstanding silence on the other end of the line—was the most surprising, and perhaps the most interesting. I made some notes about it here: Interpreting silence. It's really obvious—once you're aware of it. Think of any time you've been ghosted for any reason, deserved or not. It hurts. I've been trying to be conscious about it.

An interesting point was raised about (1), the "failure to communicate and retain contextual information". A reference was made to information sampling (Garold Stasser and William Titus, Pooling of unshared information in group decision making: Biased information sampling during discussion, Journal of Personality and Social Psychology 48:6 (1985)). The quick idea is this: when people want to talk about something, they sample from the information that they know. If more people in a group have the same piece of information, it is more likely that it will be mentioned, which leads to more people knowing the shared information. Esoteric information is less likely to be shared, and fewer people will know it. If a team is split up into separate parts, information is less likely to be sampled and shared across partitions because much of the communication happens locally, so different teams will be holding a different pool of knowledge—and that means that they'll be working in different contexts as they try to solve the group's tasks.

So you need a Single Source of Truth even more with a distributed team. Imagine what kind of abuse I get when I suggest that teams should have an internal blog. But they should. Individual knowledge and team knowledge need to be mixed together.

Finally, point (3): misunderstanding which information is important. Similar to (5), this is one I've clearly been getting wrong. An example given in the paper is how easy it is to misunderstand things written in emails. A sender might think one point given is obviously the most important thing; the receiver might think something else is the most important thing and not even see the important thing the sender wanted to communicate. The point needs to be clearly The Point, else frustration and bad decisions will soon follow. It's much worse when you're separated from the person you're trying to communicate with because all of the hand gestures and facial expressions and voice tone and so on that are also communicating information aren't there.

One more final note from the paper that raised a point that I often get wrong: attribution of blame. I get that it's not helpful to blame people directly, instead of the situation or result, but I make that slip often. There's even a field of study related to it—Attribution theory—so I guess I'm not the only offender. Anyway, from the paper:

When an error or conflict in information exchange is detected, people make attributions concerning its cause. [...] Personal attributions associate the cause of the communication conflict with some characteristic or behavior of an individual. [...] Attributions were judged to be constructive if they facilitated inquiry and change to reduce the incidence of communication conflicts in the future. Attributions were nonconstructive if they were task irrelevant or destructive to cooperation, inquiry, and adaptation. The researchers suggested that situational as opposed to personal attributions tend to produce better resolution of conflicts because they focus participants on modifying the "contracts that guide the communication process. If attributions are destructive, contracts concerning the communication process break down and people withdraw from cooperation.

If you work in distributed teams you should read the paper. It might keep your foot out of some of the traps that others have stepped in. (Now to find ways to pry my foot out of these traps that I just noticed...)

Aside. Interesting-looking rabbit hole discovered but not pursued: Several references are made to Herbert Clark, a psycholinguist at Stanford. Based on titles alone, I would check out the following if they ever line up with what I'm pursuing:

Mission engineering, digital engineering, and MBSE

I attended Bob Scheurer's INCOSE Midwest Gateway Chapter talk earlier this week: Mission Engineering, Digital Engineering, MBSE, and the Like: The One Underlying Essential Attribute. The presentation slides are available here.

Here are a few notes, along with links to the sources, of notes I took during the presentation...

Now, MBSE I understand. Not that I am an expert practitioner, but I understand what model based systems engineering is getting at. I've got one shoulder to the wall separating the usual set of text-based system requirements, trying to push it over into model-based requirements. Let the analyses and the tests do the talking, not just the words.

But: digital engineering and mission engineering were new to me. Sort of—rather their current names were new to me, which was part of the thrust of the presentation. Mission engineering is basically systems engineering at a really high level. It seems to be about designing missions, which would then be the driver for designing or acquiring systems to accomplish the mission. In other words, to repeat, it's just systems engineering. However, put another way: it's systems engineering using currently popular terminology, so maybe there's an angle to exploit there.

Digital engineering seems to be: how are you going to design your individual systems so that they can provide data to a central entity that integrates that data into some other purpose. What that strikes me as, although I am exceedingly ignorant about the details, is the interconnection of things on the web. Each of the individual servers attached to the web send and respond to HTTP requests. Many sites have defined application program interfaces (APIs) that set rules for how external entities can request and use their data via HTTP requests. Maybe big physical systems are coming around to that.

Anyway, the lingering thought is that it's difficult to tell the difference between mission engineering and digital twin and digital engineering and many other buzzwords that crop up from time to time. Maybe they're useful, maybe not—time will tell. In the meantime, systems engineer have to treat them like real things if we want to keep our heads above water.

Slouching into training shape, 3: slouching out of training shape

Slouching into training shape, 2

If there's one thing I've been lucky to not experience, it's athletic injuries, even while accumulating years and mileage. The left ankle that was sprained in fall of 2001 while playing ultimate is still larger than the right one. And I kicked a rock hidden under the leaves somewhere around mile 37 at the 2012 Ozark Trail Endurance Run, tweaking something deep in my calf muscle, eventually dropping out around mile 50 for my first and only DNF. Otherwise: nothing debilitating. Some IT band syndrome early in 2012 (not recommended—the worst, most-painful non-injury injury, just deeply weird to relieve knee pain by massaging your hip) that took a while to get rid of. But nothing else that I can recall. Resilience isn't sexy, but so what? I'll take it.

What is the difference between resilience and luck? I don't know. Injuries can be bad luck (hidden under the leaves). Injuries can be earned through stupidity. But what's the path that leads to not-injury? Of course that's a nonsense question. It's like asking how I roll so many 4s while playing craps.

What happens is this: something hurts. OK, no big deal when you're Muy Hombre. Just a pain in the right calf, somewhere down low, somewhere you'd expect an occasional pain because you run with the zero-drop thin-rubber shoes. And you think: I've had worse. It doesn't necessarily affect the run itself, it just hurts in the morning. Then it hurts after the run. Then it hurts during the run. Then a two-mile run involves some walking. And there you are.

This is a hard lesson. I tried taking two days off, to no avail. I got tired of limping around the house, around the office, etc. This time I'm taking a week off.

The horror! The horror!

It's hard to take time off something that has, for good or for ill, become entwined with your own self-definition. But it's a long game, right? This is something we're trained to understand as systems engineers: sub-optimize the component to optimize the system that it's a part of. Take a week off, lose a little bit of (planned) training, in order to do better over the long term.

Those words are all very sensible to send out to the rest of the world, but internally it's just... chomping on the bit to get moving... want to push it, but...

It's like that out in the Real World, too, eh? When you're going the same way you've been going, dragging something (like your leg) behind you, losing ground, pushing anyway... sidelined... chomping on the bit to get moving...

I've taken a week off running now, but this week I discovered ("discovered") an exercise bike in the gym. It's a different set of muscles, and different kind of energy to make it ago, and—most importantly—it doesn't piss off the muscle or whatever that was causing the trouble. So that whole time there were options within the constraint, I had just always mentally filtered out the exercise equipment in the gym because it didn't match my vision of myself.

These past two weeks I've been studying web stuff I kind of knew, but didn't really know all that well—JavaScript, HTML, CSS, PHP, etc.mdash;for a project. I had written it off in the past as being something I couldn't understand beyond what I already knew. But I knew more than I thought, it turns out, and with what I've learned about software engineering in Python, R, etc., in the last two or three years, I can make all that stuff dance now. Eight years ago, when I got laid off, I had time time time to learn and do these things, but I didn't have focus or any vision for how it could be used or learned or whatever, and I just didn't understand how to bridge the gap between reading about something and making it exist in the real world. The information was all out there, but I didn't see it—at least not in the right way. But the situation had turned a little bit in these last two weeks, and I got to see it from a different angle, and it made sense. So that whole time there were options within the constraint.

I was going to start running again tomorrow, but I might not—I might mine that cycling vein for a while and see how it turns out. I was going to give up this web programming kick tomorrow, but I might not—I might mine all these ideas for implementing other ideas for a while and see how it turns out. I've got no plan for either thing, it's just fun to push it, get good enough to compete, lace 'em up, go, and let the race sort itself out.

Interpreting silence

I'm just finishing up this paper: Cramton, Catherine D. "The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration." Organization Science 12 (June 2001): 346-371 (pdf). It's worth posting all of the notes for it when I finish them. (Update 2018-11-17: all of the notes.) But there's this one passage that's been sticking in my head all day:

One of the biggest challenges team members faced was interpreting the meaning of their partners' silence. Over the course of the project, it became clear that silence had meant all of the following at one time or another: I agree. I strongly disagree. I am indifferent. I am out of town. I am having technical problems. I don't know how to address this sensitive issue. I am busy with other things. I did not notice your question. I did not realize that you wanted a response.

The context for that passage, and that paper, is investigating how a team of students distributed across continents completes a class project. But anyone who has worked on a team with some people here, some people there, and so on, would recognize it. I recognize that situation—but not until after it's pointed out. When it's pointed out in this way, and then I reflect on it, I always assume that other people who aren't in the same place that I am in interpret any silences that I give or leave, intentionally or unintentionally, in the same way that I do. I know what I mean, why don't they? Of course this is stupid on its face. How could they?

So the trick seems to be not just designing your explicit interactions with other people, but also the implicit ones—not just the things you say, but the spaces in between. My habit is to avoid extra emails where possible, but maybe it wouldn't hurt to spare some extra one to ask the question: are we understanding each other?

Eggnog 2018

It's the most wonderful time of the year.

This is my third batch of eggnog, and the motivation is still the same as the first time: make an alcohol drink with raw eggs and then age it for 30 days? Gotta try that.

It seemed a little crazy. That's exactly the sort of thing that people who would drink alcoholic milk would say to do. That's what Michael Ruhlman said to do. So did J. Kenji López-Alt. So I tried it, waited 30 days or so, and it worked. And I tried it again, waited 30 days or so and it worked—but we didn't drink it all and I ended up aging a jar and a half for about 13 months and it still worked.

Xiaoqi standing by to call 9-1-1 while I drink the 13-month batch

I used the original recipe without modifications, except for not using the full measure of sugar (I started with 2 cups of sugar, then scooped some out until I felt less disgusted about how much sugar there was):

  • 12 egg yolks [egg whites were used for steamed eggs]
  • ~2 cups granulated sugar
  • 1 liter bourbon [Maker's Mark this time]
  • 4 cups whole milk
  • 1 cup heavy cream
  • 3/4 cup brandy [E&J XO]
  • 1/2 cup Myers’s dark rum
  • pinch of kosher salt

There's not much to it:

  1. Beat the egg yolks and sugar together.
  2. Mix it up with everything else in a big bowl.
  3. Put it in jars. Put the jars in the refrigerator.
  4. Wait.
  5. Drink.

Can't waste the bit that didn't fit in the jar

Bonus: Here's a bunch of links to other people who tried it:

A week in review, 2018-W45



  • Anne Fisher, Don't Blow Your New Job: Managers are switching companies like never before, but a startling number don't last 18 months. Here's why. Fortune (1998-06-22). In the Manchester Partners survey, human resources people gave specific clues as to what kinds of questions are likely to help you identify the best fit; 76% urge you to find out what results will be expected of you in the first year, and 64% say you need to ask for a timetable spelling out what is supposed to happen when. You should also ask how potential higher-ups will measure your performance (62%). Finding out how often the people above you want progress reports and provide feedback (45%) also couldn't hurt.
  • Angie Herbers, Set Up to Fail: Bosses Create Problem Employees More Often Than You Think, ThinkAdvisor (2017-04-14). We all use job titles to communicate what each member of a firm is supposed to do and how that differs from other employees. [...] This creates confusion among management, other employees and the employee him- or herself about what job he or she is supposed to be doing.
  • Sarah Fenske, They Requested the St. Louis Police Budget. It Took 8 Months to Get It, Riverfront Times (2018-11-09). "We wanted to use this to say, 'Look at how you're spending money. Isn't there an alternative way?'" he says. "If we could get this information on time and get the real information, not just redactions, the people who elect the mayor and the aldermen could say, 'This is not how we want our government to be. This is not what we want to spend our money on.'"
  • Binyamin Appelbaum, Their Soybeans Piling Up, Farmers Hope Trade War Ends Before Beans Rot, The New York Times (2018-11-05).
  • Nick Gillespie, 'We Are as Gods and Might as Well Get Good at It', Reason (2018-11-04). "The main problem with fame, or any kind of success, is the insulation it packs around you," writes Brand near the end of The Last Whole Earth Catalog, explaining why he decided to stop at the publication's zenith of popularity and critical acclaim. "There's a difference between intention driving us on and mystery pulling us on. Mystery will always educate and correct. Intention can go off the end of its own limb."






An us-versus-them reader

I've been thinking recently about how to solve an us-versus-them problem with a team I was working on. Sometimes us-vs-them manifests itself as a fight against groups on the outside, but it also happens on the inside of teams, especially geographically separated or functionally separated teams. It's this second problem that I'm most interested in. Us-vs-them within a group is really us-vs-us. It's a stupid and pernicious problem, if you stop and think about it. But it's hard to stop and think about it when you're in the middle of it, when you get that amygdala activated and charge straight ahead at the enemy—straight ahead at ourselves.

All of those instances of "you" above should be replaced with "I". I'm not here to 'splain anyone about how they're wrong. I just wanted to compile a list of things to read to identify the problem, understand the problem, and most importantly improve the problem.

What is it?

Looking at us-vs-them like a scientist

Avoiding and fixing

After Startup Connection 2018

Here's the preview post, Startup Connection 2018, with more links and information about all of the startups.

I attended Startup Connection this week in downtown St. Louis. It's a big show-and-tell of local startups and organizations that support them. It's an interesting peek at St. Louis from an angle that isn't obvious—unless you know where to look. There are lots of interesting small companies, and people running them. It's not Boston. It's not San Francisco. And it won't be and it needn't be. It's St. Louis.

Some news coverage:

Here are my favorites from the show:

Equine Smartbit, LLC

Website: esbits.com

When I saw this company on the list, I knew I had to learn more. The product description sounded like a Fitbit for horses. How did it work? I had to know. Would it be like a big watch that fits around the horse's neck? No! It's a literal bit that fits in a horse's mouth, with embedded electronics. Of course. It measures heart rate, temperature, blood oxygen. There's a part of me that thought: like owning horses, it sounds a little indulgent. But after talking to the people running the booth, what they've created seems so obvious and useful.

esso skin care

Website: essoskincare.com

Listen. This company's products are not for me: "We formulate and sell essential, effective, and effortless skin care for women of color; African-American, Hispanic, Asian, African, Indian, Native-American, etc." I score a zero for all that. I don't do skin care; I'm not even effective. It doesn't matter. The best part for me was talking with the founder, Kathleen Cook, about how she started the company. I thought it was interesting how she mixed her background in chemistry and biology with a need she experienced to create something new. When I talked to her, she said she had recently talked to someone at Target that might be her first retail customer—fingers crossed, etc.


Website: wakava.com

Again, much of the fun is talking to the founder. Ola Adeboye brought the recipe for the drinks from home, Nigeria. I tried the lemongrass flavor—and I can recommend it. I don't think they're selling it in any retail outlets, but I think it's just a matter of time.

Just noticed: Wakava will be at Square's Pop-Up Emporium Fall 2018 at the Cortex Commons on 15 November 2018.


Website: vital.education

This one was a really interesting experience that I had never considered before. How do blind people see graphs? I wouldn't have been able to answer that before. But Vital's demonstration app (on a tablet) made sense: when I ran my finger over a sample bar graph, there was some vibration (haptic feedback) to let me know when my finger was on the bar, and a slightly different style of vibration when my finder was on a different bar. I'd never thought of that before—it made sense immediately after trying it. I took one of their flyers and gave it to a co-worker who has a blind son. I really hope this product makes it.

There were also a few old favorites that I saw in 2017 or 2016 that are back again, and seem to be doing good business. It's just a matter of time before they're too successful and won't be startups and participating in the expo anymore—what a nice problem to have, eh?

  • SensrTrx: taking sensor data from factory machines to improve uptime and productivity
  • Agrela: solar powered sensors, standing in fields, providing data about fields to farmers
  • Strayos: drones flying over mining sites, providing analytical data