Let’s Talk in 2017

tl;dr: I’m taking a little break from social media. I hate the thought of missing a direct tweet or private message from you on whatever platform we have accounts on together, so I’ve put some contact details at the bottom.


I’ve been taking a lot of pictures lately. Probably more than I ever have.

I’ve been taking pictures for a long time: My first job after college involved photography to go with my reporting, so I learned how to get decent results with a film camera, and I learned some darkroom work. I’ve made it a point to have a camera with a few more features or settings than I know what to do with since Ben was born, and I’ve hated going on a trip or vacation without having a camera along for about that long.

A few years back I set aside my mid-consumer range dSLR for a premium point-and-shoot rangefinder. I wasn’t sure how I’d deal with having a fixed, relatively wide lens but it turned out okay.

This year I decided to upgrade. I got a mirrorless, interchangeable lens camera out at the high end relative to anything else I’ve ever bought. I love it. It’s as close to my ideal camera as anything I know of, and I’ve enjoyed shooting with it more than anything I’ve had since my Canon PowerShot G5. When I see something in the light I can make the camera see it, too. When I just want to grab it and go to take snapshots, it lets me do that. When I choose to be patient and take along a tripod and trigger, it rewards my patience. It’s a few steps ahead of me, which has pushed me to learn more. I’m taking it with me almost everywhere. Photography has become what I want to do when I have any time to do anything, and it’s something I want to get better at.

Something I’ve been thinking about the past few weeks, though, is that I haven’t been giving myself a ton of space to form my own thoughts about my work.

A friend recently observed that photography is great for me because there’s an emotive/artistic side and there’s a deeply technical side. It’s very easy for me to get pulled into the technical side, whether it’s optimizing the gear I use, figuring out how to automate or speed up a darkroom workflow, or figuring out how to best distribute an image. I love the combination of an iPad, SD card reader, Lightroom Mobile, and AirDrop. It’s really easy to capture, edit, and share an image from the Max or over lunch.

The other side—the artistic one—is harder to enumerate. I don’t understand it very well yet, and I need to learn and practice a lot more. I’ve started looking for teachers and people who are willing to let me practice the kinds of photography that involve humans with them.

I’ve also started thinking a lot more about what I’m trying to do outside of “capture an image competently,” and what it means when I take a picture, or when a picture survives the gauntlet it ran from previsualization to capture to “flagged as a keeper” to edit to printing/sharing/etc.

And I’ve also been asking myself about what I’m after at the print/share/etc. stage of the process.

So there’s one set of thoughts. Now for another:

My diary app recently started kicking up “on this day” entries from a few years back, when I went on a social media sabbatical. I was pretty unhappy with the state of my social brain. Everything went from being a vague impression still sloshing around in the limbic system to a tweet or a post somewhere, but with a layer of self-editing that really bothered me because it felt reflexive and unconsidered. I’d stop when I’d catch myself doing it and ask myself why I was doing it, and I never liked the answers. So I deleted all the social apps on my phone, deactivated my accounts, and turned off all the mail notifications the more obnoxious services will still send you when they can tell you’re not “engaged.”

I’m not going to try to sell you on doing that. It wasn’t like I experienced some sort of creative renaissance. I did just stop sharing everything for a while, and that meant I didn’t have to waste time wondering why I was sharing the way I did, or wondering what sort of reaction something I’d shared had elicited. I felt like I had a certain amount of mental space I hadn’t had in a while.

After a while, I drifted back in, and began the cycle all over. This past year has had its own set of challenges, and I’ve started to feel a growing disconnect between the person I am and the person I’m sort of performing on social media. I once read that younger folks usually take a break in the form of walking away from their accounts, never to return. They just establish a new account and build a new set of friends/connections, leaving behind their old identity. I don’t like the thought of that because I hate the thought of being read as having unfriended/unfollowed someone when I really just want to get a break from all of it, but I think I need another pause, so I’m going to take one. Here’s how to reach me:

  • Mail: mph at puddingbowl.org
  • Skype: michael_hall
  • Google Hangouts/Talk/Whatever-they-call-it: pdxmph
  • Signal: Please drop a mail and we can exchange info.

Management Training

If I speak in the languages of humans and angels but have no love, I have become a reverberating gong or a clashing cymbal. — 1 COR 13:1

