Monthly Archives: March 2019

A week in review, 2019-W13

Wrote

None

Read

  1. Kashmir Hill, Life Without the Tech Giants, Gizmodo (2019-01-22). Amazon, Facebook, Google, Microsoft, and Apple collectively make products that we love, products that we hate (but can’t stop using), and products that dictate how we communicate and how we are seen. Their devices and services make our lives easier than they’ve ever been before, yet more complicated in unforeseen ways. They are so ubiquitous and fundamental to our lives that their offerings have replaced core functions of our brains. We’re now realizing it’s as possible to get addicted to these buttons, clicks, screens, and scrolls as it is to get hooked on nicotine or heroin.
  2. David Kilcullen, Counterinsurgency (2010). (notes) [p. 76] As in any other endeavor in counterinsurgency, the challenge for commanders and assessment staffs is to remain agile, seeking not to template previously useful metrics but to constantly develop and apply new indicators, based on a shared diagnosis of the nature of the conflict and what is driving it. These indicators must track developments in the four basic elements of the campaign: the local population, the host-nation government, the security forces, and the insurgents themselves. And they must be carefully interpreted, applying judgment and qualitative reasoning, rather than simply counted.
  3. Akshit Sangomla, International space experts don’t agree with PM Modi’s explanation on ASAT, Down To Earth (2019-03-29).
  4. Eli Chen, St. Louis startup MARSfarm works with students to build computers that grow food, St. Louis Public Radio (2019-03-27).
  5. M. John Fayhee, Why I Still Carry an External-Frame Pack, Backpacker (2018-10-19). I hope that, once the gram consciousness that now almost theocratically defines the backcountry loosens up a bit, more people will realize that external-frame packs are worth their weight in reading material and vodka. And perhaps more companies will start making them again, and maybe you’ll see one in a future edition of this magazine’s Gear Guide. In the meantime, I will proudly carry my new Tioga with me, despite (or because of) all the stunned glances I get on the trail.

Listened

  1. Episode 901: Bad Cops Are Expensive, Planey Money (2019-03-22).
  2. Gerard Manley Hopkins, In Our Time (2019-03-21). [28:33] And what sprung rhythm in many ways does is bring in some of the creative vitality that Hopkins sees in ordinary speech rhythms into poetry. It's in a way a reaction against the over-regularization of poetic meters, injecting greater variability, whilst not losing the sense of the basic rhythm underneath.
  3. Why U.S. Working Moms Are So Stressed – And What To Do About It, HBR IdeaCast (2019-03-26).

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

A week in review, 2019-W12

Wrote

  1. Support systems hocus pocus (2019-03-23)
  2. Call your shot and record it (2019-03-22)
  3. Listening is hard (2019-03-18)

Read

  1. Ken Favaro and Manish Jhunjhunwala, Why Teams Should Record Individual Expectations, MIT Sloan Management Review (2018-11-30). However, when individual expectations are recorded along with the key assumptions behind them, important differences become visible. One person might see 2+2 as the problem to solve, another might see 1+3, and another might think it’s 5-1. Even if you all arrive at the same answer, recording and then discussing the variety of paths that different stakeholders expect forces everyone to think in new ways. And often the team ends up concluding that 1+5 is the right starting place—and thus arriving at a different, unanticipated, and better decision altogether.
  2. Richard Brody, The Great American Novel Buried in Norman Mailer’s Letters, The New Yorker (2014-12-10). In effect, Mailer’s letters attest not as much to his experience as to his experience of experience—his very notion of experience as something simultaneously centrifugal and centripetal, an adventuresome excursion into a world outside one’s familiar circle as well as a plunge within, toward the impenetrable core of the soul. It’s the ordinary that strikes him as inert and infertile. Even while a student at Harvard (he studied engineering but was already an ambitious and successful student writer), his notion of literary experience was that it wasn’t the hand one was dealt or the way one played it, it was the game that one set out to learn.
  3. Andy Staples, Fletcher Magee's Perfectly Imperfect Shot Refuses to Stop Falling for Wofford, Sports Illustrated (2019-03-22). For most of his basketball-playing life, Magee—who wears No. 3 not because of his favorite shot but because he loves Allen Iverson—has sought to perfect an unblockable jumper. He concocts scenarios inside and outside of practice to force himself to shoot from awkward angles and positions. Quarterbacks would call it "off-platform." When teammates first see his fanatical devotion to ripping shots from every possible body contortion, they scratch their heads. But when they see him making those shots in practices and games, they understand.
  4. Naomi Rea, Two Photographers Traveled to the Arctic to Capture Powerful Images of the Rapidly Militarizing Region. See Their Work Here, artnet News (2019-03-15).
  5. Mark Maier, System and Software Architecture Reconciliation, Systems Engineering (2006-03-30). (notes) Why is there this distinction between traditional systems engineering practice with its emphasis on detailed and complete requirements specification and software architecture that does not need it? The difference is a matter of base assumption. The classical assumption in systems engineering (and often true) is that rectifying requirements mistakes late in the process (for example after a system is fielded) are orders of magnitude more expensive than avoiding the mistake very early in the process. In contrast, incremental software development is predicated on the assumption that it is impossible to know all the user requirements early, that many of the most important ones can be discovered only after a software system is shipped, and that making fielded changes to software is low cost.

