Introduction

Too many founders fail for avoidable reasons. This is why I wrote this book. There are enough things that can go wrong that are out of our control. The last thing your company needs are complications, headaches, and disasters on top of what you’d have to deal with naturally.

This is your survival guide. This is not a cookbook. There are no recipes or step-by-step instructions. Instead, I will show you how to avoid the worst and most common mistakes I see founders make when hiring and working with software engineers.

Many readers will be alarmed by my warnings. They will have heard of big companies or unicorn startups doing exactly what I caution against. If you are a big company or a unicorn startup that can afford to keep doing what you’re doing, by all means, don’t let me stop you. This book is not for you. In nature, there are plenty of plants and mushrooms that are poisonous or deadly if not handled correctly. The fanciest Japanese restaurants in the world may serve pufferfish, but that’s not an invitation for you to try making it at home. Many founders blindly copy famous tech company behaviors and needlessly suffer for it. I’ll point these out.

Above all else, one thing has become clear to me: Founders struggle to hire and retain senior engineers. Many seem to think that their troubles will disappear if they can make that happen. The truth is that engineers can behave as seniors or as juniors, and this is largely unrelated to their technical skills. It’s up to you to create an environment that encourages the behaviors that will make your company successful and eliminates those that will derail all meaningful progress.

If you try to measure an engineer by their years of experience with a programming language, database technology, or famous tech company, be careful. Those engineers may be capable of solving problems that you don’t have and may not want.

To counteract this tendency, I’ll show you what to look for and cultivate instead. Ultimately, if you want your engineers to behave like seniors, it’s up to you to provide and enforce the appropriate structure. Some engineers may bristle at imposed structure. They want to eat ice cream for dinner and stay up late. When I was in the development trenches, I was like that too. However, engineers like my old self can cause too many distractions and deliver too little value if not channeled appropriately—no matter how “talented” they are.