Journals Against Stories


This is about a supplemental habit I’ve picked up to go along with my recent anti-story practice, and it’s also a mini-review of the DayOne app.

I’ve known for a while that it’s good for me to have some sort of journaling to help deal with ADHD. I slip in and out of it, and use a variety of means to journal, including this blog, plain text files, and physical notebooks .

For a while, my practice involved a pair of daily entries meant to help me figure out the day ahead, then retrospect. It evolved from something I learned from one of my commanders at Fort Bragg, who started and ended each day with a sheet of legal paper she kept by her keyboard.

Over the past month, though, I’ve come to use journaling as a way to capture thoughts and feelings quickly and as on the spot as I can manage. I’ve adopted an informal template, making sure to capture most of the classic five W’s. My journaling tool supports hashtags, so I have a loose taxonomy to connect related entries. Sometimes I’ll make an explicit link between entries, too, if time allows or if an entry is so fragmentary that I want to make sure to connect it to one with context.

An entry usually involves what I was thinking about, how I felt about that (the emotional truth), what I think about that (the considered response), and what I want from all of it, either as an outcome/resolution, or a next step. I try not to self-censor if I can help it, avoiding the quiet temptation to record my best self in these entries.

I guess there are a few kinds of value to be gleaned:

First, I can see the ways in which the inner story-teller is always trying to impose a narrative, even in a moment of relative remove.

Second, I can see the ways in which thoughts and feelings are always changing. It’s a “two steps forward, one step back” sort of thing. Sometimes they refine and improve, sometimes they’re not super worthy. Getting that—understanding and embracing that variability, acknowledging my own messiness—makes it easier to engage a more objective self. I know about the messiness and imperfection of other people. Stepping back from myself long enough to see my own messiness—the messiness I forgive other people for all the time—makes it easier to cut to the ethical heart of hard things. I’m just another human. What would I tell another human if they asked me about this problem? What things would I remind them of? How would I counsel them to act?

It has helped me a few times so far in the past month. It has created a book-ending joy to go with the joy of those moments where I catch myself making up a story in my head and manage to stop doing it.

Journal for the Mission

I’m more kind to others than I am to myself, but my inner- and outer-directed kindness are never too far away from each other. My ability to be kind to others seems to have a ceiling set by how kind I can be to myself. The connection between those two capacities for kindness can be a liability, or it can be leveraged.

When I’m not objective about myself—when I allow uncomfortable or messy truths about myself to go unconsidered and unforgiven—I’m harder on others. I guess the ego casts about outside itself when it’s not comfortable with what it sees in itself. It distracts and comforts itself with the failings of others.

When I think about that small gap between my inner- and outer-directed kindness and try to apply the forgiveness I can muster for others to myself, then the ceiling on my kindness to others goes up that much more the next time around.

That’s important.

When I was pretty young, my dad took me to our church’s annual conference. I don’t embrace that church or its kind of spirituality any longer, but the mission statement for the conference that year has stayed with me:

Do justice. Love tenderly. Walk humbly.

It’s a paraphrase of a verse in Micah, and it has become a sort of meditational anchor over the years. I think a lot about the ways those three directives depend on each other:

Justice without kindness or humility is cruel.

Love depends on fairness and humility, or it becomes mere neediness.

We must temper humility with fairness and kindness to ourselves. We must understand the ways in which unconsidered self-effacement can be deeply unfair and ultimately cruel to others.

It seems to me that the more I can participate in a cycle of reciprocal kindness, to others and to myself, the more readily I can accomplish that mission.

A Few Notes on Day One

DayOne is a journaling app available for both MacOS and iOS. It offers a few key features that have made it great for this practice:

  • The ability to make quick entries, with a keyboard shortcut from the Mac desktop, or with a long press on the iOS icon
  • Fast, transparent cloud sync between devices/computers
  • Passcode/Touch ID security, end-to-end encryption
  • Hashtags
  • Inter-entry linking

It also understands Markdown, and automatically records location and weather in each entry.

I love being able to make a quick entry anywhere, from whatever device I’m using: Quick, thumbed entries on my phone, or longer and more considered entries with a real keyboard on my iPad or desktop machine.

I like knowing the security is pretty strong. If I switch away from the app on iOS, I can set it to require a thumbprint right away. If I sleep my computer, it’ll require a password before opening. That’s all less about security and more about having a strong sense of privacy: I record a lot of stuff in there. If you picked a random entry to read, who knows what you’d get.

On Progress Toward 365^H4 Pictures

I take joy in photography. Some time late last year I found myself down on the waterfront on a rainy night trying to get a few good pictures of downtown Portland from across the river, and I had this to say about the experience:

It was pouring on the way home tonight, but I’d brought along a tabletop tripod and loved the way the tops of the skyline were shrouded in mist, so I got out the camera and played around for a while despite the problems that little tripod and all the rain were causing me.

I’m so happy I get to live in such a beautiful place.

And I love the inner quiet that follows when I open my eyes and heart up to what’s around me. I’ve only felt that when writing, or when sitting with another person and setting aside everything but what they’re saying and feeling. Now I’m finding it in moments like this, when I’m out with my camera trying to pull off the Magic Eye trick of seeing nothing to see something. It feels like the thing is to practice enough to marry the quality of the craft to the quality of the inner state.

I haven’t felt happiness the way I felt it out in the rain tonight for a long time.

So at the beginning of the year I decided to do a thing I forget to do every other year, which is commit to taking at least one picture a day for the next year.

Sadly, sickness in early March caused me to forget a day. There’s a picture of me looking sort of miserable and wrapped in a bathrobe, then a woozy picture of a bottle of Jack Daniels in a darkened kitchen. In between? Sickness. So I’m not going to have a picture for every single day of this year.

Another thing happened, too, which is that life sort of got bumpy and didn’t straighten out for a little while. It made picture taking hard, because EVERYTHING was hard. I managed to get through the period sticking to my commitment, but one day’s picture was literally a hole in the ground with a chunk of concrete sticking out of it, because a picture of a hole was about all I could manage before getting home and going to bed.

Somedays all you can shoot is a hole

There are also some days with self portraits because I’d forget to take a picture until I was home, then I’d be unwilling to go out and look for stuff, so I’d drag myself into the garage where I have my little studio with flash and backdrop and take a picture of myself, because, you know, fuck it: Nothing says defeat like a half-assed selfie shot 10 minutes before bedtime.