Listened

  1. Petty Tyrant, This American Life (2010-11-12). What's striking about these tapes is that Steve sees himself on the side of good. He only does bad things to bullies, he says. He hates bullies. And anyway, most of what he does—like planting a bomb at the house of Laura Balogh, the one who broke up with his local union president—are on behalf of friends, against people he doesn't even know. He'll do anything for a friend, he says. He's loyal that way.
  2. Chip Conley: The Modern Elder and the Intergenerational Workplace, Long Now: Seminars About Long-Term Thinking (2019-03-13). [27:14] [...] and the thing that happens with your brain as you get older is, generally speaking, you get all-wheel drive, which basically means you do the left-brain right-brain tango better than a younger person [...]. You actually are able to move from linear to creative much more quickly, more adeptly, which means that--what is the result of that?--it means that you get the gist of things faster. You can think systemically and holistically much better than when you were young, when you were extremely focused. Now in the context of an organization like Airbnb that's growing as fast as it is, and has a lot of things happening all over the world all at once, and has a leadership that's very young, to be the person in the room who can occasionally synthesize and get the gist of something and say, "I see pattern recognition here"--and pattern recognition is another way of saying wisdom--and be able to call that out, is the value of a modern elder in that workplace.
  3. Math Major Counts Cards, Beats Vegas Dealers, Side Hustle School (2019-03-16). [5:33] Colin's advice is that running a business is a lot like counting cards at blackjack. It's about knowing how much value you are currently creating, figuring out how you can add to that, and making the right decision based on your observations. He also suggets you always bet on yourself.

Watched

Townes Van Zandt - Pancho and Lefty, Heartworn Highways (1981-05-13)

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

Support systems hocus pocus

Automation is easy. It's as simple as taking note of how you do a repetitive task and teaching some software how to do it for you.

The next easiest version is similar, but taking note of how other people do repetitive tasks. What happens when you do this is: (1) you learn some new and better ways of doing things that you would never have figured out yourself, and thus are worth stealing as they are; or (2) you learn some really backwards and awful ways of doing things, which are also worth stealing, but as a starting point to riff off of (and later they become things that you know your automations will have to prevent, like the protections we put in our airplane thrust controllers to keep pilots from accidentally putting them in reverse in flight).

After that comes improvement and optimization and teaching the software to teach itself and so on. I'm just skipping past that here because that part of the problem is fun—working on the function is visceral.

That brings up the hard parts of automation: finding ways to share the methods, making the human interfaces tolerable (never mind even good, just tolerable user interfaces are difficult I think), making the automations configurable for different users, finding abstract ways to store the inputs and the outputs and the automations themselves, validating that everything is working as it should, some guides on how to use the thing, and so on.

Basically, the hard part is the support systems. Those parts aren't fun and they don't get the same respect as the core functions—but without them, things fall apart. Software will also seize and die one day, or at least the nature of the problem will start to drift away from the automated solution.

Anyway, I guess I wasn't trying to teach or explain anything in this note as much as I was trying to motivate myself to work on the support systems for the more interesting automations I'm trying to develop at work. I'm trying to think of a list of what needs to be done after the so-called Real Work is done—because it doesn't matter if the software works if no one can use it.


