Category Archives: Uncategorized

Rabbit hole: the Jawb market

Previous: Rabbit hole: subway mysteries of New York


It's so easy to get caught in the current on Wikipedia. Find the thing you're looking for then... link... link... link... link... and then you're miles downstream of where you intended to be. Sometimes the results are interesting.

It all started with a friend at a Jawbreaker concert in Boston... which is a blast from the 20th century.

"One two three four / Who's punk? What's the score?"

And then we had a quick chat about the jawb market, since 90s contemporary Jawbox is back and on tour.

I listened to more Jawbreaker than Jawbox in college—which is academic anyway since both bands had already broken up. But bits of Jawbox turned into Burning Airlines, who I also liked during college.

I didn't think much then or now about where Burning Airlines got their name, but Wikipedia quite helpfully explained that they got it from a Brian Eno song, "Burning Airlines Give You So Much More", from his 1974 album Taking Tiger Mountain (By Strategy)

And here is the delta where this current left me: during the development of Taking Tiger Mountain (By Strategy), Brian Eno and Peter Schmidt developed a deck of cards called Oblique Strategies to help them through the creative process—ideas and prompts and dilemmas that would help them think of things from a different point of view.

Here's a website (in 90s style—hello there, beautiful) from Gregory Taylor that explains the cards: A Primer on Oblique Strategizing (1997).

I think this sort of thing—random but thoughtful prompts—is great for getting a pushstart on work of various kinds. Stuck on writing a post? Draw a card. Stuck on a piece of code? Draw a card. Stuck on some work? Draw a card. The card need not have the answer, or even be a relevant question—it really just needs to nudge your internal trajectory so that you get to a thought you wouldn't have got to otherwise—which is kind of how this whole link-following episode turned out for me this time.

And a few other links to send you off:

And finally, from minimaldesign.net, a version of Oblique Strategies on your browser.

Try faking it.

Magic backlog board

My posts here tend to oscillate between the obvious and the esoteric. This one is going to bury the needle on the obvious side.

I have a good system for organizing information for projects at home and at work. In short: every project and initiative gets a page or notebook in Evernote (home) or OneNote (work); lots of linking in and out of projects and journals; individual pages for weeks, months, and years; etc. I've done this since 2012, evolving it into what I thought was a great system over the years, but this week I changed something and discovered it was only a good system.

Good not great. The parts of the system that deal with structure and organizing information are really good; the planning ahead in weekly/monthly/ yearly chunks is OK; the relationship between how much I accomplish to how much I planned to accomplish really isn't good at all. Execution... isn't this the part of the planning that matters?

Last week at work I took part in a two-day agile software development training course. I'm not a software developer myself, but I'm part of a development team, and we're using agile to do the development. So I'm trying to learn the rudiments so I don't get left too far behind.

The thing that struck me the most at the training course was how the backlog of work was treated. I also keep a backlog of tasks, but (1) it's scattered and not ranked; and more importantly, (2) I don't treat the next thing I take off the stack like something I need to finish before moving on to the next thing and the next thing. This second thing is so key.

A normal day for me would be queuing about seven or eight things to work on, and giving them each a half-hour or an hour of time on that day. That approach never worked, but there was always an internal pressure to organize the work like that anyway. I'm not sure why. Mostly I think it was the misguided idea that all things could get done if you just pushed them all forward every day. Maybe there were some other subconscious blocks, like I could make an excuse for not finishing any one thing on the sheer magnitude of initiatives I was trying to carry at one time.

So, taking a cue from the agile training, this week at work I took the list of tasks I keep in OneNote and put the top non-recurring tasks (the recurring ones still have to be done on a rhythm, backlog be damned) in a ranked backlog on my white board, with the one I'm working on now at the top, sort of like this (but with real tasks, etc.):

/now:
Review the development plan

/backlog:
Finish the user admin section of the spec
Draw change process figures
Draft the lower-level spec
World peace

And so on. You might recognize where the /now came from, no?

First of all, creating a ranked backlog and not moving on until the task at the top was finished was an immediate boost in focus, efficiency, etc. Things got done faster. Second, it feels good to erase the thing being done now and moving something from the backlog up. Third, putting the list on the board, instead of hidden on the computer where only I could see it, and only if I wanted to see it, added some extra motivation or direction to get the work done. Finally, putting the list on the board gave me the confidence to tell people (a) that I was working on something at the moment, where should I put their Immediate Request in the ranked list? and (b) when I finished doing some work for them I was moving on to the next thing (points at thing). There's a really fine line between being direct and being an asshole; let's just say I spend a lot of time on both sides. But I think that if I've done a good job in ranking the list, and in working with the various stakeholders associated with each of them, and in getting some cover fire from my manager by explaining what the plan is, then it's clearly the right way to handle the work.

My meta-plan now is to make the whiteboard backlog a Thing We Do on the team. Most people have to walk by my cubicle to get to their cubicle/office, so I think that if I stick to it, I can make it spread.

There is one thing I haven't figured out, though: there is clearly a threshold beyond which efficiency dies out. So there's some balance to work out there.