There’s a certain amount of pressure on the professional at some point in their career to create a Medium account and engage in some self-marketing. I found an old draft of a scuppered attempt at that while going through the digital shoebox that is my Evernote account, and realized that’s not going to happen. We have one Rands in Repose and that is enough.


  • Today I learned a piece of good news about someone who once worked for me
  • I recently took some time off and got to talk about work to people who don’t see me at work
  • I shipped a book of koans off to a friend and selected a few that meant something to me, including one that touches on this topic

So, I’m going to share the anecdote I had in Evernote that was meant to be the core of a Mediumesque post on my tenure as a manager and instead use it for this much more distilled set of ideas I want to get off my plate instead of turning them into some awful “Stirling’s Gold” series:

I was out in the field at Fort Bragg on a week-long exercise. The chow truck came around to our site and everybody lined up. One of the soldiers in my little operations group ran up to the front of the line, filled a plate, and ran it back to the First Sergeant, who was sitting in front of his tent. He took the plate, set it inside his tent, and walked over to me:

“I need to talk to you, Hall.”

“Sure, Top.”

“Don’t ever let that happen again.”

“What’s that?”

“Fixing me a plate. Never, ever let one of your soldiers fix me a plate again.”

“Top, Private Goyer was just …”

“Don’t do it.”

And somehow I got it. I’m embarrassed that I got to the age of 27 before I learned that lesson.

Funny to write it out, but I think First Sergeant Rhodes and Shanley Kane would get each other. And speaking of her, go buy her book, even if it’s just to read “Values Towards Ethical and Radical Management.” She’s got way more useful stuff to say than I was ever going to waste on Medium.

Alien Architectures

I thought I’d give an ASUS Chromebook Flip a shot as a low-cost, novel alternative to an iPad Pro with a keyboard. After playing around with a Dell Chromebook 11 last year, I got to know the world of dual-booting Chromebooks.

The Flip itself is pretty neat. It feels sturdy (aluminum body), has a decent enough display for what it is (not Retina, a notch better than the Dell’s, touch-sensitive), and it can convert into a tablet by flipping the screen back. Load up the Beta channel of ChromeOS, and it can run Android apps natively alongside ChromeOS apps, which is sort of cool.

My thought was, “tiny, rugged, cheap writing and coding device” vs. the iPad Pro (sort of large, expensive, and you can write on it but coding is tough).

Sadly, the Flip uses an ARM CPU, which immediately makes things a bit tougher if you’re going to try to put Linux on it. For instance, it was no problem to get Trusty installed via Crouton, but the ARM architecture means some things aren’t readily available (e.g. a Dropbox client). The only distro I could find with docs for dual-booting was Arch Linux.

On the ChromeOS side, there was some stuff to like about it:

The Amazon Cloud Reader app worked well when it was in tablet mode. The Android app support made it possible to play Hearthstone. I was curious how fast it would run and it wasn’t bad: More smoothly than on a first-gen Retina iPad mini. It was nice for browsing around news sites in tablet form.

On the negative side, the touch support for ChromeOS feels a little off. Google Inbox isn’t great in tablet mode (which feels like the natural mode for it), and if you’ve ever tried to use Gmail or Google Calendar proper on an iPad, you now how bad they are in a touch interface. I also hated the on-screen keyboard. I haven’t taken the time to figure out what the difference is between it and the iOS on-screen keyboard, but my accuracy on it was terrible, even when typing slowly.

So, I think I’m going to wipe it and send it back (or pass it along to someone who has appropriate expectations for this kind of thing). It was interesting to fiddle with, and it helped me think about what I’d really like in a portable computing device. iPads are still a hair too locked down for my tastes. The new Yoga Book sounds sort of amazing and strange and closer to what I’d like.

I also wouldn’t mind someone finally coming out with an iOS terminal app that can support mosh, which allows a level of persistence in an ssh connection that makes whether or not you’re locally running your Ruby interpreter or Emacs instance less material. The last iOS ssh client to provide that was iSSH, but it’s no longer under development.


I like keeping track of tasks in OmniFocus (for now) and I like to keep notes in Evernote (most of the time). I don’t like keeping notes in OmniFocus outside of a few quick jots to add context to a task.

This afternoon I was setting up a series of tasks that will require some research, links to assorted pages, links to notes within Evernote, and some other stuff that further busted my willingness to keep notes in OmniFocus, so I came up with this script.

