How I Spent 17,784 Hours in 5 Years as a Startup Founder

Sam Corcos, co-founder & CEO of Levels, shares a detailed look into exactly how he spent 5 years building the company, with reflections on what changed in the transition from very early-stage to scale up.

Outline

It’s a bit weird to see five years of your life plotted on a chart. But many years into relentlessly tracking my time, I’ve gotten used to it. When every minute is accounted for, there's no room for self-deception about where your time actually goes, or whether you're truly focused on what moves the needle.

With that, here’s the chart for exactly how I spent my time working on Levels for the last five years:

5 years' worth of time spent on Levels

Hitting the five-year milestone, I was certain the data would show dramatic shifts from our two-year check-in. After all, the leap from pre-seed to Series A changes just about everything. You have more folks on the team, more customers, more complexity. It certainly feels like I spend my time differently than those early chaotic days.

But the numbers tell a different story. Take team management, for instance: Even with triple the number of direct reports, the time allocation in this bucket barely budged year over year.

As the product matures, the customer base expands and the team grows, it seems inevitable that the founder spends their time further from the nucleus. Less coding, more strategy discussions and 1:1 meetings. And yet, that’s not been my experience.

The burnout fallacy

Before diving into the data, let’s get something on the table: Admittedly, I work a lot. During the peak of our seed round fundraising, I averaged 110 hours a week. I haven't had a single month in more than five years where I've worked fewer than 50 hours per week.

But no matter how many hours I’ve worked along that 50-110 scale, I’ve never seriously flirted with burnout. This is not thanks to some sort of burnout-banishing superpower. Over time, I’ve come to hold one simple truth: burnout is only loosely correlated with hours worked.

In fact, as I reflect back on the data, it might even be the opposite. The times when I’ve worked the most on Levels were the periods where I was most inspired by the work I was doing. I’ve seen similar patterns play out with founder friends of mine.

Burnout is much more tightly correlated to working on things that suck your energy than the number of hours worked. You can work 10 hours a week and still feel like you’re burning out if what you’re doing for those 10 hours is quite draining.

With this as my guidepost, I’m extremely diligent about spending my time on the things that give me energy. That means making space to get into the codebase and write software, batching my meetings so that I have more open space in the day, and blocking off time for strategy and writing.

That’s not to say that 100% of my time is spent on tasks that bring me energy. There are plenty of periods as a founder where you have to just grind it out on activities that you don’t enjoy. For example, there was a point in time where we had to clear out some of our technical debt, transitioning from our hacked-together system for running the company (with no database, no source of truth, and mostly a bunch of spreadsheets) to an actual database. That meant manually reconciling discrepancies between thousands of orders.

Looking back, was it my favorite 50 hours I’ve ever spent working on Levels? Far from it. But it was a finite activity, so I could live with it knowing that returning to more energizing work was around the corner.

Takeaways:

Do not accept that some degree of founder burnout is an inevitability. Be relentless about spending your time on the things that give you energy and propel the company forward.
As the saying goes, if you find yourself in a hole, stop digging. I've found that it's important to make space to reflect and consider what my priorities should be on a regular basis.
It's also ok to not feel inspired all the time. When those waves come, I make some space, do some reading and reflecting, and think further ahead.

Don’t take a hiatus from the codebase

Here is a story that will probably sound all too familiar to a lot of founders. In the early days, I devoted many hours of my time to writing software, building the MVP alongside a few other developers.

But then, around that first year mark, I stopped writing software and started passing the baton to the product, design and engineering leaders on the team. Meanwhile, I shifted more of my focus to growth, operations, strategy and recruiting.

I took about a two-year hiatus from the codebase. This was a costly mistake that was quite painful to undo.

This led to completely overhauling how we approached engineering at Levels — but first, you need to understand how we got here.

Time spent on software development

Engineering Era 1: Pork Tacos (2019-2020)

We call our first era "Pork Tacos," named after our most memorable early bug. In our first release, every single meal logged showed up as "pork tacos" because I'd forgotten to remove a hard-coded test value. (It was fine — almost nobody was using the product at the time and we shipped a same-day fix.)

Looking back, this era was magical. Our velocity was insane. Our process was beautifully simple: Ship fast (often messy), get immediate feedback, iterate overnight. No PRDs, no endless planning meetings, no bureaucracy. Just our small team of 10, talking directly to users, and pushing code.

A lot of the most popular (and foundational) features in the Levels app came from this time period. In fact, the hastily-written code for many of these features is still in the app today, largely unchanged. Sometimes I'll spot some questionable code, run git blame, and laugh when I see my own name from 2019.