At some point during this spell I was so unhappy with what I was taking that I considered quitting, but I thought about that a bit and realized a few things:

  • Even on my worst days, I’m still pointing the camera at a thing and thinking about what I’m doing, even if it’s just for a split second.
  • Even on days where I hate what I shot, I’ve probably been spending at least part of the day with my photographer’s eyes on.
  • I’ll be happier if I don’t quit.
  • This project has made me learn a lot about my camera. I’m way more proficient with it than I was a few months ago.
  • Looking back over the year so far, there’s a certain eclecticism that even the bad days reinforce. It’s not so bad as a whole.

Then I thought a bit about what was making the whole thing less pleasant to do and realized I’ve built up a pretty dense workflow that involves Lightroom automation and dealing with RAW files, and it’s not very fun. It’s also an invitation to rathole on salvaging images.

So, because I have a shooting engagement coming up at the end of next month and need a second camera, I picked up a new one that’s better suited to walking around, got it a small bag, and played around with a few presets meant to make it easier for me to quickly capture shots in a few styles but output in JPEG, and that has made a huge difference. Files download more quickly, there’s less goofing around to do because JPEGs are less forgiving of manipulation, and I’m being punished for my mistakes with a less flexible image format, which is GOOD because I wanted to do this to learn, and fiddling around with RAW images doesn’t incentivize learning behind the lens. I guess you could say it encourages more intentionality up front.

Anyhow, I’ll be sticking with it for now, but looking forward to summer camping and travel to help me shake up my subjects and break me out of a few ruts.

Here’s the project so far:


Supporting an Open Door Culture by Listening

The soul of our politics is the commitment to ending domination.  — bell hooks

Next week I’m going to give a talk on how men can support women in the tech industry. I was uncomfortable with the idea when first approached: My thoughts turned to images of me clicking through a deck and reading off bullets of things you shouldn’t do that I probably did myself at some point before someone undertook the effort required to get me to stop. I hated the idea of standing in front of a room and implying there’s something I get that maybe the men I’d be speaking to don’t. 

After a brief back and forth with one of the organizers, though, I proposed building a talk around a project I undertook a few years back to author guides for a company open door policy. She was supportive of the idea, and that made me more comfortable: Even though I had designed and led the project, it was never “mine:” It happened at all because our CEO had been listening to women who were telling him what they needed to feel more safe and heard at work, and I was just there to help make it happen. 

I suppose this entry is to help me firm up some of my thoughts before I present, but it’s also to provide a link to a repo that has the output of that project that’s consumable by anybody who’s interested in having a supplement to whatever fossil of an open door policy their company has tossed up on the intranet. I wanted to be able to share the work with the folks at my talk, so I scrubbed the guides down and dropped them on GitHub (along with a small todo list of things that could make them better in the project issues). I’ll link to it a bit later, too, but here it is right now in case you’re curious and don’t care about anything else I’ve got to say on the matter:

The initial brief for these things was to create a guide that made it easier to understand how to use our open door policy at all. I was asked to work with HR to deliver something that we could position within the open door policy itself, perhaps as a diagram or flowchart. I met with our VP of HR and one of our HR business partners, and we tried to whiteboard a basic “open door process flow.”

As an aside, that initial diagramming session was one of the best things that’s ever happened to me. Up until then I had a pretty dim view of HR. I’d worked in places where the HR org wasn’t just “there to serve the company’s interests,” but had become a sort of political center in its own right, controlling the path to promotion by gate-keeping mandatory training or obscuring promotion standards and practices. I’d never spent a lot of time thinking about the nuances of the HR discipline. 

By the time I was done working with that VP and business partner, I had a new appreciation for the complexities HR people deal with (and a huge amount of admiration for those two in particular, because they had an architect’s perspective on some of the problems we were discussing but were as engaged with making the architecture amenable to people as I was).   

I’d also decided the idea of just making a diagram or flow chart was a terrible idea: It was too rife with edge cases, and no amount of detail at the “step 1, step 2, step 3” level suggested an awareness of how it actually feels to have a problem you can’t fix for yourself that you have to go get help with. I took that idea away, digested it, talked to a few women around the company, and sent a note to the CEO:

… the issue is less “what are the steps?” and more “how do we get everybody to an equal place in terms of their confidence that when they use the steps they’ll get a good outcome?” Your public statements about non-retaliation a few months back are important, but there are things beyond retaliation that matter, too, and these came out in interviews:
  • Will my manager place the burden on me to fix the problem once they hear me out?
  • Is my manager attuned to the idea of discriminatory behavior that flies below the radar of outright bigotry? (microaggressions, which are not universally understood to be “real”)
  • Is my manager attuned to the idea that bringing my concerns to them sometimes feels like I might be marking myself as a troublemaker/”difficult,” if not to them then others. (confidentiality as a cardinal component of the process)
  • How will I know what’s going on with my issue once I bring it to someone?
  • How can I know I’m not going to inadvertently bring a hammer down on someone?
That’s 20 percent “process” and 80 percent human factors.

The next few months involved some document design, some writing, and a lot of listening. One of the people who worked for me had the misfortune of experiencing one of my people management failures, and I was incredibly lucky that we’d reestablished enough trust that she thought it was worth her time to explain to me how I’d fucked up. 

Another woman told me a deeply personal story about what it was like to be condescended and talked down to by a male colleague. We spent an hour talking about her experiences, and even then I was catching myself drifting toward thoughts about the ways in which her patronizing male colleague probably didn’t mean any harm, or surely hadn’t acted that poorly. We ended the meeting and went back to our desks. A few minutes later, I saw her at a nearby whiteboard with that colleague, so I stayed at my desk and listened to the interaction from afar, and it worse than she described, which caused me to realize that even in a relatively safe context she was still protecting someone who had treated her terribly. I’m glad I was able to engage in some empirical verification; I’m sorry I felt the need to. 

As the work progressed, I invited more and more people  into the documents to help shape them. At one point I had three copies of each document so stronger voices wouldn’t drown out quieter ones in the comments. When it was clear that the very idea of “microaggressions” was controversial, I asked women to help me list some examples: The documents don’t have that word in them (even if they probably should), but they articulate the idea and provide examples from womens’ experience. 