Postscript

"Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance."
—Kurt Vonnegut, Hocus Pocus (1997)

Call your shot and record it

Ken Favaro and Manish Jhunjhunwala, Why Teams Should Record Individual Expectations, MIT Sloan Management Review (2018-11-30)


However, when individual expectations are recorded along with the key assumptions behind them, important differences become visible. One person might see 2+2 as the problem to solve, another might see 1+3, and another might think it’s 5-1. Even if you all arrive at the same answer, recording and then discussing the variety of paths that different stakeholders expect forces everyone to think in new ways. And often the team ends up concluding that 1+5 is the right starting place — and thus arriving at a different, unanticipated, and better decision altogether.

I agree. Record everything—practically speaking, of course. Set up a system to record your predictions and assumptions and how the thing you predicted turned out. Thought you'd finish some aspect of a project in 4 weeks while spending 50% of your time on it? Mark it down. See how it actually turned out. Compare. Get better at predicting.

I've tried versions of this. Say I have a task—finish a section of a requirements spec. How long will it take, the bossman asks. I can get it done in four weeks, I say. Mark it down. Capture the actual result. Compare. How far were you off? Note the difference. Debrief and figure out why. Do it again. And again. And again.

It's not a comfortable exercise.

Want to find out how bad you are at predicting the future? Write down your predictions. Write down the actual result. Compare the two. You'll stop hating on the weatherman. At least he stands up in public, on TV, and gives his prediction.

I've never done this exercise extensively, or with a team of people. I bet you would find a lot of interesting patterns—who chronically underestimates the amount of time for projects, who has a hard time breaking up big predictions into smaller sized predictions (which should be the same as breaking up big tasks into smaller tasks), who gets touchy about having their guesses recorded and compared. If you could figure out the patterns—the good and the bad—you could cover for your blind spots and play to your strengths. It would have to be the right team—the kind of people who could take straightforward feedback. That's not easy. I love to say that I can take it, but in practice it's hit-or-miss. Negative feedback, however well-meant, still feels like a slap in the face. The real trick is your reaction to that feeling.

