View this email in your browser


At the table in the kitchen, there were three bowls of porridge.  Goldilocks was hungry.  She tasted the porridge from the first bowl.
"This porridge is too hot!" she exclaimed.
So, she tasted the porridge from the second bowl.
"This porridge is too cold," she said
So, she tasted the last bowl of porridge.
"Ahhh, this porridge is just right," she said happily and she ate it all up.
-- The Story of Goldilocks and the Three Bears
I’m not really a fan of airplanes. I mean, they’re useful – a miracle even – but the bustle of airports, the ascent, the descent… I don’t like flying. I prefer to avoid it.
Whenever I can, I prefer taking rail or ferry on medium-distance trips. Both move smoothly the majority of the time, and have typically enough space in the dining car or observation car to spread out some books, notebooks, and a computer to work leisurely.
One of my favorite modes of vacation is taking a multi-day train trip. Chicago to San Francisco on the American Amtrak, Saigon to Hanoi in Vietnam, and Beijing or Shanghai to the port city of Xiamen are my three favorite rail journeys in the world.
Being off the internet for a couple days in a row, while the train rolls gently along with scenery in the background – this has always been conducive to very good thinking for me. Before taking a train trip, I work out some complex problem or analysis I want to work on, get a couple books for reference or to read if I don’t have any other ideas, and bring a plain paper notebook with me to go alongside my laptop – there’s typically power outlets on long-distance trains in second-class or first-class.
The most effective rail journey I ever had was in 2013; the results were surprising and counterintuitive and changed how I did things a little bit forever.
It was in September 2013 on the Beijing-Xiamen route. With two full days on the train, I sat down and listed every major successful project in my life – and every single major failed project – and I started looking for what the correlations were.
I’d often heard the phrase “speed of execution” in the past – it seemed correct, obviously, that people are more successful who can get things done faster.
But, how? The answer was so illusive. “Speed of execution” was, to me, an abstract phrase and perhaps a worthy target – but very much mysterious and puzzling as to how about getting better at it.
I found the answer somewhere I wasn’t looking for it – on the long rail journey while staring out at the Chinese countryside – and gradually, I saw my success rate and speed of execution go up tremendously.
I have various stacks of old archived notebooks around the world – my notes from that fateful 2013 train ride are perhaps at my parents’ house, or perhaps at Kai’s house – I’m not entirely sure. It’s somewhere and I’ll dig it out and review it again eventually, but I remember the lessons coming through crystal clear.
I’d slowly brainstormed and mused about all my major successes and failures in life, and written down as many as I could remember. I came up with at least 30 major successes and at least 15 major failures, but either of those numbers might have been a little bit higher.
It’s interesting, you know, having a notebook in front of you with a lot phrases written that call back memories. All the while, there’s no internet, no distraction. I was listening to music and going back and forth trying to discern the patterns of what had worked for me, and what hadn’t.
I categorized different projects and endeavors – a logical cut that stood out to me is that around half of my successes were solo endeavors and half were collaborations with people like Kai or Stepan Parunashvili… but then, around 90% of my failures were solo.
That was interesting.
As I dove deeper into the solo successes, an insight wound up clicking – even four years later, without the old archived notebook in front of me, I remember getting excited and writing –
“ !!! Burst/incremental!”
Many – a majority – of my solo successes were “burst/incremental” projects that were released in little pieces. I counted, for instance, getting my blog going at and writing one blog post per day for a number of years as a success. Meanwhile, books like Ikigai and Gateless – both of which had collaborative elements – were successes, but I had a number of dead unfinished books in the failures category.
The more I looked at it, the more I found that solo projects that couldn’t be shipped in small pieces were a very rare and small part of my success – the vast majority of my successes were either in collaborations, or in burst/incremental type activities – like writing a single blog post per day, and seeing that aggregate over time.
Now, this is not the main thrust of this piece, but nevertheless I have to stop and empathetically recommend this exercise.
Clearing my calendar and having zero obligations and zero distractions for a little over two days straight, and just analyzing every major success and failure of my life – this was perhaps the single highest ROI I ever got from two days. You could perhaps go camping, go rent a small cabin, or – like me – book a long-distance train or ferry ride.
But I can’t emphasize enough that you ought to do this. It tuned my project selection criteria immensely over the past four years, and I saw my project success rate go up every single year for the past four years. Collaborating with Kai so often is a big part of that, of course – Kai has something like a 99% project success rate, as far as I can tell – but of course, I realized that certain types of collaborations were so fruitful during my time on that train to Xiamen.
Really, I can’t recommend it enough – clear the entire schedule for a couple days to analyze what’s worked for you and what didn’t…
Starting in late 2013, I drastically cut down the number of solo projects I did, and started looking to be more collaborative in my work. It helped immensely.
It took me another couple years to figure out why that was true, though. It’s not a universal truth that people have a higher success rate in collaborations than solo.
In my case, I realized that – up to that point in my life – I’d often been a mix of “too unclear” and “too clever” in the initial setup and scoping of projects – and that had set me up for failure as projects would get too complicated to ship out the door.
When engaging in collaborations, someone like Kai or Stepan or Chiara Cokieng or Zach Obront would catch these excessive complications as we were hammering out a scope of things to do, and we’d simplify the project scope.
There were additional benefits – accountability, deadlines, the ability to talk things over if something went wrong – but in my later assessments, I came to realize the #1 reason collaborations performed better was because the project scope was simplified and very clear up front.
It’s easy to start work while only having a vague outcome in mind if you’re solo, and misleading yourself into thinking things are clear enough. This error is much harder to make if someone else is getting involved.
Two reasons –
First, regular progress got made with lots of mini-deadlines getting clear.

