August 17, 2022

Reflections on a Decade of Self-Employment

Ten years ago on August 10th, 2012 I wrote “Today I am Leaving Microsoft and Starting my Own Company” and cap-stoned my final day of working for someone else. Since then, I founded two companies:

I’ve learned a lot over ten years and I’m learning more every year, but I thought I’d take this milestone as an opportunity to reflect on the journey so far.

Charge for Your Products from Day One

The fundamental mistake that killed MarkedUp was not charging for our services early on. We pursued the popular venture-funded growth model at the time:

  1. Grab territory in your target market quickly and aggressively by making your service free and friction-less to adopt;
  2. Make switching costs high for your most active users - the longer they’re on the service, the harder it is to switch; and
  3. Once you have significant traction, introduce paid tiers and gradually push free users toward paid service levels.

This model has worked well in theory, but here was the flaw with MarkedUp: the Windows Store for Windows Phone and Windows 8 were ultimately unprofitable for our customers: the application developers. But because our service was free we had no data from our own users signaling “trouble ahead.” The entire Windows Store ecosystem was a financial disaster and by the time we started charging for our products, about 14 months in, it was too late: we’d burned through too much of our capital to safely pivot.

We tried anyway by introducing our new marketing automation services - but it was too little too late. We ran out of financial runway within months of launching our second “pivot” product. Even if that product had some significant traction we would have still had problems - the Windows Store was a dead-end for our customers.

To save MarkedUp we needed to pivot to an entirely different market rather than to a different service offering within the Windows Store ecosystem. We would have likely learned that no one was making money on the Windows Store by month number 2 if we had paid tiers from the beginning. The most important signal from users is dollars - everything else sits at a very distant second.

Early Stage Self-Funded Company Hiring vs. Early Stage VC-Funded Hiring

One of the most frustrating periods in a company’s lifecycle is when you’re trying to scale beyond the initial founder / founders and bring aboard your first employees. It’s easier to hire early in a venture-funded company because you have a formal growth plan, access to experienced talent you can afford through your investors, and that hiring is done in order to create additional traction.

The rules are totally different in a self-funded company because openings are financed through cash flows, not burning investor dollars. If I have $1m investor capital in the bank, a burn rate of $500k / yr, it’s linear to plot the cash impact of hiring a $120k / yr software developer especially in a pre-revenue company.

If I generate $40,000 / month in sales, on average, but I have expenses that roughly average $30,000 / month hiring a $120k / yr ($10k / mo) software developer probably isn’t going to work for two reasons:

  1. The real cost of an employee is their salary plus 25-30% - benefits, payroll taxes, software licenses, vacation, and other expenses such as training costs all add up.
  2. From a cash flow perspective, this eliminates our margin for error - and means either drawing upon retained earnings from previous years or using a line of credit to cover instances where expenses are greater than revenue. This is an extremely stressful and risky way to run a business.

That math is obvious - here’s what is not:

The “Double Burn” Effect

When your self-funded company is in an early stage founders still have individual contributor responsibilities and there’s no layer of middle management. During this stage each hire runs the risk of the “Double Burn” effect when they start.

The Double Burn effect comes from the following:

  1. Onboarding costs - this is the amount of resources it takes a / the founder to get a new hire situated and productive in their role. This includes training costs, initially high day-to-day management oversight, and reviewing a new hires’ work.
  2. Opportunity costs - those on-boarding costs come at the expense of revenue-generating activities that the founder would otherwise be carrying out; if you’re pair programming with a new developer then you’re not hitting your own software delivery targets during the on-boarding period. If you’re training a new sales person you’re probably not working on developing new marketing campaigns that will produce returns over the next two months. In a small organization the impact of these opportunity costs can be quite high.
  3. Salary costs - in addition to the on-boarding + opportunity costs, there’s the net expense of the employee.

The “Double Burn” effect comes from the new hire eating up more revenue on both the front and the backend: their opportunity costs destroy revenue generation while their real costs consume it. Larger companies with greater revenue footprints and dedicated on-boarding personnel (typically middle management) don’t have this problem, but very early stage companies do.

Ultimately companies have to hire in order to scale and if you’re self-funded you’ll have to eat the “double burn” until your organization is big enough to absorb it. There are practices and procedures that can drastically lower the “Double Burn” (shared later in the article) but the biggest risk factor is the new hire.

