I’m a big fan of systems. Especially the ones that promise to help me make fewer mistakes (or at least, learn from my mistakes more quickly), become more efficient, and/or love my life more. I mean, I looooove a good system. I read Gretchen Rubin’s wonderful book, The Happiness Project, and I thought: Finally! A step-by-step, practical toolkit for becoming happier! I got so excited about her gigantic checklist/grid thingy that I immediately decided I needed to make one… except that I was several months pregnant at the time, and I thought, Well, I can’t commit to planning the next twelve months. Who knows what unexpected disruptions will occur, and mess up the system? So then I put the system on the shelf until the perfect moment arrived, and – you guessed it – I have yet to create a happiness project of my own.
I read David Allen’s Getting Things Done and it changed my life… sort of. Because I don’t always have the discipline to work the system the way it was intended to be used – and when you only use it halfway, it only works halfway.
Every system, every tool, every theory – on life, business, or whatever – has seemed perfect and world-changing… until I try and put it into practice.
For a while, I thought I was to blame for this. Then I stopped trying to blame someone and decided I was more interested in digging beneath the surface-level “why” for a deeper “why”: Instead of answering the question,”Why isn’t this working?” with “Because I suck,” I chose to acknowledge that perhaps I was not alone in finding it challenging to consistently implement my perfect systems – and instead, perhaps it would behoove me to work on the points of resistance I was encountering.
For example: My two biggest challenges with using Getting Things Done (GTD) methodology are that 1. I resist doing mind sweeps (a tool for getting all of your intended actions out of your head and down on paper), and 2. I don’t make time for weekly reviews (where you look over all of your active projects and decide which ones should stay active, which should be put on hold, and which should be dropped). I resist the former because I lack the discipline to slot it into my schedule, and I resist the latter because I hate dropping projects – it feels like failure.
Understanding the deeper points of resistance – the second- and third-level “whys” – has made a huge difference to my ability to use the GTD system effectively. I now put mind sweeps on my to-do list every Monday, and I try to turn the weekly reviews into a balancing act – for every “yes” there should be a “no” (or a “not right now”) of equal size.
I’m a big believer in asking “why” more than once, in many contexts; it’s one of simplest and best ways I know of deepening one’s learning. So I was delighted when I found that Eric Ries’s The Lean Startup advocates using a process called “The Five Whys” in businesses. (You can read about what a Five Whys process is over here.)
But… I have worked on technical teams for a long time now, and while I have always loved a good project post-mortem, I have also seen a ton of resistance points to actually doing them – and doing them well. Which is why when Dan Milstein stepped up to the podium at the Lean Startup Conference earlier this week, I cheered.
What I love about his talk was that he acknowledges the human side of business, and the importance of addressing the humanity of your team members. Lean Startup methodology is all about validating decisions with data, and while I totally believe in that approach, I also know from experience that humans don’t make data-informed decisions unless our fragile human egos are in a state of equilibrium. In other words, it’s a lot easier to make smart decisions when you’re not busy stroking your own ego, or working like crazy to avoid feeling ashamed and flawed.
So how do you engage in a potentially emotional process like a project post-mortem – where you evaluate the success of the project, and attempt to identify and learn from mistakes, in a group of work colleagues – in a way that actually gets you the results you want, and avoids plunging people into shame-based behaviour? How do you work around the fact that humans’ default tendency is to want to avoid facing mistakes, and reduce the shame of fallibility?
Here is Dan Milstein’s fantastic, smart, and entertaining talk, “How to Run a Five Whys (With Humans, Not Robots)”:
His slide deck is here:
[slideshare id=15474125&doc=leanstartup5whyshumans-121203175503-phpapp01]
Thank you, Dan Milstein, for making Lean Startup work better for fallible humans.
Related: Tracking the Numbers That Actually Matter
One of my other favorite talks that day (and there were many) came courtesy of Ivory Madison from Red Room. Her talk is titled, “Bonfire of the Vanity Metrics,” and it’s all about ditching the meaningless stats many of us get attached to (what Eric Ries calls “success theater”), and focusing on your real performance indicators. Again, she manages to be both highly intelligent and engaging at the same time. Here she is on the futility of tracking your business’s Facebook “likes”:
“Is this your business model? No.
“Do you get paid for this? No.
“Is it Facebook’s business model? Yes.
“Do they get paid for this? Yes!
“Are you Mark Zuckerberg? No.”
One of the wonderful things about this talk is how candid she is about what metrics she used to use, despite knowing they had no connection to her business model. So while she doesn’t speak directly to how we can get over our own desire to make our numbers look good, she does acknowledge her own fallibility, and her process for arriving at the meaningful metrics. Highly recommended.