(I don't think anything in this post is original or new for The World. Intellectually, it's not even original or new idea for me. But I've never been able to muster the self-control to organize myself like this until recently, so viscerally, for me, this is a Whole New World.)

Interesting accidents

I was going to add this one to the post yesterday, but couldn't quite get it to fit. So I'll let it stand on its own.

In a recent episode of the Tim Ferriss Show—Neil Gaiman — The Interview I’ve Waited 20 Years To Do (#366) (2019-03-28)—there was a sequence near the end from Neil Gaiman (whose books I've never read yet, but never mind that) that I liked:

[1:32:52] The biggest thing, looking back on it, that I learned from Terry was a willingness to go forward without knowing what happens. You might know what happens next, but you don’t know what happens after that, but it's okay because you're a grownup and you will figure it out. There's lots of metaphors for writing a novel and George R.R. Martin, for example, divides writers into architects and gardeners. I can be an architect if I have to, but I'd rather be a gardener. I would rather plant the seeds, water them, and figure out what I'm growing as they grow and then prune it and trim it and pleach it, whatever I need to do to make something beautiful that appears intentional, but at the end of the day you have to allow for accidents and randomness and just, "What happens when things grow?"

I'm not sure which of those categories I tend to fall into most often. On one hand, I do a lot of planning, trying to sort out details before getting started. But I also sometimes just start in order to see what happens. And other times I do the planning, but throw out the plan when getting started, using the methods practiced while planning more than the specific details that were planned, and then enjoying the interesting accidents that occur.

Sometimes it just depends on the stakes, and who is relying on the outcomes. If it's something important and there's time to plan: plan. If other people are working with me or counting on me to get something done and there's time to plan: plan.

But in the main, I think I tend to get started without knowing all the details and tweaking the trajectory as I go along. I enjoy watching the pieces emerge and fall into place. I feel calmer trying to figure out the action as I go—perhaps because there is no worrying about whether or not things are going to plan, or because it's just more interesting to see what happens.

Reminds me of one more thing—perhaps due to thinking of that last hesitation before leaning into something uncertain:

The pleasure of sport was so often the chance to indulge the cessation of time itself—the pitcher dawdling on the mound, the skier poised at the top of a mountain trail, the basketball player with the rough skin of the ball against his palm preparing for a foul shot, the tennis player at set point over his opponent—all of them savoring a moment before committing themselves to action.

—George Plimpton, Paper Lion (1966)

The Steph Curry of dumb questions

Actual line from an email that I sent today:

I am the Steph Curry of dumb questions.

I don't know where the words, and the phrases, and the sentences, and so on, that form in my head come from. Sometimes I'm even listening to the words that come out of my mouth just to hear what happens next. For the most part, I think, it's not just a bunch of gobbledygook. (Sometimes it is.) But I am willing to experiment with the ideas I'm thinking of, to experiment with the words I use to describe them, to find some kind of oblique way to get the point across. I don't have all that much patience for the prosaic—for good or ill. I search and I search and I search for the words to make an impact when I describe something. (For good or ill.)

I found a trapdoor into the past this evening, and I've been falling and falling and falling through it ever since. There was a reason for it: I was tying together an article I read about farming on Mars (I intended this post to be about that, but it didn't make the cut) with our senior design project at Illinois back in 2002-2003. Because I keep everything, I found on a backup drive the folder that had not just our report (which was all I expected to find) but all of the data and references and animation files and meeting minutes and so on from that project. And I also found some things from when I ran the Peoria-area Order of the Arrow chapter back in the 20th century in a nearby folder—something I was actually looking for another time, but found accidentally now.

This post has gone sideways from the very start, but here's a reason I mentioned the last two things: sometimes I wonder how I end up as the lead on various projects that I participate in, both professionally and not. I still don't know why. But I've been doing it now for decades. And finding some of the original materials is very weird because some of the things that I think I've just come up with today while leading a group of professionals turns out to be a variation on something I did a long time ago. "There is no new thing under the sun"—barely any new thing inside my head.

I remember Mike Riopell saying to me, circa 2000, as I emerged unplanned from the woods at the post-camp Staff Burn at Ingersoll Scout Reservation: "You're so flamboyantly inappropriate." Maybe it's true.

I am the Steph Curry of dumb questions.

Being flamboyantly inappropriate has its use.

I was in a meeting on Tuesday, and the Tech Fellow—company-designated genius, seriously, no joke—leading the meeting is saying something something something CPS something something. Panic. I must be the only person dumb enough not to know what CPS means. So, in whispers, I ask other people around the table what it means. Nothing. Nothing. Nothing. One person has the courage to say: maybe you should ask. I ask. The Tech Fellow explains. Everyone around the table goes, "Ah", and more than a handful write it down. How is that? Why? How can a group of intelligent adults just be satisfied to let meaning rush past them without bothering to ask?

I am the Steph Curry of dumb questions. Anywhere on the short side of the halfcourt line is my territory. If I can push it just far enough to get a reasonable question off—and if I've done the work in the years and years and years leading up to the opportunity—I'm going to shoot it. Perhaps other people want to wait for a higher percentage shot—a layup, a jumper from the elbow, something that won't expose them. Not me. For reasons I don't understand I was given a headful of questions and permission to shoot. Which is partially true. The full truth is that I stew in that uncomfortable feeling—to ask or not to ask—before going forth. My superpower is being able to hoist two shoulderfuls of shame and keep moving forward.


Postscript: Ecclesiastes, chapter 1 (King James translation):

[3] What profit hath a man of all his labour which he taketh under the sun?
[4] One generation passeth away, and another generation cometh: but the earth abideth for ever.
[5] The sun also ariseth, and the sun goeth down, and hasteth to his place where he arose.
[6] The wind goeth toward the south, and turneth about unto the north; it whirleth about continually, and the wind returneth again according to his circuits.
[7] All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
[8] All things are full of labour; man cannot utter it: the eye is not satisfied with seeing, nor the ear filled with hearing.
[9] The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.
[10] Is there any thing whereof it may be said, See, this is new? it hath been already of old time, which was before us.
[11] There is no remembrance of former things; neither shall there be any remembrance of things that are to come with those that shall come after.

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.

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.