Getting Stuff Done: Tips from a Year in the JHub
By James Kuht
“Ideas are easy, execution is everything”John Doerr, Billionaire Tech Investor & author of “Measure what Matters”
“Getting stuff done” (GSD) sounds so simple but is a skill held by remarkably few.
I am not talking about simply being given a task to do and completing it, I am talking about conceiving a project (perhaps taking the ideas formed from this previous article in The Army Leader), and then taking it all the way to its completion. There are always emails in the way, meetings to go to, people to chat to… and someone/something else to blame.
Below are some tips for GSD. We will rattle through how you can plot your route to success, inching your way along this route with the simple to-do list, forming a dream team to help you get there and avoiding distractions. Let us dive in.
Visualise the end-game, and plot the breadcrumb trail to get there
In chess – the most successful players are the ones who can think the most moves in advance and plot their route to achieving checkmate. Innovation is remarkably similar.
So, presuming you have a project, or a project in mind, humour me with these prompts below. Perhaps even scribble down your answers. They should illustrate whether you have truly visualised what “checkmate” looks like for your project, and the moves you need to make to get there.
What would successful delivery of your project ideally look like? When will that be?
Who will be there to deliver it? Are they a part of the project team and do they love it?
What are the major milestones along the way? Who will guide it over each of these milestones?
What are the most time-critical jobs to do over the next month to achieve these milestones?
What are the most time-critical steps to take over the next week?
This sort of future-back thinking seems so obvious, but common sense is not necessarily common practice.
In my experience if you do not do this you will simply fill your day with easy things – like answering emails or attending meetings – brainless stuff that does not progress your project. Then, all of a sudden, months have passed and you have gotten nowhere. That clear inbox is a hollow prize for your efforts.
Pick five things to achieve each day
Holding yourself to account on taking these steps is as simple as keeping a to-do list.
Try starting every day scribbling a 5-point to do list each day – 5 things that will take 30-120 minutes and get you closer to project success – and do not stop until you have finished them. Sometimes it will be 3pm (woohoo – gym/run time) sometimes 10pm. Personally, I find this acts as a gratifying yard stick of progress through the day, which allows you to hold yourself to account.
One of the first jobs that springs onto most people’s to-do list is building a team and gaining some supportive stakeholders to help them progress their project. Let us explore this below.
Minimum-but-sufficient stakeholder engagement
“Want to go fast? Go alone. Want to go far? Go together. Want to go fast and far? Go in a tribe.”Modified African Proverb [Mr Barney Green, Vascular Surgeon, added the last part]
This may counter-intuitive to many – but in my experience, the speed of execution of a project is often slowed down by engaging too many stakeholders too soon.
Without wanting to sound like an aspiring dictator, truly the quickest way to make decisions is in a democracy of one (or very few, at least). At the start of a project, when there are many decisions to be made of little consequence, this is the best option. “Go fast, go alone”.
The temptation of airing your great idea to important people early is significant (some nice back-patting) but often stifling to your progress. Each stakeholder will want to shape your proposal (if it truly is a good one) and you will soon be crippled with engaging a complex stakeholder map to make simple decisions. You will also be accountable to more senior (quantity and seniority) figures if it all goes wrong – the weight of expectation is not a good thing for a young innovation project.
Here is a suggested framework for stakeholder engagement:
- Ideation stage: if you truly are innovative, try to push yourself to dive deep in the ideation stage on your own (see Ideation: Tips from a Year in the JHub for reference), with input from others only when you have a developed idea you are ready to share. The better state the idea is in when it comes up to feedback, the better quality of feedback you will receive, and the better co-workers/secondees/stakeholders you will attract. Equally, if your idea is ill-defined you risk undermining your own credibility.
- Early project stage: Once you are moving towards getting funding, you want to bring on a small-but-perfectly-formed A-team who will take this project through the pilot stage too. “Go fast and far, go in a tribe”. Ideally it will consist of
- a doer (someone who is genuinely going to run the pilot and help develop the project)
- someone who is suitably important to give the project credibility (i.e. ~OF4).
- Ideally (but not always possible) someone who may be involved in delivering the project in the long-term – so that they feel invested from the start, and the handover after your successful board pitch is seamless (don’t underestimate this).
…this, is your tribe.
- Post-pilot stage: Once you have ran a pilot and gained some results, you are at the position where you can be reasonably confident of whether your project is a success or failure. This is the time to get the support/recognition your ego has been yearning for – suddenly quotes from 5 Generals who all think your pilot was great will be useful for the board pitch, and you want to really focus on bringing the whole future delivery team into the love-in. Beforehand it would have been a waste of their time. “Go [really] far, go in a [big] team”
Getting the best out of your team and your stakeholders
“Life favours the specific ask and punishes the vague wish”Tim Ferris, best-selling author of “The Four-Hour Work Week”
“A problem well-stated is half-solved.”Charles Kettering, Head of Research for GM 1920-1945.
Once you have assembled your team and stakeholders, there will be a variety of tasks you need them to complete, approvals they need to sign-off, and quotes they need to provide to GSD.
To do this, one of the key skills you need is to make it easy for them to say “yes” to your requests, by clearly articulating your asks. Here is an example.
When I first joined the jHub, I was in the process of launching a podcast (The Military Medicine Podcast). We needed a star guest for the first episode to launch with a bang – only problem was, I was a nobody, so how could we get one?
My boss asked “why don’t you get General Sir Chris Deverell (Commander JFC at the time) on it?”
“How?” I thought. It genuinely felt like there was more chance of getting Elvis Presley on.
Bemused, he simply told me to email the General a concise and specific ask. It felt like potential career suicide.
“It all boils down to whether they can answer with the single word ‘yes’” he explained.
The email was crafted as such. A catchy subject line, punchy first sentence, brief body, and the simple ending;
“Please simply reply ‘Yes’ if you are happy to appear on the podcast and we’ll take it from there with your outer office?’
A few hours later. ‘Yes’ appears in my inbox.
A month later we interviewed General Chris, hit Number 6 in the iTunes Chart for Science/Medicine and it is still our most listened episode.
There is slightly more to behavioural science than simply writing good emails, but honestly, it mostly boils down to making it easy for people to say ‘yes’ (or take an equivalent action). If you want to learn more about it (you should), check out Inside the Nudge Unit – they offer a 4 step guide to making behaviour change easy, which in brief, is to make an offer/action:
- Easy (i.e. frictionless)
We based the entire design of the jHub Coding Scheme on these principles and now, being the biggest coding/AI upskilling initiative within Whitehall despite not a penny spent on advertising, it is hard not to agree that this is the secret sauce to making people say ‘yes’ (in this case, to spending 20-100 hours of their free time learning to code).
Saying no gives focus – conferences/meetings/presentations/too many projects
It seems counterintuitive to progress from a section on making it easy for people to say “Yes” to telling you why you should say “No” to requests, but we are going to do it anyway
So, you have plotted the path to rip-roaring success, nailed your daily to-do list, and have assembled a great team to get help you on your way. It is a great start, but it is still going to be a bumpy ride, full of all sorts of blind-sidings and time-consuming/boring tasks (i.e. commercial competitions). This stuff is dull, but the hard yards take you the distance – it is very easy to be tempted to “look busy” by filling time with anything but these tasks.
One thing that is painful to do, but free up valuable time is, trying to go light on meetings/conferences. Especially the sexy looking ones abroad. You will have to find your own balance on this one, but mine was made very clear from the outset by my old boss, H, who, when I asked for permission to attend a conference would simply reply “does it directly increase the chance of you successfully delivering your projects?” If the answer was in any way shaky, it would be a blanket “no”.
Though this sounds limiting, I genuinely believe it to be one of the key ingredients in the secret sauce for “GSD” – going on receive for a conference for a day is easy, taking your project to the next level is not – that is why so few people have delivered hard projects although many would give you a whole bucketload of excuses…
There really is no sexy way to say it. Getting Stuff Done simply relies on having a clear aim and breadcrumb trail to reaching it, creating a dream team to help you on your way, making it easy for people to say “yes” to your requests, and remaining focus on achieving your aim.
But, having decided to GSD, you will also need a team to get you all the way to the finish. And you will have to lead them, the subject of the next article.
If you found this article interesting, read what else James learnt at the JHub in his other articles.