But eventually we hit a threshold. The feedback we were getting from our customers was too incremental — we spent too much time reorganizing how things were laid out in the app and debating color schemes instead of shipping breakthrough features.

In other words, we needed to take a bigger swing and the conventional wisdom was clear: It was time to professionalize our engineering org. Time for experienced managers, proper PMs, and a real design team.

That’s when everything started to break down.

Engineering Era 2: Corporate (2021-2022)

At 60 people, we weren't exactly Fortune 500. But "corporate" perfectly captures what this era felt like. More managers. More layers. Bigger product teams and an ever-expanding design org. All while our revenue struggled to justify our bloated headcount.

What happened next was all too predictable: Velocity ground to a halt. Two-week projects ballooned into three-month ordeals. We drowned in pre-work, specs and planning meetings. We’d spend months building in one direction, then change direction without shipping anything. Or worse, we'd ship features nobody wanted and celebrate our "wins." Meanwhile, our app was becoming a buggy mess.

Our product and design team had grown to 12 people, nearly matching our 13 engineers. I'd publicly stated that I wanted to maintain a 1:5 product-to-engineering ratio at minimum. We'd done the exact opposite.

The consequences were severe. Our support team flagged critical issues, but nobody moved. Why? Because in our beautiful new org chart, nobody felt truly responsible. Product teams could flag problems but couldn't fix them. Engineers had devolved into code monkeys, robotically implementing whatever specs landed on their desk.

There became a huge disconnect between what our customers were saying about our product (“it’s getting worse”) and what we were telling ourselves (“it’s getting better”).

There are a lot of idioms to describe how I was feeling around this time: treading water. Pushing on a string. Screaming into the void. But looking at the data, I have no one to blame but myself. It’s easy to see from reviewing my time from these couple of years that software development was not my priority, and it should have been.

The Reboot

You can't fix terminal bureaucracy with pep talks and OKRs. I took control of software development and laid down an ultimatum: Hit 15% month-over-month growth, or we’d reduce the size of the team.

The target was aggressive but achievable — and we missed it. We needed to take action and reduce our burn, while we still had cash in the bank to turn things around. So we took drastic action: dismantling our entire product and design org. Instead, we’d make use of contract design help and lean on our support and engineering teams to make product decisions.

This was, in part, inspired by the “responsible engineer” culture at SpaceX — and our goal was to get back to an environment where engineers are major decision-makers. In tandem, we also elevated support within the company, giving them significant input into our decision-making process.

Engineering Era 3: The Scientific Method (2023-present)

Sometimes the oldest ideas are the best ones. We rebuilt our entire development process around the scientific method — the same approach that's worked for centuries, and largely the same ideas from the book “The Lean Startup.” Every project starts with a clear hypothesis. We build to test it, measure the results, share what we learned. Anyone can propose an experiment, but I personally review every hypothesis that might touch our product.

Every time we learn something new, we write up a retro, share it with the whole team so everyone can benefit from what we learned and agree on next steps.

Everyone in the company, regardless of their role, must talk to a customer at least once per month. That includes every engineer and executive.

Projects that used to take months now take days. Huge waterfall projects now get shipped incrementally with feedback from customers along the way. The app is stable, performant and bugs get fixed quickly.

That’s not to say everything at Levels is perfect — we still need to get better at working cross-functionally and avoiding the “waiter-chef” dynamic that Brian Chesky talks about. Rather than making products and features and then handing them off to marketing to figure out how to sell them, we need to get marketing involved in the process earlier to guide what we build.

Takeaways

During Era 2, I knew there was a problem. I had lost touch with the people making and using our product. But I didn’t have the courage to do what needed to be done. When I would make an effort to get back into the codebase and the product development cycle, or even just talk with customers again, I would hear from the leadership team that my involvement was disruptive and I should let them do their jobs. I didn’t push back strongly here, because I was too busy listening to conventional wisdom — likely because it leaves less room for criticism.
I continued to place my focus in other areas of the business — which was a huge mistake. I had allowed myself to become the passenger and not the driver of my own company. It wasn't until I made the drastic change that I felt like I was running this company again.
We no longer hire pure “managers” at Levels, and we probably never will again. The managers we hire need to be capable of performing the tasks of those they manage. If they manage engineers, they need to be able to write excellent software. If they manage marketers, they need to be exceptional marketers themselves. Hire people who can be “button clickers” instead of finding someone else to click the buttons for them.