What It Does

It takes your currently selected OmniFocus task or project (henceforth referred to as “the item”) and makes a new note in Evernote with it. That note has a few characteristics that are useful:

First, the source URL of the new Evernote note is the application URL link of the item. It looks like this in Evernote:

Evernote Premium

That means if you’re in the Evernote note and need to find your way back to the OmniFocus item, you can just click that link and away you go. You can find that link in Evernote for mobile by tapping the note’s info button.

Second, it sets an Evernote reminder that matches the due date of the item. If you use reminders (doesn’t everybody?) then you will have a tidy list of notes that are associated with (and linked to) your OmniFocus items readily available.

Third, it prepends the new Evernote note’s link to the OmniFocus item’s note, so that when you’re in OmniFocus, you can easily find your way back to the Evernote note.

Making It Easier to Use

OmniFocus will let you save scripts in its script folder then set them up as buttons in its toolbar:

  1. Make sure you have the directory ~/Library/Application\ Scripts/com.omnigroup.OmniFocus2
  2. Save the script below into that directory.
  3. Open OmniFocus
  4. Right-click on the toolbar and select “Customize Toolbar …”
  5. Look for a black-and-white script icon with the name of your script.
  6. Drag that icon into the toolbar.

You can make sure it’s working by selecting a task or project and clicking the icon. In this case, “working” means:

  • A new note in Evernote is created with:
    • a title matching that of the OmniFocus item
    • a link back to the OmniFocus item
    • a reminder set to the due date of the OmniFocus item
  • A link to the Evernote note is appended to the top of the OmniFocus item’s note.


  • It’ll bomb if you try to do this with an OmniFocus context.
  • It is stupid and doesn’t care if you’ve already done this with the existing project or task: You’ll just get more links added to the item’s note, and more Evernote notes will be created.

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:

Please be considerate of my neighbors

So, here’s a scenario to try on:

You’ve just woken up in your tent down on the Springwater Trail.

You climbed into a sleeping bag the night before. The temperature was headed down to the low 40s. You’re sleeping in a tent among dozens of others in a similar situation. The small ad hoc community around you has all sorts, including  people who seem angry all the time, and young men who are dressed much more nicely than everyone around them. They don’t spend the night: They just make a few deals and then head home for the evening.  If you’re a woman, there’s a better than even chance you were assaulted within 72 hours of beginning your life outdoors. Since it’s April in Portland, it’s muddy and wet. You might have gone to sleep to the sounds of people fighting or yelling at each other. You probably woke up because it’s really goddamn cold, or because your children woke up with the light, the way little kids do. 

So, about the time you’re unzipping your tent, grateful that nothing happened to it or you or maybe your family the night before, a pair of people on expensive bicycles, all kitted out, ride by. They look around at all the tents, and one looks to the other and says “Jesus Christ, this is fucking disgusting.  Who the fuck are these people?”

Well, friend, they’re my neighbors. I ride by them every morning on my way to work, and again on my way home each evening. I’ve got a pretty simple protocol for making my way through the little community that has sprung up on the Springwater near 82nd. I’ll list some of its key elements:

  • I slow down. There are a lot of people down there, including families with small children. Nowhere I need to be is more important than any of those people. 
  • I don’t gawk or comment if I’m with someone. I wouldn’t want to be gawked at if I had to live in a tent along a trail. I wouldn’t want someone to loudly wonder “who the fuck” I was, or comment on my “fucking shithole” accomodations. 
  • I say “good morning” or “good afternoon” to the people I do make eye contact with.  That’s my practice with just about everyone I pass on the trail. 

I’d really like to believe that the “Jesus Christs” and “who the fuck are these peoples” are coming from a sense of deep moral outrage that we live in a country where families with little children, the working poor or anyone else for that matter has to live in a tent in the mud along a trail on the edge of town. Because I read nextdoor.com and the Facebook groups for my neighborhood, I know that’s not always the case. At least sometimes they’re also coming from a place of deep revulsion with the people in those circumstances themselves, and from a deep desire to erase them from awareness … to push them out of view with no regard for where that might be or what it might mean for them. It comes from a place of rationalizing the existence of that kind of misery that comes from ones own precarity (though maybe that’s not so true of the people on the nice bikes out for a pre-work ride). 