An expensive new hire that shows a poor aptitude, attitude, or no excitement for the role is a terrible fit for an early-stage self-funded company - you’ll figure this out before the end of their first month on the job. Fire them quickly before then (I’ve done it as early 10 days on the job) and move on.

Another approach for reducing the double burn is to aim at hiring more expensive, experienced talent. In theory the on-boarding costs should be lower as they should be familiar with many of the processes / patterns / tools you already use and, given a sufficient amount of job structure, should be self-sufficient quickly. That theory is high risk / high reward and best used when the candidate is someone you’ve had previous experience working with directly.

Employees as Generalists: Few and Far Between

One fantasy I’ve often had at Petabridge is hiring someone who can take care of:

  1. Inbound customer sales-follow up;
  2. Authoring newsletter updates to customers;
  3. Handling accounts receivable;
  4. Managing contract execution (i.e. just getting things prepped for e-signature and filing documents); and
  5. Managing some of the more labor-intensive parts of our social media marketing, such as organizing our YouTube channel.

I’ve made a few attempts at filling “administrative” positions like this, with varying degrees of success. Unfortunately, most of the candidates you’d hire off of a recruitment portal like Indeed or ZipRecruiter tend to struggle with getting one thing right, let alone five.

An example: I’ve had multiple book-keepers, including some who are CPAs, absolutely maul our QuickBooks to a point where I couldn’t get our QB balances to match our bank account balances anymore - and we’re an extremely simple business.

As a founder you start to pick up all sorts of responsibilities that emerge post-launch when customers, expenses, revenue, employees, et al become real rather than theoretical.

What works best is to group like-kinded workloads together:

  1. An “Administrator” hire should be able to handle A/R, contract execution, and sales follow up.
  2. A dedicated “Online Marketer” or “Social Media Marketer” should be able to handle newsletters and YouTube with no trouble.

Hires will succeed when they can concentrate on doing fewer things well. You should delegate work to more focused roles that do more than what you currently do (i.e. the admin could probably also be responsible for things you don’t do today such as office management or arranging employee morale activities.) This approach works much better than trying to jam all of the various odds-and-ends into a single purpose “generalist” role.

There are definitely some operators who can function as generalists out in the wild, but you’re probably not going to find them on a jobs website. They’re few and far between.

Use a Structured Management System

One of the most important sayings I’ve ever heard came from a mentor of mine at the start of my career: “all of our weaknesses are our strengths taken to an extreme.” One of my strengths is that I have a strong internal sense of direction and a good memory - and that’s served me really well when it comes to decision-making, school, and pub trivia.

However, where that strength has hurt me: I’ve never needed much of a visible organization system to keep myself organized. That “just remember and do it” model I’ve used to self-manage most of my life doesn’t work when you are trying to build an organization - and it took me painfully long to realize that.

At MarkedUp we had a management system without realizing it - a well-structured SCRUM / Kanban system I put into place on top of JIRA. We reviewed the board each Friday, made assignments for the next week, had a 10 minute stand-up over Google Meet each morning, and then just did our work. Our engineering team was the highest producing I’ve ever-seen before or since.

Our sales process at MarkedUp was not nearly as structured - there were no goals or revenue targets because at the time I didn’t know any better, and it’s no surprise that area of our business was significantly weaker than our product team.

At Petabridge we’d started off using a highly simplified Trello-based Kanban system and I still use that for myself personally to this day. But getting buy-in from the team was hard and visibility into everyone else’s work was poor. We never performed at a level I was happy with in any area of our business.

In 2021 I recognized the extent to which our lack of management systems was hurting us and did the following:

Making the goals of your organization explicit, with deadlines, and creating a system for managing the progress towards them is essential. It’s not as fun as coming up with new product ideas, but it’s an absolute necessity for keeping the organization aligned and moving in the right direction.

The other tremendous benefit of having a structured management system is it reduces every employee’s management overhead significantly - you can compare one day’s to-do list to the previous and see everyone’s contributions or lack-thereof.

Focus on Fewer, Important Things

One major dichotomy of owning a business is balancing the important with the urgent, the latter typically prevailing over the former. I have a urgent need for revenue to pay this quarter’s bills, but chasing that revenue comes at the expense of working on a marketing initiative or product that could generate significantly higher returns in the future.