Ditch your rote 1:1s

Here's a number that should break everything we know about scaling startups: My direct reports tripled from 6 to 20, but my time spent on management didn't budge much at all.

Time spent on team management

This is quite atypical compared to the grumblings I hear from other founders. Usually, the story goes, that the further along they get in scaling, the more of their time gets eaten up by team management. More people means more meetings, more check-ins, more time playing therapist and mentor.

But the biggest unlock for me was inspired by how Nvidia CEO Jensen Huang manages his 60+ direct reports (far from the management golden rule that no leader should have more than 8-10 direct reports). Instead of being a mentor first, he's a decision-maker first.

Here’s how I made that decision-oriented approach happen at Levels:

Delete Every Recurring 1:1: Yes, all of them.
Create Living Documents: Each report gets a Notion doc. Have something to discuss? Add it to the doc.
Meet Only to Unlock: When decisions need to be made or bottlenecks cleared, that's when we talk.

The result? Meetings that actually matter.

Now when I sit down for a 1:1 meeting, I know it's because something critical needs attention: A product lead wrestling with feature direction. A support manager making the case for team expansion. Real decisions that move the business forward, not status updates masquerading as management.

Takeaways

Let me be clear: This isn't a universal solution. It works for me because I also over-communicate everything. What I don’t say in meetings, I write in memos or voice over in Loom videos.
Make space for other leaders on your team to have different approaches. Our Support lead, for example, has a much more hands-on management style. And he gets fantastic results — it’s been inspiring to see the folks in his org who have grown from entry-level support to highly-impactful leadership roles, largely thanks to his mentorship. While decision-oriented management works well for reports to the CEO, others managing earlier-career folks might need a more traditional structure.

Put strategic work in a time box

Looking at five years of data, something surprising emerged: Despite writing many Notion pages worth of memos (as my team can attest), I spent just 5% of my time (924 hours) on strategy work.

Time spent on strategy

This runs counter to what I hear from other founders. Many get consumed by endless planning sessions and strategy offsites. Others, especially early on, find themselves too busy fighting fires and playing whack-a-mole to think strategically at all.

So from the very beginning of Levels, I borrowed from Bill Gates’s Think Week concept.