After a few months of work, either writing, listening, or reconciling the viewpoints we’d brought into the project, the VP of HR signed off and we shipped them to the CEO. He said he liked them, and he named four women he wanted me to meet with to get final approval. I was a little chagrined because I’d already talked to each person on his list as part of the work, but I invited them all to meet and discuss the finished docs, anyhow. They turned up a few more small things and we fixed them on the spot, which taught me it never hurts to listen for just a bit longer. 

We ended up with two guides, meant to be used as a supplement to a generic open door policy of the sort you can just go download from the web: 

The first guide is for employees. It’s written to strongly suggest our values around the process of escalation. The language is about “expectations,” and you could think of it as a bill of rights that compels certain behaviors from managers. The language is meant to be supportive and affirming. It’s made clear that if those expectations aren’t met,  the interaction is in trouble and the employee can bail on it, escalating to the next level.

The second guide is for managers. Structurally, it closely parallels the employee guide. The language is less on the “supportive and affirming” end of the spectrum than it is quite imperative. 

The employee guide references the manager guide a few times, not to avoid repetition and certainly not as a requirement to understand the employee guide, but to accentuate things we’re telling employees: “We told you to expect this behavior, and here is where we’re telling managers, in imperative language, to do exactly what we told you to expect. If you observe your manager not doing these things, you can see right there in the manual we wrote just for them that they’re supposed to be doing those things.”

Since releasing them just over two years ago, HR has made them part of the management training program, and our HR business partners make sure new employees hear about them when onboarding. When I’m involved in a conversation with an employee about something sensitive, I will often share the link after telling them about their rights to confidentiality, and I’ll make clear to them that the bedrock values of those docs include consent and confidentiality. 

I don’t have any way of measuring their success. Personally, I find them comforting: Even though I helped write them, I still find myself going to them to remind myself of my obligations to the people who work for me, and people have told me that they’ve been glad to read them. 

And they’re also a valuable reminder to me of a few things: 

First,  the piece of work I’m most proud of during my time at Puppet wasn’t really my work at all: It was the result of deciding I didn’t know everything I needed to know, that I didn’t have all the answers, and that my reputation as someone who understood womens’ concerns and was a good manager in that regard wasn’t something that I had—something that was part of my nature—but rather was the result of knowing to listen, and accepting the idea that “I know that I know nothing.” 

Second, that the thing I’m most proud of as a manager came not from “taking charge” and leading, but from deciding the best use of my authority was to assert my right to be guided by others who hadn’t been given that authority. 

Anyhow, if you see some values in these guides, they’re on GitHub. The README has a few suggestions on how to use them that preclude simply downloading them and tossing them up. Instead, I’d suggest you fork them and make them your own, preferably after talking to people in your organization and learning what would make such a guide more useful to them.  

Script Sunday: Fixing a Self-Inflicted Pinboard Nuisance

I really like the recent-ish share sheets in iOS, but I learned to my dismay that sometimes you’re not really sure what you’re passing from one app to another. After a week of using the RSS reader Unread in combination with the Pinboard app Pinner to save bookmarks, I learned that Unread was sending Pinner the domains of the things I was saving as the description, and not the title. So instead of a list of bookmarks that looked like this:

  • Reading in the dark
  • Archive articles from various sources to org file via IFTTT and Dropbox : orgmode
  • 9 Tips For Black And White Street Photography Post Production
  • How to Culture Jam a Populist in Four Easy Steps | Caracas Chronicles
  • E unibus pluram: television and U.S. fiction. – Free Online Library
  • The first days inside Trump’s White House: Fury, tumult and a reboot – The Washington Post

I ended up with a list of bookmarks that looked like this:


To be clear, this is a self-created problem brought about by my habit of saving anything that looks vaguely interesting and refusing to use the version of the Pinner share sheet that would have let me review title and tags before saving them. I’m okay with this, because the alternative is trying to peck in a description on my iPad while I’m hanging on to a strap on the Max.

Anyhow, there’s a gem for Pinboard that lets you run through your bookmarks and do stuff with them. Well … it lets you run through your bookmarks and learn stuff about them, and allows you to use the Pinboard API action to create a “new” bookmark. If you re-save a URL you had previously bookmarked, it’ll update the original item with anything that changed.

There’s probably also a way to programmatically determine whether a given string is a valid domain, but I went cheap and just check to see if the end of the description string is something like:

  • .ab
  • .abc
  • .abcd
  • .abcde

(plus a few other possibilities I’m willing to live with, since I’ve spent more time describing this than I did writing it)

Anyhow, the whole thing is short, simple, and dumb as a rock:

I’ve got a version sitting in my /bin directory that talks to the Alexa Web Information Service and extracts the categories for a given URL, but there’s some interesting taxonomical noise I need to sort through before I’ll actually use it in anger: Categories in Alexa seem to be a mix of topics (e.g. “photography”) and formats (e.g. “blog”). The former would be a great thing to programmatically tag a hastily saved bookmark with, the latter wouldn’t.

Probably also worth noting that Unread isn’t so much better than Reeder that it was worth having to run this thing every so often, so I switched back to Reeder, which does what I’d expect and passes a proper title to begin with.

Adventures In iOS Automation: Middleman Blogging Edition

My Things site is built on Middleman, a static site generator that's pretty much the Jekyll modern people can love.

I've tried static site generators a few times in the past, and the thing that's always stopped me from adopting them full-time for my regular blog (this one) is the overhead of maintaining something built around Git on a bunch of devices when most of my writing is spontaneous and squeezed in around the edges of other stuff. I was willing to do it with Things because it's a slower site, and the bulk of the content is developed over days or weeks.

When I got the iPad Pro I'm typing this entry on, it made me start thinking about the things I'd like to be able to do given a closer-to-real keyboard and enough screen real estate to keep my brain from freezing up when starting at everything through a 10" window. “Create and post content for a website managed by a static site generator kept in a Git repository” seemed like a pretty good test case.

Attempt 1: Paleo

Reader, my formative Internet experiences all happened on a Lear-Siegler ADM-3A+ talking to an Ultrix machine over a 300 baud modem. Consequently, when I'm confronted with a “move text from one place to another and make things happen” problem, the first place I go to is “open up a dumb terminal to some distant end where all the brains and guts are, and go from there.”

To that end, my first cut at the “maintain a version-controlled static site from an iPad Pro” problem was to find a decent terminal app and see what I could do with it. I went with Panic's Prompt, which is simple and pleasant.

