The other day a developer in my team asked, “So what’s your plan for…” and then described a particular organisational and technical challenge that several of us had been discussing on and off for a while. It was something that I was pushing forward, but I didn’t have all the answers yet. Of course, I was honest, and I said I had “half a plan”, which roughly went along the lines of:
- Here is where I want us to get to;
- Here is a draft of some of the things we’ll need to do;
- Here are some rules or principles for getting to that point; and finally
- Several of us need to get together to review of this and improve it further.
“Ah,” said one of the group, “a plan for a plan.”
It definitely wasn’t a full plan, and some people might be uncomfortable with a plan for a plan, but I am actually very comfortable with this. Here are three reasons why.
First, I’m quite comfortable these days with uncertainty. As part of that, a couple of years ago Matthew Leitch and I wrote an article called “How does a risk expert behave?” and we outlined several scenarios in which one person might deal with uncertainty much better than another. Indeed, some might turn uncertain situations to their advantage. None of us are risk experts in all fields, but some people manage certain situations well, and we can all learn. One thing we mentioned in that article is that many people who are good at dealing uncertainty recognise uncertainty and will consult others about plans. I took a leaf out of that article. Consulting others helps ensure a plan is more robust.
Second, it’s agile. By itself that’s almost never a good justification for anything, but in this case it’s just a shorthand way of describing the scheme of creating a plan, taking small steps which deliver value, and continually adjusting that plan. I (and the team, in this case) are quite used to that way of working, so we understand it. It’s also a good approach to dealing with uncertain situations.
Third, this approach fits with the recommendations by David Allen in Getting Things Done, a very well-regarded approach to task management which I (roughly) follow. One of the key ideas there is to focus on doing just the next step, not the whole thing, because the whole thing can be overwhelming. Step by step we achieve our overall goal.
Back with our development team, I believe we will successfully deal with the challenges that face us. And we can make progress, even without having all the answers.