Where the rubber meets the road is to cut some urgent things in exchange for working on more important ones when you need growth:

  1. Don’t try to hire any direct reports if your personal time and attention is needed to hit a key deliverable, such as the launch of a new product;
  2. If you’re in a strong cash position, maybe forgo working on a bunch of marketing and sales initiatives for current / older offerings when you have new ones in the works that will generate better returns on capital or labor; or
  3. If you find yourself working on multiple projects concurrently but not able to complete any of them, prioritize and drop all but the most important one.

These run contrary to traditional advice I’ve received from investors and peers (“never cut back on marketing!””) but in my experience it’s what works - you have to cut something to execute game-changing moves. It’s painful and it’s what you signed up for when you became a founder: making difficult choices.

In recent months we slashed our OKRs down from 3 objectives with 4-5 key results for each person to 3 objectives with 4-5 key results for the entire organization - with each key objective assigned to a single person. That is working significantly better than our previous approach as each person has fewer things to focus on. The trade-offs? Less work is occurring in other areas, but the work we’re doing in the areas prioritized by our OKRs is much more complete than ever before.

Make Things Turn-Key

One of the things I both liked and disliked about Michael Gerber’s The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It was his fixation on McDonald’s operating system for running each franchise location.

His point is intuitive - by designing the business to be as turnkey / standardized as possible you can:

On the other hand - McDonald’s makes cheeseburgers. Making a more complicated, technology-driven business like Petabridge’s “turnkey” is not nearly as straightforward as cooking a burger consistently well.

But the point is taken: we’d worked over the years to document our processes using internal GitHub repositories, Process Street, and other programs but ultimately Notion was our savior in this area.

We’ve documented our engineering standards, sales practices, email templates, marketing best practices, and organized many of our processes around each of those key business areas into repeatable templates in Notion.

Most productively, we’ve adopted a culture of writing engineering specifications before beginning large projects - that was initially met with substantial skepticism and push-back from our software development team, but now it’s been about a year and everyone can see the productivity and throughput improvements resulting from it.

You can see my Engineering Spec template here.

All of this effort revolves around decreasing the amount of expertise, oral history, and self-management each person in the organization needs - instead there’s an explicit, written system that anyone can pick up and follow. The regular meetings cadences our organization holds also keep people on track with these turnkey systems we’ve designed.

Communicate with Your Customers Frequently

One of the things I didn’t do at MarkedUp as often was communicate regularly with our customers - and that’s another way I might have learned sooner about the revenue problems our users were facing in the Windows Store, a critical piece of data that could have helped us pivot much earlier in the lifespan of our company.

Contrasting MarkedUp with Petabridge - the latter is an open source business with an active user community that creates daily activity in the Akka.NET Discord channel, on Twitter, on StackOverflow, or on GitHub. We’re able to hear about all sorts of paper cuts, growing pains, and other points of friction our users run into.

In addition to what the OSS community reports we also get feedback regularly from our paying customers in the form of support tickets. It’s irreplaceable for myself and the members of our team to interact with users and understand their issues with our products from their point of view - that’s what allows us to drive forward with massive productivity improvements like Akka.Hosting this year.

Petabridge has evolved a lot as business over nearly 8 years - nearly all of that is due to listening to what our users said they would pay for in order to make their development and operation experience easier. Never be afraid to ask for an order.

Conclusions

There’s a lot more I could share: thoughts about pricing, hiring, product development, all sorts of arcane legal and accounting bits you need to know as a founder, and more. However, my parting thought is that running your own business comes with a tremendous number of ups and downs - no one likes losing a sale, having to fire someone, or having to shutter a beloved but unprofitable product or service.

You have to have a thick skin to run a company. You can’t be overly concerned with getting credit, what your competition is doing, with how people react to you and your business on social media, or where you think you should be relative to your own expectations.

You need a vision, a plan to get there, a system to execute the plan, and people to work the system - everything else is a matter of listening to your gut, your data, your customers, your employees, and then making the appropriate adjustments along the way. If you allow your emotions to get the better of you when you’re riding high or low you’ll never succeed. Do the hard work of building experiences customers love, systems your team can follow, and systems to measure your progress and you’ll be ok - that is the essence of execution (that and, a later stage, creative destruction.)

Thanks for reading - onto the next 10 years.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..