The basics of Think Week: Block your calendar, don’t take any meetings or calls, put your phone in Airplane mode — just think and write. (OK, I’ll sometimes sneak one hour of email each morning, but that's it).

While Bill Gates would take these Think Weeks twice a year, I upped the cadence to quarterly, which works better for our pace of growth. And in the five years of running Levels, I’ve never missed one. I can’t overstate how important this practice has been to ensure that we’re making good decisions as a company. Every Think Week I come back with a fresh perspective that changes the trajectory of the company in some way. (I've written a detailed guide for anyone interested in implementing this practice here.)

For example, the memo I discussed earlier with the Software Engineering reboot (and the 15% MoM growth goal we needed to hit) came from a Think Week where I realized that we were not on the right track. After failing for many months, it wasn’t until I zoomed out and thought deeply about the problem that I realized how dire the situation had become.

Setting aside the full week proves essential for this practice to work. The first few days, I find my thinking still anchored in tactical problem-solving. It’s not until days four or five that I can fully detach and realize that winning might mean going in a completely different direction entirely.

When I’m working on a project, all I obsess over is how to do that project more effectively. Think Week allows me to step back and consider if we should even be doing the project at all.

Alongside these focused bursts of strategic thinking, reading remains a constant thread through my work. I aim for about 100 books annually mostly through audiobooks these days.

Admittedly, the number of life-changing or company-changing insights per book has gone down over the years (and at some point it starts to feel like most business books use the same ghost writer with a degree in behavioral economics), but I still find it useful. Many of my best ideas came from reading something that was seemingly unrelated to the problem at hand within the company.

There are an unlimited number of problems in startups. Identifying what problems are worth solving and which ones you just have to live with determines whether your company succeeds or fails.

Takeaway

The daily pressures of running a startup make it tempting to postpone strategic thinking. But creating dedicated space for long-term thinking isn't a luxury; it's essential. The key is treating this time as sacred as you would any other critical meeting, protecting it from the constant pull of Slack notifications and daily firefighting.

Take investor relations beyond board meetings

Back when I did the two-year reflection, I flagged raising our Seed round as one of the major spikes. Early-stage fundraising is a grind, especially if you aren’t well-established.

Since that checkpoint, we’ve raised both a Series A and an opportunistic Series A extension, neither of which completely took over my calendar in the same way the Seed round did. Both were only about 15% of my time, I was spending far more on sales and operations.

Time spent on investor relations

Context matters here: Our Series A landed during the peak 2021 boom cycle. We didn’t even put together a deck — we sent out a long-form Notion doc and closed the round with minimal meetings. While we had encouraging traction, macroeconomic timing certainly worked in our favor. The subsequent extension came together efficiently when existing investors expressed interest in increasing their positions. The Series B will likely demand more time — markets have shifted considerably since then.

This approach to fundraising stems from a lesson I learned the hard way at a previous startup. We’d bootstrapped it for the first two years before starting our raise with just three months of runway remaining. We figured we’d get the process done in a couple of months and then we’d have plenty of money — at least that seemed reasonable at the time.

Cash itself is an asset — the less you have, the harder it becomes to raise more. The ideal time to fundraise isn't when you're running out of money, but when you have momentum.

This philosophy shapes our ongoing investor relations. I maintain a steady cadence of about five investor meetings monthly, which serves two purposes: keeping a pulse on market cycles and nurturing relationships. A lot of fundraising happens in cycles, and it’s important to know how things are trending. And when it comes time to raise significant capital, these aren't cold conversations — they're extensions of relationships built over months or years.

I’m also relentless about activating our networks with clear asks for how they can help the business (detailed in my piece for Lenny’s Newsletter). In return, I send extremely thorough monthly investor updates, covering everything from email subscriber growth, support response times, and SEO keyword tracking. We’ve made many of these investor updates public to share our learnings with other builders.

Takeaways

A flashy pitch deck won't save a struggling fundraise. I've seen countless founders obsess over design and formatting, convinced the perfect slide layout will unlock investor interest. They’ve gone through their 10th revision and hired several designers and consultants. But at the early stage, investors primarily evaluate three things: team, market and early signs of traction. For perspective, here's our seed deck and Airbnb's.
While positioning and storytelling matter, the best way to raise money is to build a good business.

The reality of running a startup while starting a family

The data from these past few years reflects more than just the rhythms of a startup — it captures a profound personal transformation. Marriage, and then the arrival of our first child, rewired my relationship with time.

The numbers tell a clear story: When I was single, my working hours regularly stretched between 90 and 110 per week. That shifted to 50-70 hours when I got in a serious relationship, and has settled into a consistent 50-60 hours since becoming a father.

Having written extensively about productivity over the years, I frequently field questions about how fatherhood has affected my output. The assumption seems to be that babies, with their wonderfully unpredictable schedules, must wreak havoc on productivity.

Honestly? I don’t think it has.

Yes, empirically it has reduced the number of hours I put into Levels. Admittedly, I don’t really have hobbies — so once I had family, the only time available to claw back was time previously going into Levels. But I've reallocated those hours rather than lost them.

I used to spend a lot more time doing email, going to conferences and collecting context from across the company. But now that I’ve reduced the time I commit to Levels, I’ve cut out most of these low return-on-time-spent activities. Instead I try to hyper-focus on the activities that matter most for the CEO to do, like steering major company decisions and strategy.

I've always viewed productivity through the lens of intentionality rather than hours worked. By that measure, my productivity remains steady.

Takeaways

Life changes like marriage and parenthood will inevitably reshape your relationship with time — but how you respond to that shift remains a choice, as is everything in life. Yes, there will be unexpected schedule disruptions (the dreaded "nanny called in sick" message comes to mind) and so the correct answer is to adapt instead of trying to fight it. How we spend our time changes during different life stages, and that’s ok. We shouldn’t expect everything to stay the same as it was in our 20s.
There's no universal formula here — each founder needs to find their own balance based on their priorities and circumstances. What matters is being intentional about the choices you make.

Looking ahead

Five years of data tells a story of what was, and it feels like a cliche to say it, but the only real constant in running a startup for five years is change. Changes in life, changes in business strategy, changes in team — everything evolves. What happens when we hit 100 employees? 500? The patterns that worked at 50 people won't necessarily translate.

The data from these first five years has been useful for me because it captures our journey from founding through early scale and gives me an empirical record of my priorities. But the next five years present entirely different challenges. How do you maintain startup speed with enterprise-scale operations? What's the right balance between being in the technical weeds and steering the broader vision?

I'll keep tracking every 15-minute block, not because I expect to find the perfect formula, but because the data keeps me honest about the tradeoffs ahead. The next five years won't just be about working differently — they'll be about choosing differently.