Wherever it’s coming from, I’d really appreciate it if you’d keep it to yourself next time. Those people are my neighbors and I want you to be kind to them. 

Priorities v0.6

I got to spend a few hours on Priorities over the weekend. I put one thing back that the older app had, and added something new.

The thing that went back in was a conception of “effort” and a calculated combination of “effort” + “support” that yields something I’m calling “burden” internally, and “cost” in the UI. I could change it to one or the other, but I haven’t made up my mind which I like better, so I’m keeping it that way so the sense of misalignment will eventually spur me to a decision.

The idea of “effort” and “cost” is to capture the idea that not all goals take the same amount of work. By adding up the effort expended to work on the goal, and the level of relative support it’s getting, you can reflect a sense of what it actually costs to work on that goal.

The new thing I added is a little dashboard for goal health on each user’s home page:

Goals status

It’s just a simple tally of the number of goals in each state of health (good, medium, poor, unknown). If you’re using Priorities with other users who’ve shared lists with you, the tally shows up in your “Shared” list of lists, as well.

I guess there’s one other change: I’m assuming postgres for the app db in all environments. There are instructions in the database.yml file for how to set up sqlite as the db backend if you’d prefer that.

Source, as always, is up on GitHub. I’m also hosting a version I’m happy to share with others. Feel free to ping me if you’d like to learn how to get a login.

Priorities v0.5

Oh, feature creep.

So, last I wrote about it, I’d put together this little prioritization tool based on some thinking I’d done about priorities. I reused a bunch of code from a previous project to get to a sort of “good enough” state.

Then I started thinking about the ways you could extend that model into a bigger environment, like a company, which has several organizational levels besides “teams.” So I did a huge cleanup of the legacy code in Priorities and started work on something that would be more appropriate to modeling goals in a really large environment.

In the end, though, I realized a few things:

  1. I don’t really own that other project anymore. I mean, it’s “mine,” but I’m sharing it with people who’d like to do more with it.
  2. The places I was taking that other tool were being shaped by the company I work for.
  3. The thing I set out to do with Priorities was meant to be really simple. There are ways to extend the idea, but they leave the tool in a place where it’s harder to approach for someone who isn’t working in the same company as me.

So this weekend I just started over with Priorities. Since I’d been working on an alternate app that needed a bunch of the old Priorities code cleaned up, I had a pretty decent set of models and templates, so it was really easy to reuse a lot of the thinking, but keeping the new version to something quite simple.

The older version of Priorities, the one I wrote from all the legacy code, lives in its own branch now, since I learned at least one person had downloaded it and was using it.

The new version is in a new master branch on the project. For this version, I did a few things:

I changed the “Team” model to “Lists.” Not everybody’s managing a team. You can still name a list after a team, or whatever you like, but by talking about “lists,” it’s more of a tool for anybody, from a sole proprietor to a company.

I also began working toward making lists private. The old version let everybody see everybody else’s lists. The new version will still allow that, but you have to go looking. Once I get the basic features polished up, I’ll take a pass back through to require ownership to view a list. Once that’s done, I’ll work on allowing owners to set their lists to be public. For now, the app guides you toward just looking at your own stuff.

There’s a little help if you’re a new user and don’t have any lists set up:

Priorities Home

There’s also a prompt once you make a list and don’t have any goals:


If you’re interested in giving it a spin, you’ll need Ruby and Bundler on your system:

  1. sudo gem install bundler (no sudo if you’re using rbenv or rvm)
  2. Download Priorities from GitHub: git clone https://github.com/pdxmph/priorities.git
  3. In the download directory, install the needed gems: bundle install
  4. Set up the database: bundle exec rake db:migrate
  5. Run the app: bundle exec rails s
  6. Visit the app in your browser.

Since it’s running in dev mode, it’s going to be sort of slow on load.

The TODOs are pretty simple at this point:

  • Do more to ensure the privacy of individual lists.
  • Clean out the remnants of the old team model.
  • Put it somewhere private but not secret so people who don’t want to run their own instance can use it.

Then there are a few things to think about:

  • Adding info pages for each goal.
  • Adding notes for each goal.
  • Adding back the comparison data for goals.
  • Figuring out if there’s value in expanding the user model to have “groups” for shared lists.

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.

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