I went through the hassle of setting up rbenv on shared hosting, added a few conditionals to my heretofore-mac-only .emacs.d, and applied myself to creating a blog entry. The stuff in the Middleman workflow that involves running shell commands worked fine, which solves the most potentially labor intensive part of making a new blog entry, which is creating a file in the right place with the right starting content and a decent slug.

Sadly, Prompt and Emacs don't exactly get along. Most frustrating is that the iPad Pro Smart Keyboard doesn't even have an escape key, and Prompt doesn't seem to have any provisions for remapping opt or cmd to work as a meta key. Instead, you can opt to have it keep a soft keyboard up on the bottom of the screen and reach up to tap an ESC key. This is as awful as it sounds.

Attempt 2: Whatever the Kids Are Doing These Days

So, the way my brain works, I usually end up deciding if something that worked well for me 25 years ago isn't working now, it's probably time to swing to the other extreme. That led me to Workflow, which is probably the closest iOS is going to get to Automator any time soon.

Workflow is pretty cool: You can drag and drop actions from a variety of iOS apps and chain together workflows. It can assign and modify variables, munge text, pass text off to other things to be munged some more, and create little Workflow applets you can launch from your home screen.

So, I set out to solve the first problem of creating a Middleman blog entry, which was the part where you set a title and then pass it through a few actions to create a decent slug. In other words, you want to start from a title of “This Is My Fantastic Blog Entry!” and end with a permalink that looks more like: 2016-04-23-this-is-my-fantastic-blog-entry.html.markdown.

Given the ability to write a script, the things you need to do to get there are pretty simple :

  • Grab the title
  • Downcase it.
  • Strip out all the non-word characters and replace them with dashes.
  • Make sure there are never multiple consecutive dashes.
  • Make sure there's not a trailing dash (because it's ugly).
  • Tack on the date to the front.
  • Tack on “.html.markdown” to the end.

There are things you can toss in there: For instance, since you know you need a particular date format for the “date” field of the entry, you can stash today's date in a variable for reuse. Same with the pre-munged title.

Doing that on Workflow was easy enough, but laborious: Workflow itself doesn't understand regular expressions, so it has to go talk to a third-party app that does. Since that app is a single-tasking marvel, it can't pass an input string through several transformations then pass it back: It has to receive the text, do the first transformation and pass it back to Workflow, which then decides what to do next and passes it back. Workflow and that outside app do this little dance four times. Because all of this is being done with a fascinating grassroots-driven system of callback URLs the assorted apps all understand, you sit there watching Workflow switch back and forth between apps. It can be a little dizzying.

This is going to sound weird, but that rapid flipping around between apps made me sort of hate what I cobbled together, which stopped me from going to the next logical step, which was figuring out how to hand the thing my workflow stitched together back to something that could try to get it into a Git repo.

The Editorial Way

Since I'm a compulsive iOS text editor experimenter, I had a copy of Editorial sitting around. Editorial understands Markdown, and it has some built in automation you can use to create text filters and talk to other apps. While I have no doubt that Workflow is amazing for a number of things, starting from your text editor and handing off to something else seems more elegant than starting from a different app, scurrying around between all the other apps, and then handing off to something else.

With Editorial, you just stack up actions in workflows using a drag-n-drop visual interface. It can do regular expressions, transformations, ask for text, etc. There's a very nice custom UI builder that I want to try out, which would allow me to pop up a form with fields for the title and tags, or logic for whether a file is ready to be published or just a draft. You can bind a given workflow to a hotkey, meaning it's possible to just type up an entry in (syntax-highlighted) Markdown, hit a hotkey, and constitute a proper Middleman blog entry with slug that can be handed off to a receiving app.

A little Googling yielded a Jekyll-based workflow someone had already put together that got me most of the way to where I wanted to be. It didn't do real slugs, and its front matter was a little different, but it was a simple matter to modify and produce my own

Getting It to GitHub

The other half of that workflow involved getting the newly created entry over to my Middleman site. For that, it uses an iOS Git client called Working Copy. Working Copy is free if all you want to do is browse your repos, and it costs $14.99 if you want to be able to push to them. Like Workflow, it's aware of callback URLs, so it's possible to push things into it from other apps.

Once the file is in Working Copy, you can just commit it and push it. Done.

Building the Site

Well, not quite. I wanted to automate the last mile, as well: Not only did I want to get the content into the repo, but I wanted to be able to update a local copy on my shared hosting and then run a site build.

I got a little lazy here. There's a simple PHP script you can ping with a GitHub webhook that will do the work of updating a local copy. It's not a perfect fit, but it does what I need. I stuck it off in a corner of one of my live sites. A cron job handles running a Middleman build every few minutes. Since Middleman is pretty smart about looking for changed files, it's not as expensive as a comparable Jekyll build.


Anyhow, lots of things thrown out. If you're a static site blogger looking to use an iPad or iPad Pro to write entries or maintain your Git-based site, here's the basic workflow:

Priorities v0.01

I spent a chunk of yesterday and a few hours today pulling a bunch of plumbing out of the Docs Decomposer so I could remake it into what I’m going to just call Priorities.

It’s a tool that lets you step through the prioritization exercise I outlined yesterday, and it provides a few extras because it’s happening in the context of a dynamic web page.

The Docs Decomposer had a prioritization tool bolted on as an afterthought, so it was missing a few things, including a conception of “teams.” Priorities has a Team model that allows multiple teams to exist inside of it, each with their own members and lists of priorities.

It’s in a somewhat usable state now, to the extent you could check it out of GitHub, run bundle, run the migrations, and self-provision your account, team, and priorities. The workflows for some of this aren’t great, and a few of the relationships that are meant to be two-way are as yet one-way. I think its documentation page is still that of the Docs Decomposer’s, too, so it won’t be super helpful.

Here’s a quick demo of the basic use:

There are a few places I’d like to take it:

Teams have but a single flavor now. Making the tool think of teams in terms of scrum teams or services teams would make it easier to extend Priorities into a general purpose prioritization and auditing tool. Services managers, for instance, could have a dashboard where they characterize the level of support they’re offering each scrum team, or would have mandatory priority objects for each scrum team the app knows about.

