A while back, I wrote about Anti-Workflow Apps -- apps that solve problems for you without forcing you to adopt a workflow that you may never fully be able to adopt. Workflow apps (CRMs, to-do lists, project management tools) are super hard to drive adoption towards, as everyone works differently and really resists this kind of change. (of course, it's possible when the reward is super good -- e.g., slack and git/github -- bit those times are rare and more often than that an attempted re-workflow goes splat) So I've been on the lookout for Anti-Workflow tools. Solutions that solve a problem that you think requires a new workflow, but may actually be more effectively solved another, more clever way Today I want to talk about to-dos, because I seem to have found my own personal anti-workflow solution. I've always struggled with to-dos -- I've used every to-do management tool on earth, and have never been able to adopt a workable, effective system. I've tried everything from complicated tracking systems like OmniFocus to simple to-do lists of every possible flavor. Nothing has stuck. For years and years, I kept trying, trying and trying again. In the end, I just gave up and said, fuck it, I'm not using a to-do list anymore. Not going to even try. What happened was that I ended up keeping track of my priorities in a totally different way -- a way that was actually more in tune with my existing workflows. One part of the solution was pretty obvious, and one was surprising. On the obvious side: the calendar. For things that I absolutely must do, and that require dedicated time, I just use my calendar. I'm in my calendar all day long, so it's the perfect place to block out time for important things. So now I set calendar entries for myself, to make sure I set aside time for things that need focus. The calendar is good for things I know I need to do, and that I know are important. What it's not good for is capturing notes, ideas, and small to dos, which often just need to be captured in the moment and prioritized & dealt with (or not) later. This is the use case that has always drawn me back to to-do apps, to no avail. In particular, the really bad thing about a to-do list for this use case is that all it does is make you feel guilty. Items get added to the list, and whether you really need to do them or not, you feel drawn to. And then when it doesn't happen the to-do list just becomes a giant pile of guilt that you do your best to ignore (that's what happens to me at least). That brings us to the less obvious solution. What I've found is that a great way to handle both the capture / prioritization issue and the guilt issue is to use a Sparkfile. Long time readers will know that this blog is named after my favorite idea from Steven Johnson's Where Good Ideas Come From: the "slow hunch" approach to developing ideas. Another idea from that book -- unearthed by studying epic thinkers of the past like Darwin and DaVinci -- is the Sparkfile: a long, running list of thoughts & ideas. Fragments that pile on one another over time. One way to cultivate the slow hunch is not only to keep a sparkfile (in addition to other kinds of journals), but to constantly pour back through it re-reading and reconsidering your previous thoughts, ideas and observations. Turns out that this is also a pretty good way to filter inbound ideas of things to do. Just add them to the spark file, continually review the list, and occasionally do things (immediately or via calendar), and then add new stuff to the top as you think of more things. No pressure -- and absolutely no expectation -- to do everything on the list or turn it into a perfect set of priorities. Just let the mind run, capturing as you go. For me, this idea ties back into anti-workflow because I've been keeping a personal blog/journal for about 7 years now. Which was in many ways a sparkfile, though it started out slightly more long form (starting with a private wordpress blog). The big revolution happened last fall, when I switched over to using Diaro. Diaro is a personal journal tool, with both a desktop web client as well as a mobile app. The mobile app is the key, as it makes it possible to really quickly jot down a thought -- as quickly as you'd do on a to-do app, or email, or notepad. So in the end, the solution to my to-do workflow was not to add a new to-do workflow. Rather, it was to extend the workflows I already had going, calendars and the sparkfile. Boy it feels good.
John Oliver has become the most important voice in tech policy (and maybe policy in general). His gift, his talent, his skill: turning wonky policy language that makes people glaze over into messages that people connect to and care about it. Last fall, he did took what may be the most boring, confusing term ever, Net Neutrality, and made it relatable as Cable Company Fuckery. 8mm people watched that video, and it was a big factor behind the over 4mm comments left at the FCC on an issue that even most tech people had a hard time explaining to each other. Now, he has tackled another mind bending, but really very important topic: surveillance. It's amazing really. Huge, complicated, important issue. Real-life spy stories, with real life hero/villains. And no one gives a shit at all. But when you say it the right way -- in this case: should the government be able to see your dick pic? -- people light up. This is 30 minutes of truly instructive brilliance: The best part - he hands Snowden a folder labeled top secret including a 8x10 photo of his own penis. And asks Snowden to re-explain every NSA spy program in terms of "the dick pic test". On the one hand, you could argue that it's sad that policy issues need to get boiled down to "dick pics" and "fuckery" for people to get them. On the other hand, it's even sadder that the people investing time, energy, and effort in working on these issues (myself included) don't grasp that and use it to make sure ideas connect. Thankfully we have John Oliver to help us with that. This piece is brilliant -- in particular the way he opens Snowden's eyes to the extent to which people don't get this issue, misunderstand who he is and what he did, and need it to be presented to them in a different, simpler way. The major point here is that no matter your feelings on what Snowden did, it's all for naught if it doesn't trigger an actual conversation. And while it's easy for folks in the tech / policy community to feel like that conversation is happening, the truth is that on a broad popular level it's not. So once again John Oliver has shown us how to take a super important, super complicated, and basically ignored issue and put it on the table in a way people can chew on. Bravo. From here on out, I'm going to start looking at every policy issue through the lens of WWJD -- what would john oliver do -- and pick it up from the vegetable garden of policy talk and into the headspace of people on the street.
I couldn't sleep last night, and was up around 4am lurking on Twitter. I came across an old friend, Elizabeth Green, who is an accomplished and awesome education writer -- you've probably read some of her recent NYT mag cover stories, and it turns out she has a new book out, Building a Better Teacher. I know Elizabeth because back in 2008 at OpenPlans, we worked with her to launch GothamSchools, which eventually spun-out and became Chalkbeat. I said to myself: oh yeah, that was such a great project; I had totally forgotten about that. So awesome that it is still up and running and thriving. And I dutifully headed over to update my Linkedin profile and add it to the section about my time at OpenPlans. During my nearly 6 years at OpenPlans, we built a lot of great things and accomplished a lot, and I'm really proud of my time there. But it's also true that we made a ton of mistakes and invested time, money and energy in many projects that ranged from mild disappointment to total clusterfuck. Looking at my LinkedIn profile, I started to feel bad that I was only listing the projects that worked - the ones that I'm proud of. And that's kind of lame. The ones that didn't work were equally important -- perhaps more so, for all the hard lessons I learned through doing them and failing. So rather than be ashamed of them (the natural and powerful response), I should try and celebrate them. So I decided to add a new section to my LinkedIn profile -- right under my work history: Self.Anti-Portfolio. Projects that didn't work. I started with things we did at OpenPlans, but have since added to it beyond that. Here's the list so far:
OpenCore (2005-8) - a platform for organizing/activism. Hugely complex, too much engineering, not enough product/customer focus, trying to be a web service and an open source project at the same time and basically failing at both. (now http://coactivate.org)
Homefry (2008) - platform for short-term apartment sharing. Seemed like such a great idea. A few friends and I built a half-functional prototype, but didn't see it through. Maybe a billion dollar mistake. (more here).
Community Almanac (2009) - platform for sharing stories about local places. Really beautiful, but no one used it (http://communityalmanac.org)
OpenBlock (2010) - open source fork of everyblock.com, intended for use by traditional news organizations. Stack was too complicated, and in retrospect it would have been smarter to simply build new, similar tools, rather than directly keep alive that codebase (https://github.com/openplans/openblock)
Civic Commons Marketplace (2011) - a directory/marketplace of open source apps in use by government. Way overbuilt and never got traction. Burned the whole budget on data model architecture and engineering.
Distributed (2014) - crowd funding for tech policy projects. Worked OK, but we discontinued it after brief private pilot.
Looking through this list -- and there are certainly ones I've forgotten, and I will keep adding; trust me -- what I noticed was: in pretty much every one of these cases, the root cause was Big Design Up Front - too much engineering/building, and not enough customer development. Too much build, not enough hustle. Another observation is that these were mostly all slow, drawn-out, painful failures, not "fast" failures. I thought I learned these lessons way back in 2006! That was when I first read Getting Real, which became my bible (pre-The Lean Startup) for running product teams and building an organization. The ideas in Getting Real were the ones that helped make Streetsblog and Streetfilms such a big success. And they are what helped me understand what was going wrong with the OpenCore project, and ultimately led me to disassemble it and start what became OpenPlans Labs. But it turns out the hard lessons can lurk, no matter how much you think you've taken them to heart. Perhaps tracking the Anti-Portfolio in public will help.