53 lessons I wish I knew before I started my first startup
I started Column Tax in early 2021 and sold it to Aiwyn1 in late 2025. Starting a startup was the hardest thing I've ever done. But knowing certain things makes it easier. Here's what I learned through experience that I wish I had known at the start:
Growth, energy, & momentum are the only things that really matter
Product<>Market Fit & growth are the only things that really matter: everything else will fall into place* if you have them.
- *though everything will still feel painful & hard in-the-moment no matter what.
There's no substitute for energy in. Energy in is the most important input to progress. Anything you put energy into as a founder will go better.
- You have to show up with energy every day if you want your team to.
- It's relentless, but you're the person who is going to push the pace & energy. This week, not next week. Today, not tomorrow. Right now, not after this meeting.
Momentum is everything. Work hard to build it and bring the energy. And losing it is really tough.
- Do whatever it takes to bring momentum back if you've lost it.
Your best people will dictate your progress
Finding people who can work across >1 discipline (e.g. product + engineering, design + product) is incredibly hard. Don't expect it. And if you find someone like that, hold on tight and give them lots of responsibility, regardless of their past experience/level/title2.
- If they could do [what you do as a founder], you'd be working for them, not the other way around.
The only thing that matters for how much you can get done is how many barrels3 (aka DRIs) you have. You're bottlenecked on the number of DRIs you have.
The big difference between founders & employees is the amount of ambiguity you can handle.
No employee will ever be able to do it as well as you can. But to scale, you'll have to figure out how to get others to do projects on their own.
When you find someone who is better at a function than you, hold on for dear life!
Hiring: Always Be Recruiting
It's better to be polarizing in recruiting messaging: attract people who fit your culture and actively dispel those who don't. e.g. if your company works many hours, don't advertise work-life balance as a recruiting selling point and reject anyone who mentions it during the hiring process.
You have to always be recruiting, even if it's really painful on your time.
Only hire for roles you're actually hiring for. Make sure you put everyone through a (well-thought-out) interview process4.
- Corollary: most of your hires will come too late. Try every once in a while to make a hire too early. Then, maybe by doing that, you'll hire someone on-time.
Make sure you find evidence in your interview process of being able to work at startup speed if someone has only worked at BigCos before.
Hiring an exec is hard because you want to hire someone who has done your stage before and people want to join as their prior role +1. So you have to find the balance between those.
You'll never successfully recruit someone who is considering you + AmaFaceGoogSoft. If someone is considering you + BigCo, make them make that decision before continuing the interview process.
Damn, it feels so good when you hire someone great and they take a bunch off your plate. Try to remember this when hiring is taking up so much of your time.
Sometimes if you feel like you're pushing too hard on getting a potential hire to sign with you, you might be making a mistake and they'll end up quitting quickly anyway. Use the anti-sale5 strategically.
If you plan to interview/work with your friends: either be really sure they're amazing and you know they'll do well, or be ready & willing to lose the friendship if it doesn't work out/the person doesn't perform.
Some software engineers are just so insanely productive they can be net beneficial even as part-time contractors and are worth the organizational overhead. Most aren't.
Lots of things you don't think of as skills are actually skills just like coding: people management, leadership, influence, interpersonal effectiveness, leading larger teams/projects. (e.g. Your VPE should be able to do the last one really well.)
Hiring for a first PM is so hard. Be sure to hire someone who has worked at startups before (not just big companies) and "gets it". You need someone who is scrappy, can do end-to-end product work for very ambiguous problems and is willing to implement your (founder's) vision. That's hard to find because experienced PMs often want to own "strategy" decisions.
Fire fast & performance manage well
Fire fast. By 90 days if you know it's not working. Taking longer only makes things worse. Don't make excuses to yourself to avoid this!
Like hiring the wrong manager, hiring the wrong PM is especially painful because they impact 5-10x more people than just themselves.
After X attempts, if someone can't get onboard with your strategy/decisions, you have to part ways.
When you fire someone, you'll be surprised at how badly it seems like remaining employees want an "explanation" of what happened. Unfortunately, being direct about the former employee's underperformance will make remaining employees feel "better".
Members of your team sometimes do know about performance problems, and it can drag morale down if you don't handle it.
- Other times (maybe it's if someone is in another function) your team doesn't know and firing that person will come as a surprise (and you'll have to handle the morale consequences).
Be intentional about the culture you're building
Don't start a remote company. Hire in-person.
- If for some reason, you've already made the mistake of starting a remote company, be really rigorous about building a remote culture that actually works6 (good luck!)
The quality of your managers will dictate your progress. Don't settle for mediocre managers or folks who are just good at their function but not great people managers.
Unlimited vacation sucks for everyone. Founders are mad because employees are taking too much. Employees are annoyed because they don't have clear expectations (see above about employees not being able to handle ambiguity).
Good onboarding is super important (but so boring to work on? and so hard to keep up to date? but so worth it). Onboarding sets the tone for the person's whole ability to execute. It feels like a chore to do, but is worth it because otherwise new hires are totally unproductive. If you as founder/leader don't set the culture for new folks, they'll find out the culture by Slacking their peers (which you might not want).
Building a culture where Sales respects Engineering & Engineering respects Sales goes a long way. When those feel like one team, the whole company works together well.
Communicate effectively
Don't be too transparent about fundraising with your team.
- In general, be fully transparent, but not about topics your team can't control/help on at all.
Repeat these refrains:
- What's the goal? Write it down.
- What are the priorities, in order? What tradeoffs are we willing to make? Write it down.
- How are we going to get there? Write it down.
Communicate why any time an expectation changes.
Storytelling & narrative are super important.
- As technical founders, we like to think in facts, data, and analysis. But momentum is often built through great storytelling: simple narratives that can be repeated become true and translate to easier hiring, retention, and sales.
Never DM! Work in public Slack channels. The more work is public, the less “communication” is required as a discrete job.
Have well-set public metrics that everyone can follow: these help drive focus as much as anything else. Getting these metrics right is as valuable as any other communication & storytelling work you can do.
There's something about offsites in a different location that are weirdly helpful for getting out of the day-to-day and thinking critically about bigger picture topics.
Executing as a Product & Engineering team
It's better to get very smart software engineers/PMs to become domain experts than to try to have your domain experts become software engineers/PMs.
Working with an amazing Product Designer is magical. When the Product<>Design pair is working in-sync together well, it's a beautiful thing.
Know the details of what your team is working on. It'll make you more well-respected by your team if you understand (and can speak to and help with) their struggles/work. And it'll help you make better decisions.
Setting timelines before a project is spec'd out doesn't work and unnecessarily stresses everyone out. Timeboxes are OK though.
- i.e. if you have decided-on/expected [feature set], don't set a [timeline] until you've spec'd the project. If you're OK with a variable [feature set], it's OK to set a [timebox/timline].
Everything is more complicated than you think. The world has a surprising amount of detail.
Project management, organization, and coordination/communication continue to be annoyingly important. They take a lot of time and effort. For a large complicated project, it's basically a full time job: 4-8 hours/day just to keep things organized and everyone doing the right thing.
You can drive projects really well with daily check ins, as annoying as they are.
It's hard to explain how much complexity goes into any piece of software and making it Actually Work. Someone has to be on top of those details - maybe a PM, but generally a "DRI". Without those folks, things fall apart and your software quality starts to suffer. Those people know the craziest minute detail edge case of every part of their area of the software.
Find the right balance as a founder & manager
You have to balance not micromanaging with being direct about your expectations. After living through both sides of this spectrum, I landed on: if you have expectations about the outcome for something in your head and you won't be happy unless they're satisfied, you should share them upfront so the person doesn't have to guess.
There's another tough balance between imposing your will as the founder & empowering your team. You need to find employees that are high-agency but also down to execute your will.
Make your future life as easy as possible
- Have an open source policy and make sure you just get all the correct licenses. Also be organized about offer letters, contracts, and such. A little organization7 now will make things so much easier later.
Do more customer discovery
Do 10x more than you think you need to to get customer discovery calls scheduled.
- 10x more reachouts and 10x more effort into getting warm intros to the right people.
People are surprisingly open if you are friendly on customer discovery calls.
- e.g. one time, a guy just started screensharing his internal company dashboards with us!
Take care of yourself
- Take a lot of photos. Keep a journal of lessons, big, and funny moments. You'll wish you had.
For employees: find the right industry and negotiate hard
B2B kinda sucks as a software engineer because there's always more to build and there are external timeline commitments.
- As an employee, try to work somewhere where the roadmap flows from internal instead of external, if you can.
Engineers often get screwed because they don't negotiate enough when getting hired. Business people consistently get more just by negotiating harder.
Thank you to Jon Tippens, Amy Shen, Nadia Eldeib, and Sahil Shah for reading early drafts of this essay and providing great feedback.
To get notified (extremely rarely) when I publish a new post, subscribe here:
Let me know if a piece on how to sell your company would be interesting to read!↩
Dynamic employees like this do best when given the freedom to go outside of their title/role and just do whatever was the most urgent/important for the business. Founders should not only not block this but enable it (and eventually reward it).↩
Terrible politics, but very right about this: https://www.conordewey.com/blog/barrels-and-ammunition↩
Blog post on how to create a well-thought-out interview process coming soon.↩
The anti sale is where you tell the candidate all of the reasons why they shouldn't join your company. If they still want to join after that conversation, maybe they're a good fit :)↩
See GitLab's remote culture handbook: https://handbook.gitlab.com/handbook/company/culture/all-remote/↩
My strategy: download every Docusign into an organized folder (e.g. offer letters, contractor agreements, sales contracts, etc.) once it's fully executed.↩