I’ve temporarily removed the tying of users to priorities. It would be easy to put them back, but the current approach to that problem assumes everyone on a team would be an active user of the app. People shouldn’t have to have logins to review team priorities. If I can solve how to do that, then active users can start having their own user pages, where they can see efforts they own and perhaps contribute to reporting around the priorities they’re responsible for.

The organizational model is flat. Extending the models to include a conception of “organizations” and adding some notion of whether a priority is tied to (or is) something like an OKR would make it possible to model an entire company.

Anyhow, next steps probably ought to be:

  • Cleaning it up under the hood a little.
  • Finally delivering on better user password reset tools.
  • Figuring out what it takes to Herokuize it.

Thinking About Priorities

I’ve had to think about prioritization a lot over the past few years. A few things make prioritization hard, even if you know you need to do it:

If you’re a manager in a busy place with a lot of customers or partners, you might have lost track of all the things you’ve committed to. If you don’t have a good practice of recording outcomes and next actions in meetings, you’ll find things creeping around behind your back.

If you don’t maintain boundaries with customers or partners, it’s going to be an issue for you, too. If you’re the type who’s open to being grabbed in the hall and put up to something on the basis of a nodding agreement, or if you regularly let people outside your team head straight to people who report to you without checking in on the interaction later, you’re not really maintaining boundaries.

If you and your manager or you and your team don’t have a culture of requiring a conversation about priorities with each new commitment, prioritization will be difficult.

If these patterns look familiar to you, you probably also know some of what comes next:

Your team will start to run hot as they struggle under the load of an undifferentiated (and possibly incomplete) list of their deliverables. That will take the form of stressed out behavior and guilt over what’s not being done. The folks with a workaholic streak will double down on their effort and become frustrated with people on the team who don’t follow suit. The ones who aren’t going to be pushed into working past reasonable hours will go into a defensive crouch.

Lacking a way to talk about your priorities with customers or partners, it’ll become easier and easier to flip from a posture of relative openness and helpfulness to one where it’s simpler to just say “get back to me in six months” (or never, if you’re being honest).

You’ll begin to focus on headcount as the cure to your problems: You know enough to know you’ve got a ton on your plate, and that your team’s morale is beginning to suffer, and that a few extra hands could at least take some of the pressure off.

Looking back, I don’t think I’ve ever worked anywhere that was doing a great job with prioritization, to the extent “great” would mean you’d be able to get affirmative answers to all these questions:

  • Do the managers have a list of everything they’ve committed to?
  • Is that list prioritized to at least the level of high/medium/low/not, and is it shared with everyone on the team?
  • Do managers periodically reassess the list and clearly identify things that can fall down into the “not a priority” bucket?
  • Do people on the team feel empowered to ask about the relative priority of new things as they come in without being made to feel like that’s an insubordinate or unfair/gotcha question?
  • Does everyone on the team treat those priorities as real?

Consequently, just about everywhere I’ve worked has shown some of the symptoms of poor prioritization, too. The ones that bother me the most are guilt and recrimination.

Guilt affects peoples’ ability to be open and honest about their work, and it erodes a team’s ability to celebrate what it has accomplished. Guilt also eventually blocks people from being able to ask for what they need from others, because the person feeling the guilt worries that they’ll be viewed as a hypocrite when they have their own impossible list of unfulfilled obligations.

Recrimination — anger turned on teammates for not doing enough — destroys trust, makes it hard to get people to pull together, and creates a toxic environment.

Taken together, guilt and recrimination from poor prioritization will grind a team down.

A Prioritization Exercise

I don’t think I’ve ever felt the challenges around prioritization more acutely than at a startup, where there’s a huge amount of energy, a massive appetite to solve big problems, and a desire to buckle down and become profitable (which means the “toss a few more bodies on the problem” solution to poor prioritization is losing its currency).

After some painful and frustrating conversations around the work my team was doing and the hands we had available to do it, I did an exercise that helped a lot.

The goal of the exercise is to get everything you’ve got going into a list, figure out how important each of those things is to you, describe how much effort you’re putting into it, and then start figuring out what really matters and what needs to come off.

The exercise uses a very simple model that helps you see the gaps between the priorities you think you have, and the work you’re actually doing.

Once you’ve completed the initial steps, you’ll have something that can serve as the foundation of a conversation with your team and your manager, as well as a tool to build an ongoing practice of thinking about what’s important and how what you’re actually doing lines up with that.

There’s no real magic here. The thing that strikes me about this process, however, is that when I describe it to people and show them the tools I use, it strikes a nerve. I think a lot of people are used to carrying their priorities in their heads, or expect their manager or some other leader to let them know what their priorities are (and steer them back when their actions don’t line up with priorities). So I’m writing about it in the hopes that people who are struggling with the stuff they have to do will see something they can use (or modify, or at least get some inspiration from).

This is also written from the perspective of someone managing one or more teams. If you don’t manage anybody, you can still run through this exercise with the projects and tasks you’ve been given.

I’d recommend you do this using a spreadsheet: You’ll want ways to sort the information you gather for the exercise. I wrote an app to help me with it, and I’ll share a little about that in an upcoming entry.

1. Make Your List

If you’ve ever tried to do the Getting Things Done approach to task management, you know that one of the first things you’re supposed to do is get everything out of your head and into a list. That can go a long way to helping you feel less overwhelmed right away.

What goes onto the list is going to vary by the kind of work your team does. Since I manage services organizations, I tend to break the team’s work down into these areas:

  • Customer commitments: The teams and projects we’re supporting.
  • Professional practices: The actions we layer on top of the basics. For a writing team, for instance, it might involve multi-stage editing.
  • Team maintenance: Things the team does to maintain itself, e.g. professional development, maintaining and developing tools and processes, etc.

You definitely want to include the things you’re doing or have committed to do. You should also include the things you want to do but have no current plans for, and things you’ve recently refused to do.

It might be helpful to add a column listing who on your team is working on what. Who you’ve put on a given task is an implicit comment on its importance to you.

2. Prioritize Your List

Once you’ve got your list, prioritize it. That doesn’t mean you need to force rank everything. Aim for a simple high/medium/low/not scale. Don’t try to come up with some formula for how much of your list should be at a given priority: That’s overthinking it, and you’re going to address that soon enough, anyhow.

