Through working with various founders and startups as a consultant, CTO, and engineer, I've come to appreciate a fundamental truth: learning from your own mistakes is good, but learning from others' mistakes is even better. I’ve cataloged the most common and derailing mistakes I’ve seen over the years, in hopes that you can learn from them.
If you depend on engineers to get things done, here are the key points to remember:
- Standups are a waste of time and hinder productivity instead of increasing it.
- Coding riddles don’t test applicants for the ability to build real customer features.
- Success comes from solid team players, not from mythic individuals who can do the work of 10 people.
- Software estimates are crucial for planning, coordinating, and—most importantly—ownership.
- Sprints do not guarantee better outcomes; they are unnecessary at best and actively harmful at worst.
- Devs should focus on completing projects and not just being busy.
- To make the best decisions and to avoid bias, devs should consider multiple approaches and alternatives before settling on a solution.
- Communication should happen in a way that allows information to be shared and accessible to everyone, even after team members leave and new ones join.
- Engineers must understand the company's goals, and any roadblocks they encounter need to be swiftly addressed.
- Accountability is key; decisions should always align with what's best for the business, not individual whims or preferences.
Above all else, I want you to be successful. Pay attention to what drives results and what does not. For the same reason I warn against mimicking famous tech companies, I don’t expect you to heed my warnings without thought. For example, if evidence or experience shows that sprints are the best way for your team to plan work, keep them. Just know that your process should not make you feel like a “real” tech company; it should crank out valuable software.
As you turn the final page and your thoughts return to building your company, remember that success requires an iterative process: a cycle of making decisions, reflecting on their outcomes, and making adjustments. It demands an honest and critical examination of what works and what doesn't, coupled with the courage to retain effective practices and discard unproductive ones. With this book in your hands, you're already in better shape than most founders and tech leaders who blindly follow industry dogma. Go build great things.