Every month, every week, every day: I try to lay out what work I have to do, and when I'm going to work on it. But I don't often aggregate the total estimate of how much time it will take (because I get a pile of tasks to work on, and there is some wrangling about how to work on that pile so that the pilers think you're not ignoring them), and I never count the total amount of time it takes (even though I actually record it with Toggl. The truth is: doing the work itself takes a lot of time and effort, and the extra step of recording and comparing feels like extra work. It's true: it is extra work. But if the extra work can make the future work go faster, then it's a useful feedback loop. And if you can automate the input back into the feedback loop, then you can really improve.

So, that's my mission for April, I think: record my assumptions and predictions on the projects I'm working on, then record the actuals, then compare them, then do the hard work of improving.

Listening is hard

Listening is hard.

I was dealing with someone today (read: exchanging reply-all emails), and I was overwhelmed by this rage of "Why won't you just listen?" Later, I did the usual corporate thing (read: banged out another email), except it was after work hours so I decided not to send it.

Not sending led to an unexpected wealth of time to reflect--this time, mainly, to consider my history of listening. Not so good. I tried to think of the best personal examples of times when I listened. The best I could come up with was the second half of undergrad, when I would fiendishly scribble notes, trying to not just catch the things on the slides and the things written on the board, but the additional information and context that was said between all those written words; and following all that I would rewrite the notes on yellow engineering paper. That's good, sure, but taking notes is fairly deterministic--the information flow is one-sided and defined by the lesson on the agenda, and there was really no penalty to missing anything.

Real Life is quite different. Listening well is quite indeterministic. There may be some contextual boundaries, but they're not hard boundaries. And it's not one-sided. You have to hold up your end of the conversation, absorbing what you hear, not spending that time formulating a response but actually absorbing, not posturing as if you're listening but actually listening.

All pretty obvious stuff, really. I wouldn't bother typing it if I was any good at it. I was hoping that considering the steps in listening would help me find the area where I'm getting it wrong. But like a lot of ego-induced incidents, the problem isn't getting the steps wrong, but rather the viewpoint you bring to a situation. If you try to protect your ego, you're going to listen poorly and allocate your attention to surface features, to look like you're listening, to concocting a response. But if you can subsume your ego, you might feel comfortable with the possibility that you're not going to look smart, that you're not going to have any witty answers, and your attention can be focused on the other person instead of yourself. So maybe there is no training for listening better, only practicing the subtle art of not taking yourself so damned seriously.

A week in review, 2019-W11

Wrote

  1. Eating as an out-of-the-box solution (2019-03-16)
  2. Is there a better way to say process improvement than saying process improvement? (2019-03-15)
  3. A basis for working smarter, not harder (2019-03-14)
  4. Cow and pig: avatars of improvement (2019-03-11)

Read

  1. Robinson Meyer, Houseplants Don’t Actually Clean the Air, The Atlantic (2019-03-09). "It's such an alluring and enticing idea," Elliot Gall, a Portland State University professor, told me. "But the scientific literature shows that indoor houseplants—as would be typically implemented in a person's home—do very little to clean the air." "My view is even harsher than that," Michael Waring, an engineering professor at Drexel University, told me. "I do not think that houseplants clean the air."
  2. Charles Duhigg, Dr. Elon & Mr. Musk: Life Inside Tesla's Production Hell, Wired (2018-12-13). There’s a sense of tragedy in such stories because these men seemed, at one point, to rise above the masses and suggest that genius is possible. Silicon Valley in particular reveres these kind of heroes—and the more willful and ornery they are, the better. Technologists are often called upon to do things that seem impossible, and so they celebrate when doubters are proven wrong—when the dismissal of an idea becomes evidence of its visionary reach. The idea of the odd genius is afforded a special status within technology. People lionize inventors who listen to their intuition and ignore naysayers, who hold themselves and everyone else to a standard of perfection, regardless of what it costs those around them. Steve Jobs is gone; now we have Elon Musk.
  3. Megan Thompson, If you can't beat 'em, eat 'em:' University of Illinois serves invasive Asian carp for dinner, PBS NewsHour (2019-01-29).
  4. Nathan Robinson, Meritocracy is a myth invented by the rich, The Guardian (2019-03-14). In reality, there can never be such a thing as a meritocracy, because there’s never going to be fully equal opportunity. The main function of the concept is to assure elites that they deserve their position in life. It eases the "anxiety of affluence", that nagging feeling that they might be the beneficiaries of the arbitrary "birth lottery" rather than the products of their own individual ingenuity and hard work.
  5. Danny Wicentowski, Brian Stofiel Stumbled Onto the Right Stuff For Orbit: a Plastic Rocket, Riverfront Times (2019-03-07).

Listened

  1. Unconditional Love, This American Life (2019-03-08). [35:17] "I don't think he wants to hurt me. I don't worry about that at all." It's a very unsentimental view of her relationship with her child, but that is probably exactly what has made Heidi so successful. That is, Heidi is an unusually pragmatic person. She's not a flowering earth mother with a wealth of love to give. She is fundamentally realistic, tough minded, and these are precisely the characteristics that are needed in this situation. If you're the kind of person who actually needs love—really needs love—chances are, you're not the kind of person who's going to have the wherewithal to create it. Creating love is not for the soft and sentimental among us. Love is a tough business.
  2. Episode 211: Sartre on Racism and Authenticity (Part One), The Partially Examined Life (2019-03-11). (notes) [13:00] So one of the things the anti-Semite is doing is they're grounding themselves in the irrational and the concrete and the intuitive, as over and against the universal and the rational. So the manifestation of that, right, is to say, look, I have a certain heritage, I have these societal values, my family's been in this country for hundreds of years, I simply inherit and possess these things and I don't have to do anything for them. I don't have to be smart, I don't have to achieve a lot, because--this is the strategy, according to Sartre, of the middle class--I just have to possess these cultural values, and in that sense I gain a status and a transcendence of everyday class and social hierarchies by way of that. So, without effort, without having to compare my status to others. So, he calls this a kind of mob equalitarianism or mob egalitarianism or, another way that he puts it that I like, is elite mediocrity, an aristocracy of birth where someone who's not at the top of the hierarchy can enjoy high level status through identification with country.
  3. Continuing Education Directory Earns Six Figures, Side Hustle School (2019-03-09).

Watched

天上“龙肉” 地上驴肉【食尚大转盘 20170226】 ("In heaven there is dragon meat, on Earth there is donkey meat.")

Photo

McDonald's 油条

Upcoming


There might be additional links that didn't make the cut at notes.kirkkittell.com

Eating as an out-of-the-box solution

Megan Thompson, 'If you can't beat 'em, eat 'em:' University of Illinois serves invasive Asian carp for dinner, PBS NewsHour (2019-01-26).

I've had this article sitting in my to-read pile for weeks before finally reading it this morning. Have you ever seen Asian carp in action? They're awful. In high school, I went water skiing in the Illinois River near Havana a few times with a friend. No problems then (except for not being so good at water skiing), but I bet it's not even possible now—or if possible, not safe. You'd have to dress in football pads and helmet to survive, and even then you'd get slimed.

Anyway, that's just the aesthetic aspect—the practical aspect is that they ruin the aquatic environment they're in (remove plants, disturb the riverbed) and run off other fish.

So: good on the University of Illinois for serving the fish up on plates. Now, if you've got any Chinese friends, the solution would have been obvious to them from the start—it wouldn't have been a question of should the fish be eaten but when and how it would be cooked. For us, in the Midwest, there are two kinds of fish: frozen fish and catfish. (Fishing friends, don't @ me.) Left to our own devices I don't think we would have come up with the idea of eating the problem as a solution. These are the kind of fish you want to beat with a baseball bat and then bury unceremoniously in a corn field. Given our context, eating the fish is thinking outside the box; how they got the students to buy into eating it, I don't know, maybe they just followed the line of Chinese students into the dining hall.

I think that sounds like I'm getting close to the pejorative there, but I've eaten several things in China—some of them tasty, some of them well-that's-an-interesting-experience—that I never would have considered eating myself. And every one of the places serving that food had a line.

I was going to call this post "Eat the problem", then I found that Chef Philippe Parola was a step ahead: eattheproblem.us. He's taking on the problem from the other end of the Mississippi River.

Is there a better way to say process improvement than saying process improvement?

"Process improvement".

Gross.

If you've ever had a corporate job you know about process. Sorry, I mean capital-P Process.

Nominally, process is how you—yes, you—as a good worker take something from point A to B to C to ... to the End. Maybe it's metal fabrication. Maybe it's paperwork fabrication. Either way the idea is to transform things from their original state to a final state.

Just typing that word makes my blood pressure spike... process.

You see, in the best scenario, process—a set of written rules that you follow to get from start to finish—helps you Get The Job Done Quickly And Correctly. But in the worst case, process does the opposite: it's out of date, it's wrong, it's confining, it's stifling, it's not the best way but it takes seven weeks and four review boards to change so whatever it's good enough, it's the way we say we do things when our boss asks but in reality we each have our own list of steps that actually gets the job done. And so on.

Beating around the bush here—sorry. Process improvement. I don't mind doing it. I wish it was called something else more interesting, but it's not. I really spend time at work thinking, "how can I do this boring task way faster?" Or, "how can I write some software so that I can just push a button and do my work for me?" Or, "why does this work standard say I have to do these 17 steps when we only really use the output of 7 of them?"

But there's a limit to the amount of things you can improve by yourself. To really knock things over, you need to organize a team[1]. That's the leap I'm trying to make at work. Yesterday day I wrote some words about working smarter not harder. Creating a team, and getting them to Move, is perhaps the archetypical way to work smarter. I've never had much trouble doing that outside of work. Organizing a professional society or alumni club or whatever, it's always been second nature to recruit people, give them a vision, get them to work together, and then light out after some goal.

Then this year I thought: why not just do it at work the same way I do it out of work? And that's what I've been doing. This week I ran our first Performance Improvement Group (PIG) on our team, just to do simple things like find opportunities to automate work that we all hate but have to do, and share ways to do our everyday work faster. It's not all that inspiring—it's no moon shot—but it saves time and money, and for anyone that wants to get into it there's a chance to learn some coding. And it's had a secondary effect where more people just drop by my desk and ask if I can help them with things. Now, it's definitely not that I know more things. What's happening, I think, is that now there's an environment where people can question the most basic things that they're doing, that now they can listen to that internal voice that thinks that there's got to be a better way. And then what happens is that two people will come to me with the same problem, then you can do a little work and hit two targets with one shot.

All of that is within the team—maybe two dozen people at most. The next iteration of this is going to be inter-team, connecting systems engineers from different teams to share what they're doing and ruthlessly steal from each other. Connecting different teams will definitely be a forgiveness-not-permission kind of affair (for good or ill, managers know how to guard their territory), but there's so much more opportunity to wipe out duplication where it's not needed and bring the best ideas to the top and leave room to experiment where you can, etc.

So, inasmuch as process improvement is about getting more things done better and being open to the idea that the world is always changing and improvement implies changing to keep up, I'm in. If process improvement is about ossification at the best state at a given time, and then intentionally fighting against the inevitable change in the world, I'm out.


[1] Ed Abbey, The Monkey Wrench Gang: "One man alone can be pretty dumb sometimes, but for real bona fide stupidity, there ain't nothing can beat teamwork."

A basis for working smarter, not harder

"Work smarter not harder" is lame, obvious advice that you should always keep to yourself. Obviously this is what should be done, right? Saying it out loud doesn't serve any purpose other than to mark yourself as the kind of person that nobody wants to hang out with.

Again, though, it's good advice. Folksy knowledge. Common sense.

Here's a paper I found recently that explains why:

Repenning, Nelson P., and John D. Sterman. "Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement." California Management Review, vol. 43, no. 4, July 2001, pp. 64–88, doi:10.2307/41166101. (pdf) (notes)

Common sense is easy to dismiss when it seems folksy—the sort of thing that doesn't necessarily apply to a Man of Sophistication. So what I like about the paper is that it takes a system dynamics approach to explaining why working smarter eats working harder's lunch. System dynamics (Wikipedia) is essentially a way to understand how feedback loops affect the behavior of a system, which produces weird (non-linear) results.

The short-short version is: working harder is like trying to cut more wood with an ax by spending more time chopping without investing enough time in sharpening the ax. It's like eating the seed corn or spending the principal. In the short term, you might get ahead of the problem, but at the cost of reducing your capability to solve the problem so that eventually you fall behind. And then what? Keep chopping or start sharpening? The former will lead you into the capability trap where you get too far behind to ever recover; the latter will cause short term slowdown when you take away time from catching up, but long term improvements because you can move faster.

Reading this paper will give you some substance to push back on the natural drive to solve a capacity problem by simply spending more time on it.

...Now that I think about it, working smarter might seem like common sense intellectually, but viscerally working harder feels like common sense in the moment—some sort of an I Am The Master Of My Destiny feeling as you wrestle with something that didn't necessarily need to be wrestled with. That's covered in the paper also: the fundamental attribution error, where a manager assumes that the problem is a lazy or incapable staff that just needs the right amount of beating to get motivated to solve the problem. It's not an easy feeling to resist, but if you remember there are benefits to sharpening the ax, you might make the right long term choice to do so.

Cow and pig: avatars of improvement

Some people use fast, ferocious, inspiring, fearsome animals as the mascots for their projects—hawks, eagles, lions, tigers. Livestock is my spirit animal.

Today I put together a weekly get-together on Friday at lunch to share some better ways of getting things done, and to focus on some vexing problems that could be automated to save ourselves some time. Nothing fancy. It's just that people often stop by my desk for some help with DOORS (requirements database) or with displaying some text stuff that shouldn't have been put in Excel (but for the fact that it's better there than wherever else it would end up, probably PowerPoint). Or maybe I just look at documents and spreadsheets and so on with that nagging feeling of "there's got to be a better way"—constantly. I enjoy doing that work—improving things—but (1) I'm not that good at it, I'm just persistent; and (2) I don't want that to be my job, I just do it so that I can work with or display the actual content better.

Anyway, I called the group the Performance Improvement Group. The PIG. It is, after all, the year of the pig in the Chinese zodiac calendar.

And that reminded me of how, five years earlier, I enrolled another bit of livestock to help me record some beefs we had with the program we were on and to collect some lessons learned:

May is, after all, Beef Month in Iowa.