If you’re using a spreadsheet, using numbers for your priorities is a good idea. I’d recommend a 0 = none to 3 = high scale, because you can do math on this a little later on. For instance:

  • 0 = No priority at all. You know it’s a thing but you don’t have any plans to do anything about it any time soon.
  • 1 = Low priority. This is something that would be nice to have some day, and that isn’t at all necessary now.
  • 2 = Medium priority. This is something that requires at least some maintenance on your part as a secondary duty for someone, even if it doesn’t warrant your full attention. If it slips for a little while, it won’t cause too much pain, if any.
  • 3 = High priority. You have to actively work on this, either to build it or to maintain it to a high standard.

3. Qualify the Effort You’re Giving Each Priority

Once you have your prioritized list, you should take a look at each item and ask how much effort and attention you’re giving it. I’d recommend, once again, using a 0 = none to 3 = high scale.

There are a few ways to think about this number. Here’s a scale to consider:

  • 0 = The item in question is getting no effort at all. Nobody’s paying attention to it.
  • 1 = The item is getting very little effort. Someone — maybe not the same person every time — checks in on it now and then, there’s a long backlog of issues with it that are addressed irregularly. Quality may be relatively low.
  • 2 = The item is getting some effort. It has a clear owner but it’s not getting their full attention. Quality may be “best effort” as opposed to “high.”
  • 3 = The item is getting full effort. The person or people working on it are expected to prioritize it above other things, it consumes a significant portion of their time, and it’s being completed to a high degree of quality.

4. Think About the Disconnect Between Priorities and Effort

At this point, if you’ve got everything in your list prioritized and if you’ve recorded how much effort you’re putting into everything, you can do a little math that will help you think about the health of your priorities list.

You can assess the relative health of everything on your list by looking at the disconnect between your priorities and your actual effort. I call this “risk,” but “health” is fine, too. The main point is that you want to capture how wide the delta is between your stated priorities and the actual work you’re putting toward them.

A quick formula in your spreadsheet will do it:

item priorityitem effort = risk

  • Risk > 1: High Risk
  • Risk == 1: Medium Risk
  • Risk <=0 : Low Risk

You can use conditional formatting to make the calculated “risk” column a little easier to parse, as I did in this simple spreadsheet:

Priority Tables

I wrote a conditional formatting rule, btw, that catches things under ‘0’ and highlights them: That shows you where you might be putting more work than necessary into something of relatively low priority.

5. Talk About it With Your Team

At this point, you probably need to sit down with your team, put the spreadsheet up on the screen, and start talking through the work you’ve done so far.

This conversation is going to require a baseline of trust between you and the people on your team. If you’ve been having problems with poor prioritization, you’ll probably find that there’s a certain amount of guilt and defensiveness. Some people might be worried that you’re doing this work to document blame.

You need to make clear that you’re not using this exercise to place blame or judge people for what they’ve been doing. Rather, if prioritization has been a challenge for you, you need to own your own leadership gaps in this area. Explain that you’re looking for help to get a good picture of everything your team thinks it’s supposed to be doing, and to make sure you understand where relative levels of effort are going.

If you’ve got a few layers of management, you might want to keep this initial conversation to leads or managers, especially if you’re dealing with a demoralized team or one with a poor performer. You don’t want the “effort” question to devolve into one of individual performance. Rather, you want to have a clear idea of how much work is being done around a thing, good or bad.

For that reason, I’ve taken a stab at modeling and then shied away from things that look like story points. They just make people nervous and it slows down the conversation.

Things to ask the team include:

  • Is the list complete? Make sure you haven’t missed something, or mistakenly lumped a few things in together in a way that hides effort or complexity.
  • Is the amount of effort you recorded accurate? Sometimes you find that someone on the team has been putting a lot more into something than you realized. Alternately, you may discover something has been allowed to slide for months. Note those, move on, and if they represent a performance issue deal with them in a 1:1.

Once you’re done with this, you’ve got a snapshot of the team’s state you can use to drive conversations with your own manager.

6. Take It To Your Manager

Once your team has vetted your snapshot, it’s time to take it to your own manager for review. If you’ve got everything in a spreadsheet and have a little conditional formatting to help make it easier to scan, the conversation can go line-by-line:

  • Describe the item in question.
  • Explain why it has the priority it does.
  • Explain why it’s getting the level of effort it does.
  • Point to the calculated risk/health field and ask if it reflects an acceptable outcome for the item in question.

Your manager probably won’t agree with all your priorities, or the amount of work you’re expending on a given item. That’s great! You did all the work up to this point to make it easy to find those disconnects.

The thing you need to do, though, is think in terms of tradeoffs. If your manager wants to bump something up in priority or apply more effort to it, you should press them to explain which items you can back off on to shift capacity accordingly.

As you work through the list and make adjustments, take advantage of the spreadsheet: Sort by different columns to offer a picture of the things with the highest priority, or the things consuming the most time, or that are at most risk because of a disconnect between priorities and effort.

Once you’ve worked through the list, give it a final sort by the risk/health field, and take a hard look at the things you see as high risk/poor health. The questions you and your manager need to be asking at this point are:

  • Is this in an acceptable state right now?
  • Is there anything happening in the near term that might change this? (e.g. planned hiring that will provide more capacity)
  • Is this something we can drop to a lower priority, deprioritize altogether, or actually drop from the list?

7. Take It Back to Your Team

Once you’ve run through the list with your manager, identified misaligned priorities, made adjustments to priorities, and identified a plan to correct misalignments, make sure to close the loop with your team.

For each item that changed, talk about an action plan to make the needed adjustment. That might involve communicating with stakeholders, shifting work around on the team, or simply resolving to quit thinking about something for a while.

The main thing you want to do, though, is communicate a clear sense of permission for each thing that ends up getting less priority or effort. If you’ve been having problems with prioritization and people on the team are dealing with guilt over what they haven’t been able to do, let them know it’s okay to put those things down, that you support them in doing so, and that you’ll defend the team’s priorities and effort to your manager and the rest of the company.

8. Support and Maintain Your Priorities

Once you’ve been through this process, you have to support the work you did.

Review your list periodically: Once a month give it a look and think about each item. Once a quarter, pull your team back in and review. If things change and you need to reassess, bring it back up with your manager.

If you have some sort of progress/status reporting routine, ask everyone on the team to specifically report against the priorities on that list. They might not be doing everything on that list every week, but a section of their report should include things from that list. Work that wasn’t done against any of your priorities needs to show up in its own area because you’ll need to assess whether it was truly a one-off, or something that needs to go onto the list.