Second, feedback from the incremental/burst work was gotten and course corrections could be made before getting oneself into a “dead end” of being stuck on some large too-clever mess of a project.
Or, said differently, why did long drawn-out projects without regular feedback often fail?
To even ask that question is to mostly answer it.
There’s some minor tactical advice to increase one’s speed of execution – for instance, I adopted the rule last year to try never to go to bed at the end of the day with more lingering small tasks to do than I started the day. If I got a bill I needed to pay, ideally I would either pay it that day, or do some other equivalent task. Don’t let things pile up. This certainly increases speed of execution.
Likewise, talking oneself into doing “just one more round” of work can help, and doubly so if you’re close to finishing something and shipping it. Certainly, it’s a hugely beneficial habit to immediately put something in the mail if you finished filling out a form, or submitting a report if you wrote or edited it, and so on.
These minor things can help, sure. As can working more hours and working at a faster pace.
But counterintuitively, I think speed of execution comes less from working harder and less from working faster than most people think – I think it chiefly comes from project selection and scoping.
Like I mentioned earlier, my frequent colleague and now business partner at Ultraworking, Kai Zau, always seemed to have something like a 99% project success rate. He didn’t work much harder than other people, per se, and he didn’t take on as many projects as the most prolific people we know… but everything he did take on, worked.
This became an ongoing series of dialogs between us over the last half-decade – me trying to decipher how Kai got to those project success rates. (To my great blessing, I mostly inherited Kai’s project success rate whenever I collaborated with him.)
Eventually, Kai came up with two terms to try to make it clear –
Is this project “Goldilocks-sized”?
And does it complete within the “project honeymoon window”?
Kai has a few unusual attributes about his working style. One, that used to drive me crazy but which I’ve grown to immensely respect and appreciate, is that he hates to do the same type of work at the same quality twice.
Whenever we succeed at something and want to do a second iteration of it, Kai insists that we slow down and spend a week or two analyzing what went right last time and what could be better, and how we could get more gains going forwards.
He’s always looking, thus, for “Goldlocks-sized” projects – not too big, not too small. Too small and we didn’t get enough gains. Too big and it could fail or be a huge hassle to succeed with the costs outstripping the gains.
Relatedly, Kai tries to finish projects within the “honeymoon window” – meaning, while the project is still fresh and exciting and motivating. The exact amount of time a “honeymoon window” is open varies; it might be one week or, rarely, as much as a few months – but Kai doesn’t like having projects that linger on. He wants the project to complete and have the gains collected before things get stale.
Let’s try a different metaphor on briefly – in investing, it’s a common truism that money is made on the buy side. Meaning, if you buy a property or a stock that’s underpriced when you buy it, you’ve already made money. Most people think money in investing is made from growth or on the sell-side – collecting the gains later – but many sophisticated investors swear by the buy-side approach. It’s a big part of the heart of value investing, as defined by Benjamin Graham in The Intelligent Investor and practiced by Warren Buffett.
As a metaphor then, perhaps a majority of speed-of-execution is made on the “buy side” – not by taking a badly-scoped project and marching it out as fast as it can be done, but rather choosing projects in that “Goldilocks-size” that can be rapidly completely at your current level of skill and resources, and which completes in the “honeymoon window” before getting difficult or particularly taxing.
If projects are chosen well, of particularly the right size, actually completing the work is still of course required, but becomes more of a formality towards getting the gains.
That’s probably too strong of a statement, because I didn’t have a great grasp on how to execute for a long period of time. This was the last piece of the puzzle needed for me – a way to ensure I was executing and completing projects rapidly enough.
Here’s what I eventually did, which worked great:
I created a spreadsheet tab and listed every project I started on it.
Immediately, I wrote the StartDate of the project.
I then created a column called DaysWorkedOn and I increased that number every day I worked on the project.
When the work was completed, I entered the EndDate.
I then had two more columns that completed automatically – DaysElapsed and AdvancePercentage.
For instance, here’s two projects I did in July:
Fitness Plans
StartDate: 8 July
DaysWorkedOn: 3
EndDate: 10 July
DaysElapsed: 3
AdvancePercentage: 100%
What did that mean? I started the project on July 8th. I worked on it on July 9th and July 10th, and finished it on July 10th. That means it took three days to complete making new fitness plans from start to finish, and I worked on those fitness plans every day.
The goal, for speed of execution, was to get the DaysElapsed as low as possible – that meant a project completing as fast as possible in calendar time – and to get the AdvancePercentage as high as possible, meaning I worked on it every single day while the project was active.
Coincidentally, I started another project on 8 July.
Edit Pragma
StartDate: 8 July
DaysWorkedOn: 5
EndDate: 22 July
DaysElapsed: 15
AdvancePercentage: 33%
As you can see, I only needed to work on editing the book Pragma for two more days than I needed to finish my fitness plans – but I didn’t work on it most of the time! As such, the project lingered longer, taking 15 days to complete and get off my plate. 10 of those days, nothing happened! This is worse speed of execution all the way around.
In fact, I daresay that speed of execution can be boiled down to just four things –
(1) Generally sound good work habits,
(2) Careful project selection,
(3) Minimizing DaysElapsed from the time a project starts until it completes, and,
(4) Maximizing AdvancePercentage – how many days you worked on a project while it was active, towards concluding it.
Well first, if you wanted to start your own spreadsheet, it would look like this –
Column A: Project Name [manually enter this]
Column B: StartDate [manually enter this the day the project begins]
Column C: DaysWorkedOn [start this at 1, and manually increase it every day you work on the project]
Column D: EndDate [manually enter this the day the project ends]
Column E: DaysElapsed [ =D2-B2+1 ]
Column F: AdvancePercentage [ =C2/E2 ]
But that’s a technical note; it’s not necessary. The general mental model for speed of execution can still be applied, spreadsheet or not –
First, good general work habits. This has been covered ad infinitum everywhere and is beyond the scope of this piece, but try not to let little admin work linger, ship things quickly, and work diligently on your first priorities from the start of the day.
Second, an important counterintuitive thing I believe – speed of execution comes primarily from project selection. Aim to get projects that are “Goldilocks” for your current skill and resource level – easy enough that you know they’ll succeed, and with enough new gains and improvements that you get at least slightly more payoffs than you did in past projects. Then, aim to scope a project so it completes in the “honeymoon window” when everything is still easy, you’re still motivated, and everything is fresh.
Third, minimize days elapsed from the start of a project to its completion. Of course, single-tracking projects helps immensely with this. But even if you have multiple projects on the go, you’re better off – whenever possible – taking a single day to march one of them to completion than to “make a bit of progress” on all of them. There’s actually some interesting advanced math on project payoffs and decay rates that support this, but it’s not necessary to know it – suffice to say, the sooner a project completes, the better off you are. If you’re going to measure only one variable about your projects to increase speed of execution, I’d recommend writing down the start date and end date and optimizing for minimizing days elapsed.
Finally, to keep yourself honest, it can be helpful to measure how many days you worked on the project while it was active. As shown above, editing my sixth book only took me two more days of working on it than my fitness plans took to design – but nevertheless, it took 15 days to complete instead of 3 days. Why? Because I didn’t work on it for 10 of the 15 days it was active. This is much more aggravating and much less enjoyable – and much more dangerous – than marching something to complete as quickly as possible. You’ll be shocked at how fast projects complete when you ensure you make progress every single day on the project, and when you choose and scope projects so that they can complete quickly.
As she was sleeping, the three bears came home.
"Someone's been eating my porridge," growled the Papa bear.
"Someone's been eating my porridge," said the Mama bear.
"Someone's been eating my porridge and they ate it all up!" cried the Baby bear.
"Someone's been sitting in my chair," growled the Papa bear.
"Someone's been sitting in my chair," said the Mama bear.
"Someone's been sitting in my chair and they've broken it all to pieces," cried the Baby bear.
They decided to look around some more and when they got upstairs to the bedroom, Papa bear growled, "Someone's been sleeping in my bed,"
"Someone's been sleeping in my bed, too" said the Mama bear
"Someone's been sleeping in my bed and she's still there!" exclaimed Baby bear.
Just then, Goldilocks woke up and saw the three bears.  She screamed, "Help!"  And she jumped up and ran out of the room.  Goldilocks ran down the stairs, opened the door, and ran away into the forest.  And she never returned to the home of the three bears.
Get your projects done quickly – and then get out!
Until next time, yours,
Sebastian Marshall
PS: I think this is one of the more useful TSR pieces in a while. Perhaps forward it to someone who might find it useful?
PPS: If you just got this forwarded to you, you receive one free long-form piece of this type every Thursday at – we’ve got some really brilliant and effective people on here reading each week – welcome onboard.

Copyright © 2017, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.