Leadership Learnings For Startups

Overheard At Startups By My Brain and Synthesized Here


The following is an always up to date list of insights I’ve been able to distill from working as a technical leader at 3 early stage startups and counting.

1. Everyone should strive to be student and teacher, coach and player, owner and delegate.

2. No single solution works universally for individuals and groups. It's a dynamic process, best represented by a time series and a moving best-fit curve. Bayesian methods prevail, and effective leaders minimize deviation.

3. Product should lead what to build, engineering should lead how it is built.

4. Have a minimal meeting mindset. If you are scheduling a meeting with more than one person, ensure it is necessary vs. something that can be handled async. Consider tools like Slack to have daily and weekly updates and a slackbot as a reminder for everyone to contribute.

5. Meetings kill productivity. A good rule of thumb is to have one meeting per project. Bring the RFC and the PRD to the meeting to frame it and ensure everyone is on the same page.

6. Don't gatekeep information. Enable information flow by being radically transparent to the entire company as much as possible to ensure context is there if anyone needs it. This requires trust and accountability from everyone.

7. As a leader you are responsible to set deadlines and enforce them. Track them but don't micromanage. Communicate the inevitable delays and scope changes to the product owner and other stakeholders.

8. Don't gossip. Gossip is a waste of time. It is not helpful to share info divulged in confidence. It is helpful to share your ideas and ship your best work.

9. Culture is magic. You are the magician. As a leader, show how your tricks are performed and help everyone see the magic so they can perform it themselves. Not every company has the same tricks, but everyone has the ability to perform magic given the opportunity.

10. Don't schedule regular 1:1s. They are not effective. Instead, schedule them when you need them most. This is a rare opportunity to talk about anything and everything. Wait until you have something you need to address with the individual.

11. Have just enough structure to not have mass chaos. To figure this out, remove all structure and see what turns into chaos and add in the order as needed via tools for developers, product, and management. This is easily overdone and a huge waste of time to clean up after the fact or to educate on tooling vs. shipping new features.

12. Own the mistakes, share the wins.

13. Leading is more than decisions. Decisions are 1% of the job. 99% is derisking each decision and building consensus. The best decisions appear inevitable in retrospect.

14. Lead by example is BS. Lead by doing.

15. The best developers learn by doing. The best leaders learn from mentors who have been there before.

16. In crisis, panic in private. Communicate to the team the plan out of the crisis. Execute on it calmly and swiftly with all the resources available.

17. When in doubt, do what you know the CEO would do. To perform this effectively, you need a close relationship of trust with your CEO.

18. Email is where progress goes to die. Those that rely on email are doing it to ensure they are covering their asses while doing the bare minimum. Get rid of them. Email should be reserved for external partners, clients, and investor updates.

19. Fill your team with people that are smarter than you. You will be relying on them to do the work without being told what that is all the time. Otherwise you wouldn't need to hire them.

20. Keep your team small and connected. Identify and mitigate communication churn. Slack helps a ton with this. There are always indicators and warnings of burnout and disenfranchisement, and those in the middle of it may not be aware of it.

Back to blog