Make priorities part of your weekly 1:1s. You don’t want 1:1s to devolve into tactical discussions or 30-minute readouts, but a snapshot of the week’s priorities delivered in the first few minutes keeps everyone thinking in terms of what’s important.

Build a healthy practice of discussing priorities both on your team and with your own manager. If a new piece of work turns up, talk about its relative priority, discuss how much work should go toward it, and add it to the list so you can assess it against everything else you’re working on.

In Practice

I walked through a lot of this process earlier this year, after a bunch of frustrating conversations about headcount. My team had a long list of stuff accumulated over the years, with a section of that list simply falling off the bottom over and over, and we simply didn’t have the people we needed to do it all.

I’d already written an app that modeled who was on the team and the things they were working on at a low level (individual pages of documentation) so it was pretty easy to add a model for all the areas of concern we had and do a little work to make it present nicely.

I saw the benefits from taking this approach at several levels:

For myself, as the team’s manager, the act of getting everything into a list was so clarifying. I had other sources of truth for the work my team was doing, mostly in JIRA, but they weren’t as focused as the list.

For the conversation I had with my manager at the time, we had a way to interactively discuss our priorities and where the work was going. He ended up helping me find places where we’d been working to a higher standard than he felt was required, and provided me with some permission to offload some of that work to other teams. Some things came up in priority as a result of that shifted capacity, but we also ended up agreeing that more seniority on the team and an additional writer would help. Some things he’d put on me he realized he’d stopped caring about, and we dropped them.

For the team, it was helpful to see the results of that discussion. They could see that a constructive conversation was happening about their commitments, and that my manager and I had agreed some things weren’t sustainable at their current level of effort.

Priorities Farmers

It gave me an opportunity to express to them in very clear terms that the snapshot we’d described was something of a contract I’d honor.

One of the more senior people on the team said the hour or so that went into the initial review of priorities and the ensuing followup were the most useful meetings he’d been in, because they helped him finally understand the things he could stop worrying about after years of having them on a mental list.

Services orgs get a lot of incoming tickets telling them what they “should” be doing, and the people filing those tickets aren’t always mindful of the things they’re piling onto someone else’s plate. Having a prioritized list published somewhere that was easy to point to also made it a lot easier to educate people around the company about our work and priorities.

Finally, the exercise has been useful for having headcount conversations both up and down. When we recently had to consider trading some eventual headcount away in favor of a big overhaul of an aging toolchain, we had a source of truth to turn to. In the absence of a new team member, we had some stuff that was in a state of marginal or poor health that might have to remain that way. Was it worth it? We had a way to validate our hunch that it probably would be, and even a way to see the ways in which some things in the “no time soon” backlog would probably be helped along more by better tools than more people.

Next Steps

I’ve recently turned my attention back to that app I was working on. I spent some time over the weekend isolating the priorities model from the pieces specific to a tech writing team, then nesting those priorities inside a team model. That has all resulted in a much smaller, easier to maintain prioritization tool that can account for multiple teams.

With a little more work and a few more models, it will be able to support a multi-level organization. The ideal end state to me would be recording something like OKRs at a high level, then associating team-level priorities to those OKRs and modeling in health metrics.

For now, I’ll be content to get it to a point where it can be shoved out onto something like Heroku, where anybody could set up a single team and step through the prioritization exercise.

If you’re interested in playing with it, drop a line and I’ll either show you how to run your own instance, or give you an account on a stable machine once I’ve pushed it up to one.

Writing About Things

I pushed v1 of a little project up to a new puddingbowl subdomain this evening.

Things is meant to scratch a few itches:

I’ve been meaning to redo this site as “a real site with a blog attached,” I’ve been wanting to not use WordPress anymore, and I’ve been wanting to write things that aren’t blog entries. Things only satisfies one of those criteria right now: It’s not WordPress. There’s not much content on it at all, and of what there is, one of the things is a repurposed blog entry.

Anyhow, here’s why I think I’ll like working on it:


I wanted to start writing reviews about things, and I wanted to try to do better than a lot of informal reviews I end up stumbling across when I’m trying to learn more about something. When I was trying to learn about standing desks a few years ago, I kept coming across all these reviews written from the perspective of someone who’d been using one for all of a week. That didn’t help me understand the products, and it really didn’t help me understand what you’re in for with a standing desk.

Reviews in general are kind of like that. I’m really thrilled when I come across one where the writer is circling back on their initial review months later, or simply hadn’t bothered to write about the thing at all until they’d had some time with it. Most of the time, though, you’re getting initial impressions. It’s that way from commercial sites because they’re under pressure to have those early impressions out. It’s that way for personal sites because people mostly seem to want you to know they have a thing, and they don’t often care to come back around and note that it was a bad purchase, or that it broke and they threw it out, or that they just don’t care to use it anymore.

So, the core of Things will be me trying to improve the situation for anyone considering purchasing a thing I happen to own and wanted to write about: I want to come back to each one I write later on and offer the long-haul perspective on it.

The reviews I write get a score based on how long I’ve owned a thing. So, for instance, my initial review of a Schwinn Loop folding bike—which I’ve owned for less than a month—gets a lower score than my review of the Quicksilver, which I’ve owned for just shy of a year. I could figure that out for myself and periodically update the site by hand, but it’d be better to automate that.

That’s where the backend comes in:


I was introduced to Jekyll as “a static site generator built on Ruby.” If you’re like me and maybe had several Rails projects behind you when you first heard that, you might think things like “oh, cool … I bet it uses ERB or maybe even HAML for templating!” and you got a little excited over that.

Jekyll very pointedly does not use Erb or HAML, and after almost three years of coming in and out of contact with it in a professional capacity, I don’t really want much to do with it in my spare time.

Middleman is a static site generator built on Ruby, and it does use HAML right out of the box, along with a few other pretty nice things. I’m having fun with it.

One of the ways I’m taking advantage of having HAML templating is in the review templates: I put the date I bought something I’m reviewing in the metadata of a review, and that changes the visual presentation of the review. So that Loop review has a red warning box, and the Quicksilver review is a sooting blue.


So, that’s that. The reviews (such as they are) are the featured content. I’d like to move some of my tool- and things-related blogging from here over to there, and I’d like to start building sections about tools I use a lot over time.

