As we scaled the team in recent months from two to four to now seven, it rapidly became apparent we need a better system of work. What we are trying to build (a computer controlling agent designed for healthcare) is extremely complex, because;
a) it’s never been done before, so there is a very high degree of uncertainty as a whole, and
b) it has multiple individual uncertain interlocking parts, each of which interacting uncertainly; AI models interacting with software interacting with the clinical environment and interfacing with an unclear and ever-changing regulatory environment. It feels a lot like trying to play the video-game “project management” on Platinum difficulty, blindfolded, having never even seen the controller.
Pre-raise we were constrained by the size of our team (just Chris and I really) and the resources we had access to; we just built as much as we could. This constraint forced us to genuinely think hard to find our way through the maze, and as a consequence we made great progress.
Post-raise however this has become much harder, simply because there are so many different roads available to us now. Similarly, expanding the team has given us an incredible resource, but every additional team member requires another order of magnitude of interactions within the company to get stuff done.
So in summation; more money, more problems.
Therefore, we need a system.
I was first exposed to Scrum when I ran a charity during the pandemic. For context, myself and four other co-founders founded HEROES (now called the HWF), raising >£1m in just a few weeks and standing up a world-class team of volunteers, eventually raising £3.2m in that first year and delivering to over 500,000 healthcare workers. The charity work was diverse to say the least, we did everything from building bespoke PPE to creating a bereavement fund for the children of healthcare workers that died during the pandemic to study at university (which I’m most proud of). One of my co-founders was a highly experienced senior executive, and as part of our team we had a certified Scrum Trainer, that created a Scrum culture from near-enough day one. Learning from both of them was like an accelerated MBA masterclass on steroids.
It was probably the most intense learning experience of my life (perhaps excluding Entrepreneur First itself), but the pace and scale of delivery in that time was undeniable. Even though it felt like chaos most of the time, we kept a remarkable level of alignment and execution throughout.
So these last few weeks at TORTUS, we have now been officially moving over to Scrum. As a quick explainer for those that don’t know Scrum or haven’t come across it before, here is the TORTUS’ version for context. We are working in two week ‘Sprints’, from Monday morning to the following Thursday evening (with the second Friday off for recovery). We plan the Sprint on a Monday morning – essentially looking at everything we are planning to ever build or do (the Product Backlog) for the user, and prioritising and sizing each item in terms of effort.
Each item is a ‘story’ of how the user will experience the work item e.g. ‘as a physician, I want TORTUS to transcribe my consultation so that I save time and can focus on my patient’ etc. The Team then choose from the top priority items what we can get done in this Sprint. Once we’ve decided what we’ll do, we crack on with it, reviewing the work every morning at a daily stand up. On the 1st Wednesday we look through the Backlog to add new stories and reprioritise. The 2nd Wednesday we do a product review and invite physicians and other stakeholders to look at what has been completed so far. The Sprint ends on the Thursday at 5pm and we then do a retrospective on the following Monday morning, identifying one thing to improve for next time.
We have only really just begun trialling this process out, but here’s a few thoughts on process so far.
- ‘Just Say No’
I used to think that focus is just about forcing yourself to concentrate on one thing at a time. I now believe focus is actually about just getting rid of as many as those other things as possible. We’ve set ourselves just three, big goals for the next 12 months, but within that the search still feels too wide. What I really like about Scrum is the Sprint cadence. “Here is everything we’d like to do, stored on the Backlog, but for the next two weeks we will just focus on these one or two things.” We as humans are really bad at protecting our own attention so it’s my job to give everyone permission to ignore everything else while they get focussed on one or two things at a time. - Everybody on the bus
The other thing I’m really liking about Scrum is that the Team decides themselves what work they can get done in the Sprint. We trialled a little of the Delphi* approach to calculating effort – it was incredibly useful to bring out what everyone knows about any given story. It also allows the team to self calibrate for the Sprint and set their own goals. - Process vs productivity
The flip side of adding process is that even at our stage of team and complexity of product, we could potentially just talk about what we are going to do for the entire week. So we constantly have to balance time on talking versus doing. I’m trying a quick rule of thumb heuristic to think about ROI;
– if we spend X hours on a process that requires the time of Y employees, we need to get back XY hours to be a justifiable ROI on time. For example, we spend 2 hours in a planning meeting with 4 people – we need to then save at least 24 hours of work as a company to justify that meeting, e.g 16 hours. - Make Efficiency Visible
It’s hard to visualise ‘using up’ time as a company, even though it’s our most precious resource. I remember possibly an Andy Grove thing where he would calculate the cost of every meeting he attended by the hourly salaries of everyone attending. I tried to find an app that would do this, but couldn’t, so GPT4 and I whipped up our own. (Download code from my GitHub here, executable only for Mac*.) Will try this on Monday and see how it goes! - Unknown unknowns
The biggest part of our difficulty in balancing time spent on exploration vs execution is uncertainty – if we were building a house every part of the build is a tested and known quantity (e.g. pipe laying, electrics, plastering etc) and therefore Scrum becomes an exercise in lego building and reacting to new problems during the build – ie known unknowns. For us, nearly every one of the building blocks themselves (our core AI models, the corresponding software systems, compliance, regulatory, QA) are relative unknowns as well, now and into the future. So we have to not only try to account for this when building product today, but also for the technology and regulatory frameworks of tomorrow. - De-risking
Our main goal therefore has to be to find and de-risk our biggest uncertainty or risk in any given Sprint. While this sounds straightforward, in practice it’s quite hard to prove a risk has been meaningfully reduced. So one of the ways to ground this, and a big part of Scrum, is the Product Review. On that second Wednesday we bring in our network of clinicians to the office, to come and play with what we built during that Sprint. In the fog of uncertainty users are one of the best ways to tell us we are going in the right direction. - Gamification
We have quite a lot of work to do – so we are trying to make it fun. An advisor recommended we name each two-week sprint after an alcohol or a chocolate so we are starting Sprint Aperol (Sprint Bacardi next time etc) this week, with an obvious bar order waiting for us if we are successful in two weeks. We also gamified some of the compliance work – we’ve named each of our compliance badges after an animal. Some are now our pets, as we have already achieved these badges and therefore now ‘own’ them, so they just need feeding (e.g. DSPT – our ‘dog’, HIPAA – our ‘hamster’). This reminds us to keep them up-to-date and do the regular training. Some others are monsters out there we need to go out and tame still – (Class 1 Medical Device certification is the ‘Kraken’, ISO27001 is the ‘Dragon’). Slightly immature, but highly engaging in important but monotonous work. - People before process
Ultimately all of these processes need to serve an actual purpose – to allow us to work together better and amplify each other’s best work, while reducing wasted time. I think it’ll be a while before we find that sweet spot to match the culture we have with the way that we work, but I’m keen we iterate as fast as possible towards finding our groove, or we will flounder in the tidal wave of AI before we get anywhere at all.
Lastly, a thought on execution.
When you ask the person on the street where great companies come from, most people will probably say ‘a great idea’, and perhaps a smaller segment of people might say ‘really hard work’.
Now think about all the ‘great ideas’ you’ve ever had, and how many of them ever actually saw the light of day in any meaningful way? Probably nearly none. Ideas by themselves are almost worthless. And originality is also overrated – many great companies today weren’t original ideas at all: Google was the LAST search engine not the first, Facebook was the 5/6th major social network.
Now think of the percentage of projects you’ve worked really hard for, sweated blood for, that have gone nowhere. In start-ups, one of the hardest types of ‘project’ you can work on, the failure rate is over 90%. If extreme hard work alone was all you need for success, every single parent for example would be a multi-millionaire by now.
Now think of some amazing projects you’ve worked on that were hugely successful, I’ll wager that the idea was not that original and the work actually didn’t feel crushingly hard – everything came together because the team worked hand-in-glove, worked with minimal wasted effort, pivoted together when needed, and smashed it out of the park. This is what great execution feels like.
So now we have the right team (hiring), on the right bus (culture), we need to get the engine into gear and actually drive it somewhere. I’m sure there will be some bumps before we really get going, but we will get there.
