Operating Principles for Personal Holding Companies (Part 1)

While wrapping up the development of my first product under Positive Sum, I have been contemplating the principles that I aim to establish for the growth of Positive Sum in the upcoming years:

There are a few principles by which I am looking to grow Positive Sum over the coming decades:

• Short feedback loops
• Bias for action
• Focus on intelligent automation

I'll be breaking each of these down in a separate post in this three-part series, starting with short feedback loops.

Short feedback loops

I've already written about feedback loops on my blog. It's a topic I spend a lot of time thinking about because I believe it is so important. A founder who is iterating and learning every day instead of every week is learning 7x faster, which over the course of a year compounds significantly. Over the course of a decade, it's an even greater difference.

This is why I want to be shipping new features and updates to my products every day, as it's the only way to learn anything meaningful in a business context (put your ideas/creations in the real-world, and understand how people react to them).

Here's how I plan to do so:

Decreasing the speed of iterating with code

Over the years, I've come to learn of many ways to speed up development with code - larger companies require more processes to ensure that the systems they're building do not break. This becomes a self fulfilling cycle, as it takes more and more people to manage these systems.

Keeping the code in your head

With fewer people, it becomes easier for those on the team to keep a working mental model of how the code works in their head. This is under-rated because instead of taking several hours to explore a section of the code, a change can be made instantly, while understanding the implications of that change across the rest of the codebase.

Leverage type-checking using Typescript

It isn't always possible to have a working model of a codebase in your head - if there is a large codebase and you haven't worked on a particular section of it for a while (even if you were the person who originally wrote it), it can take a while to re-orient within the code.

That is where I personally find Typescript to be incredibly valuable - you can make changes to the code just as quickly, and be confident in any errors that you've inadvertently caused across the codebase to be signalled to you before deploying - this has prevented me from pushing countless bugs to production.

I predict that we'll see this taken further over the coming years, as code self-repairs  as you make changes in one part of the codebase, that have implications in other parts of the codebase, following the guide-rails that Typescript lays down to improve accuracy.

Pushing straight to production, and the use of feature flags

With a large team, this is viewed as bad practice, and for the most part, it is. But when you're working in a small team or as a solo engineer, this becomes much more possible.

With caution, this is something I've begun doing more - modern tooling makes this much more possible:

• Automatic roll-backs to a specific point in time within a database, using Supabase
• Instantly revert to any previous commit using Vercel (with no additional requirement to push or build again)

Additionally, the use of feature flags mean that specific features can be enabled or disabled independent from the code being pushed to production - this means that I can incrementally increase the % of users who have access to a feature and monitor for