I also want to use what I’m learning building out little features here and there to redo this site. That’s gonna take some time because I don’t want to use somebody else’s pre-packaged theme.

That’s kind of what got me on this kick: The theme for this blog dates back to when Blueprint was the new hotness in CSS frameworks. Someone bundled it up for WordPress, I poked at it a little to personalize it, and here we are. I’d like to climb just one level up the ladder, to using Bootstrap and HAML to put things together. Still someone else’s CSS framework and all the rest, but it’s just a hair bit more I can play with.

org-mode Face Lift

Menubar and usr local bin emacs q Dropbox org omnifocus org usr local bin emacs zsh 159×34 and Init File GNU Emacs Manual and Preview of org mode Face Lift

I realized a couple of days ago that part of the reason OmniFocus and Things feel better compared to org-mode is that they’ve got a much more pleasant visual design: There’s way more room, screen elements are better differentiated, and they present with a variable-width font. So I did some poking around in Cocoa Emacs to see if I could clean up org-mode a little. There’s no particular master plan here, just some things that made org-mode look nicer.

If you’re looking for the quickest wins, the first three (picking a better theme, hiding leading stars, and using org-bullets) make a big difference right away and work in both Cocoa and console Emacs. They don’t involve any fiddling with faces. The fourth (opening up the line height) works on Cocoa Emacs and definitely helps a busy file feel a little more scannable; and it’s also fiddle-free.

A Nicer Theme

The flat-ui theme gives Emacs a more muted palette that’s similar to the one OmniFocus uses. Stick it in your .emacs.d/themes and invoke it with:

(load-file "~/.emacs.d/themes/flatui-theme.el")
(load-theme 'flatui t)

Hide Leading Stars to Declutter

You can turn off the display of all the asterisks in a heading but the last one:

(setq org-hide-leading-stars t)

Use org-bullets

org-bullets gives you the ability to change the way the asterisks used in org-mode present on the screen. The defaults aren’t great. I ended up using normal bullets for level 1 and 2 headings (which are equivalent to folders and projects in my own org hierarchy) and open circles for lower levels (which are usually todos for me).

Downplay “DONE” and Similar States

I set the face for org-done to bright black and the weight to thin to help push completed items to the background. I often squirrel notes away under information gathering todos, so I don’t like to completely archive a todo until the project is complete. By muting the display of done items, they’re still there and searchable, but they don’t compete with active TODO items when I’m scanning my list.

Open Up Line Height

It helps to open things up between lines a little:

(setq line-spacing '0.25)

Differentiate With Size and Weight

You don’t need to go bananas. I gave the highest heading levels a small bump in size (:height 1.2 for level 1 headings, :height 1.1 for level 2) and helped them stand out by setting their weight to semi-bold. I sized metadata faces down to :height 0.8 (org-tag, org-date, org-special-keyword) and also made the tags face less dark, which reduces the sense of clutter and makes tags more scannable.

In the process of changing these faces, I learned a new trick I can’t believe I’d missed in the past: Place the cursor over a given element in an org file and use the command customize-face, and Emacs will present the face of the current text you’re on as the default argument. That makes it easy to visually identify what you want to change and quickly jump to its customization page.

Use Variable Width for Headings

… and maybe the body.

I explicitly set the typeface for headings to Helvetica Neue, and I’ve been using this hook for org-mode:

(add-hook 'org-mode-hook (lambda () (variable-pitch-mode t)))

It sets the body type for any org-mode buffer to variable width. The drawback of variable width type is that it breaks some indentation (since Emacs still thinks in terms of fixed-width characters). The advantage is that it’s a little more pleasant to read. I haven’t made up my mind about it yet.

If you do end up using a variable-width font for everything, don’t forget to explicitly set the face for org-table to a fixed-width choice.

All that gets you to here:

Menubar and omnifocus org and usr local bin emacsclient t Dropbox org omnifocus org emacs zsh 159×34 and Emacs Set Line Spacing and org mode Face Lift

Review It in a Terminal Window

Because it ought to be able to work there, too.

Menubar and usr local bin emacsclient t Dropbox org omnifocus org emacs zsh 159×34 and Preview of org mode Face Lift and org mode Face Lift

In a Gist

If you’d like these to play with, I put them in a gist for easy cut-n-paste inside a custom-set-faces block in your own init.el:

Ripley and Newt

Sunday Cats

This has been a pretty nice Sunday. It’s rainy in a manner that is appropriate for the latter half of November in Portland, without the damp chill that will come in a few weeks. Ben and I did our usual Sunday breakfast at Oliver’s, then came home and secured Elsa in a bedroom so we could let Ripley and Newt — our two new kittens — out into the house to explore.

We adopted them yesterday from a local PetSmart-based outlet of Cat Adoption Team. We expected to go there and adopt just one, but the lady running the outlet said they were bonded siblings and the three of us ended up thinking we liked both of them pretty well. Based on how they’re behaving, I think that was a pretty good call.

The open question was how Elsa was going to deal with the situation, so we decided to go for a gradual introduction. We put all their stuff in my office, which doesn’t see much use anymore, and let them out to wander around while we sat on the floor. After an hour of that, we let Elsa in for a brief visit. She tried to get a little close and Ripley batted her on the nose, so we saw her out until everyone could settle down again.

We tried again a few hours later, and learned that Elsa would probably prefer not to be around them, but considers any of the three of us holding or petting one of them to be a signal that it’s okay — perhaps necessary — to come sniff. That provoked more hissing and batting from Ripley, and aggrieved whining from Elsa, who is plainly torn over how to receive them.

We kept them in Ben’s room overnight, and after breakfast this morning, we herded Elsa into the bedroom so they could have the run of the house. They weren’t super interested at first, but after I came downstairs for a while, Newt — who seems more adventurous — followed. Ripley preferred to hang out on the window sill behind Ben’s computer.

I’m glad we adopted them both. After Newt and I had been downstairs for 20 or 30 minutes, Ripley began to mew a lot from the top of the stairs. Newt ran up and they conferred about the matter, then she came running back down with Ripley in tow. They’ve been poking around down here since. Ripley is pretty skittish and runs upstairs without much provocation. Newt prefers to explore, and only mews when there’s a place high up that she can’t figure out how to get to. We’ll let Elsa out of containment some time later this afternoon, once they’ve had a chance to learn where the high ground is.

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.