Leadership: Tips from a Year in the JHub
By James Kuht
In the previous article on GSD (“Getting Stuff Done”) I talked about the criticality of assembling a small-but-perfectly-formed team – this article explores how you might lead them effectively. Now I am certainly not a born leader, naturally quite introverted in fact, and am certainly not a veteran military leader either – this article humbly offers my observations of good leadership practice specific to innovation. Leading innovation projects have unique challenges. The projects are often disruptive and risky. The people you lead are specialists, often senior to you and usually volunteering their time. The pace can be break-neck.
This article starts by outlining how you can convey your mission with clarity, prioritising your team’s workload and empowering to own their tasks as they set-off to accomplish your mission, staying humble and maintaining a culture of healthy challenge.
Clarity
“If you can’t explain it simply, you don’t understand it”
Albert Einstein
“Life rewards the specific ask and punishes the vague wish”
Tim Ferriss
Innovation is often vague and difficult to decipher – people argue for hours over its definition, innovation jargon is almost impenetrable and it commonly involves technologies that are fledgling or ill-understood by many.
Given this, what struck me when I first met the Head of the jHub was the clarity of his mission for us jHub staff. He had composed a nine-word mission statement: “Capability into the hands of the user at pace” and a seven-item “operating principles” document, outlining how we were to work including unashamedly direct items such as: “Deliver results”, “Do the basics”, and “Obligation to Dissent”. It was impossible for us not to buy into this mission. There was an almost tribal belonging to a highly-motivated group of exiles doing things differently. The sheer simplicity of the operating principles was baffling to me – so glaringly obvious but so effective – having to be frequently reminded: “just because it’s common sense, doesn’t mean it’s common practice”.
Leadership lesson learned – clarity – clear vision, clear mission, clear principles.
…but this clarity did not come easily for me. I am a waffler. So what can you do if, like me, you find speaking succinctly and with clarity challenging?
Firstly, it takes effort to distil down complex ideas or new technologies to bite-sized chunks that can be easily understood by many. Start by taking inspiration from TED talks, where metaphors are often used to explain complex subjects like quantum computing and string theory in talks lasting less than 15 minutes. No offence, but your idea is likely to be simpler than either of these topics, so consider yourself lucky!
Once you have seen how the best do it, it is probably time to get some practice. The next time you do a presentation try to use a PowerPoint format such as the pechakucha format – having 20 slides simply with an image on each of them that automatically progress every 20 seconds. This will force you to truly distil your ideas down into succinct and easily understandable narrative, and also force you to memorise a talk – a great skill for improving your connection with an audience when conveying a mission/vision with clarity.
Another tip I have found useful when either debating a point or conveying an idea with clarity is to stick to the rule of 3s – structuring your argument or vision in three points. It is a common strategy employed by some of the world’s best debaters.
So, how do you get good at this? Structure your notes like this, your scripts for speaking, and your elevator pitches. It gradually becomes habitual… my triplet-prosody is now probably fairly annoying for my girlfriend. For one of my projects, a physiotherapy mobile app, this became:
“using a mobile app to prescribe physiotherapy will (1) empower patients with more ownership of their own healthcare, (2) arm clinicians with data to make better decisions, and through these two effects (3) reduce the overall time spent rehabilitating from a Musculoskeletal injury.”
Boom. Try it out. Cut the waffle and loose the hat trick of killer points. People will find you so much easier to follow if they understand your vision.
Prioritisation
“Tackle the hardest problem first”
Approach frequently attributed to Google
Having clearly articulated the mission to your team, it is important that you prioritise their tasks optimally.
Unfortunately, this does not always happen. Team leads (including me!) found it difficult to prioritise the boring-but-challenging-tasks, so progress ground to a halt just when momentum had built up. Typically; the necessity to run a commercial competition in line with EU law. Anyone who has run a commercial competition will know that it requires deep thought to get a “Statement of Requirement” right, a lot of paperwork to be completed, and a strict focus on avoiding bias and getting the best possible product at the best value for the taxpayer.
The most effective project leads seem to make a concerted decision to avoid this issue by conquering the commercial competition (or equivalent boring-but-challenging-task) first, prioritising any work related to this. The least effective leads spent time on the interesting and fun things – meeting senior stakeholders, building a prototype, or trying out kit, but simply made no progress on delivering the project.
I have had experiences at both ends of the spectrum with this. I got it right for one project I lead – a Mixed-Reality CBRN (Chemical, Biological, Radiological and Nuclear weapons) Clinical Simulation Trainer. We obsessed over creating an accurate requirement, prioritised the competition over all other work (including one 15-hour day evaluating submissions!) and strictly avoided a biased process. Now 5-months after awarding the contract we have a great product, at a fantastic price, and have proceeded to the next phase of the project seamlessly post-gaining funding. In contrast, another one of the projects I lead has been in commercial competition for 5-months after gaining funding and I am still involved despite having moved on from the jHubMed. The beers after a successful funding pitch taste so much less sweet when you know you the hard work is about to start. Trust me.
What is the boring-but-critical-task that holds back the progress of your project/team? Is it at the top of your priority list?
Do not ask people to do it, allow them to own it.
“Be strict about your goals, but flexible about your methods”
Once you have prioritised the tasks to achieve, it is important to delegate them effectively. Empowering those working for you sounds like the obvious tactic in achieving this but personally I have found it embarrassingly difficult to do. My key takeaway from this year has been that:
Empowerment is not giving someone something to do, it is giving someone something to own.
One of the team for the physiotherapy app project that I lead, R, was an academic and used to be a bit of a waffler – like me! R had a lot to offer, but pitching was not his strong suit. When the opportunity came for a 3-minute pitch to a General whilst I would be on holiday, I became rather nervous about whether R would even get past his introduction in the 3 minutes. Nevertheless, there was nothing for it. I was going on holiday so I had to leave it in his hands.
He must have absolutely smashed it, because the General immediately followed up with considerable interest in the project. Since then R has done numerous pitches and the turnaround in his pitching style is remarkable – he has owned each-and-every occasion. I wish I could take some credit for empowering him with true ownership of the task which catalysed his improvement in public speaking, but actually he can take far more credit for how he changed my approach to empowering those on the team.
Empowerment is not giving someone something to do, it’s giving someone something to own.
Humility
There is little point me beating the drum on humility in general, for fear of sounding patronising, so instead below are three (of course, three) tangible examples of humility in action that you might consider.
- Humility to ask stupid questions:
Have you ever sat in a talk/meeting where one of your team members makes a technical point which is utterly incomprehensible to you? Next usually comes the uniform response of nods from around the table and swiftly moving onto something everyone understands. “Bullshit baffles brains”.
Now this is dangerous – the devil is in the detail in innovation projects and ignoring a problem tends only to make it grow, ready to leap out and floor your project later when you have invested more time and money into it. The most inspiring leaders I have witnessed have the courage to ask the question “So if I understand this clearly you mean [x]?” – posing it in a way which exposes that they might be being stupid (in which case – great, the leader was missing something and we can all move on). More often though, this exposes a key risk to the project that was about to be glossed over, which can then be addressed.
2. Having the humility to know you might be wrong:
When you propose a solution, do you get sick of people picking your idea apart and telling you why it will not work? Me too! In fact, I find it infuriating! I have ashamedly occasionally even found myself asking how on earth the person could be stupid enough to think that! There is clearly no room for that sort of mentality in leading a team successfully – your team, critics and stakeholder have different and valuable perspectives to learn from. Here are two action points you might consider:
- When someone criticises your project, make sure to note their criticism down and really challenge yourself as to whether their point is valid or not, and what your response to it is. Chances are others will repeat their point in the future, and you should be grateful for the fact they exposed this weak-link in your project before a General did. What a gift.
- Secondly, have the humility to acknowledge that they may be right. A staunch critic of your project can quickly become a supporter if they realise that you have set up a rigorous evaluation of your project with metrics that will unarguably prove either one of you right. If then you are right, then great, they are far more likely to become a new supporter.
3. Humility to refer to the team, and not yourself:
Something I got picked up on by a colleague was referring to myself too much. “I did [x]” rather than “the team did [x]”. It might be technically true, but it sounds self-centred. Does it really matter if someone knows that you filled in most of that spreadsheet rather than your colleague? Let others sell your success.
Obligation to dissent/Class 2 arguments
Finally, we will touch on an important culture to foster within your team – that of an “Obligation to dissent”. A sense of duty within those who form your small team to speak up if they see a flaw in the plan. Innovation projects are high risk with danger around every corner, but most of these dangers can be anticipated and mitigated – only if they are brought up.
Let me share a personal example of my failings on this! When I was a fledgling jHub scout I video-teleconferenced into an OA (preliminary funding) panel. The pitch was presented well, but frankly I could not see any possibility of it delivering until 2023 – the IT infrastructure simply did not exist. jHub’s remit is to innovate in weeks and months, not (five) years. I did not challenge it in the OA, and it was passed, for a not insignificant cost.
Shortly afterwards, I called a trusted colleague to ask him what he thought about the OA – he shared my views – how on earth was this going to deliver? We wrote an email there and then, raising these concerns to the boss. It was concise and the arguments well-formed. Minutes later I received a stern response asking why on earth I had not brought this up in the pitch – that we have a clearly stated “obligation to dissent” and I had directly breached this.
I felt terrible – but it was one of the strongest life lessons I have ever learned! I am far less reserved in my feedback since… So what happened next? The project has been slow to progress since, and still has not been delivered (~18 months later) – arguably, our lack of dissent has contributed to a significant opportunity cost of a jHub scout, and potentially unnecessary spending of a significant quantity of money.
A caveat I must note here, though, is that there is a balance to be reached here, and that not all dissent/feedback is useful – picking apart every proposal with aggressive “dissent” can halt progress and damage interpersonal relationships. So how do you ensure your feedback/dissent is most productive?
Perhaps a good way to approach this is to follow lessons learned from PARC/ARPA documented in Dominic Cummings blogs of engaging only in “Class 2 arguments” – ones in which you can explain the other persons argument to their satisfaction. This leads to a well-informed and mutually respectful exchange of views which, in my observations, can be extremely productive. This environment is, indeed, partly credited with the creating the conditions that enabled the development of the internet… Mutual understanding and mutual respect.
Conclusion
So, there we have it. Form a succinct mission and convey it with clarity, then prioritise your team’s tasks and empower them to own them, rather than just complete them. Always act with humility and try to foster a culture of constructive challenge/obligation to dissent.
I certainly cannot profess haven’t mastered these, but I hope by offering some frameworks by which you might think about them you might avoid making the same mistakes as me.
One final point is to make sure to end you measure your performance at the end of the year by doing a 180-feedback survey on your leadership, sent to all your Project teams… “What you measure you become”.
If you found this article interesting, read what else James learnt at the JHub in his other articles.
This article was originally published on DrJK.com. You can read the original article here, and listen to James Kuht’s Podcast The Military Medicine Podcast here.
