I’ve spent 4 years going from non-technical founder/CEO to reasonably technical founder/CEO…along the way I learned a ton of “business guy don’ts” that are common mistakes non-technical founders make that hurt engineering culture. Here are some of the biggies to avoid:
1) Don’t ask how long something is going to take to build. Just because you don’t understand the scope of the feature or build for which you are advocating doesn’t mean you are exonerated for your ignorance. You have to make an effort to get better at understanding the scope and challenges of software development even if you’re not programming yourself. Instead of asking how long something will take (which teaches you almost nothing), ask how hard something is to build and where the challenges are. Listen to the answer, understand which components are unknowns and which are easy plugins. It’s so disrespectful not to invest the minimal energy required to start answering your own questions…and you will suck as a CEO or founder if you can’t get a grip on the pace and predictability of your product cycles.
2) Don’t ask your engineering team to help you set up email on your iphone. Just because you don’t want to put the effort into googling “how do I set up exchange on my iphone” doesn’t mean it’s ok to ask your engineers to do it for you. Again, totally disrepsectful…these people on your team are Stanford educated computer scientists, not IT guys…one, it’s disrespectful of their time and two (and more importantly) it shows a lack of willingness to make yourself (even slightly) more technically competent than you are…just because you didn’t study C.S. doesn’t mean you get a “freebe” when it comes to anything with an on/off switch.
3) Don’t spit out every single product idea or feature idea you had on the walk to work during your morning standup. It’s great that you’re creative and thinking toward the future, but you’re engineering team has a very full plate all the time…each cool idea you have represents serious time and effort from the team…there can be a feeling of “we are already overwhelmed, you’re not appreciating the challenges of what we’re working on right now.” Very important to communicate what we’re building toward and to have an open dialogue about new ideas and directions, but how and when you present that information as well as how clearly you indicate importance and where in the roadmap these new ideas lie is super important to be mindful of.
4) Recognize and celebrate the wins (even if they aren’t customer facing). This can’t be bullshit…it’s not just “oh, today we say good job because you’ve been working so hard)….actually understand what the hell people are grinding on day in and day out…if someone has been working on deduplication for the past month…what are the metrics that we’re measuring progress based on…how are we doing, what’s good and what’s great? What are the approaches that others have used? Where’s our innovation? Did we do something smarter than state of the art? Understanding the build with this level of intimacy allows you to know where special things happen on the engineering side. When they do, we stop and show appreciation and respect. The sales guy who brings in $100K gets celebrated all the time because everyone at the company can comprehend his contribution…it is essential that everyone at the company understand the contributions of our engineers.
5) Minimize interruptions. Control yourself when you have ideas or questions that you want to discuss with your engineering team…just because you just thought of something cool, doesn’t mean it’s the right time to tap an engineer on the shoulder…not every engineer is the same, but many appreciate uninterrupted time to get through a challenge or problem…wait until the headphones are off or you are walking to lunch to discuss whatever you wanted to…tap an engineer on the shoulder every 30 minutes while their editor is open and you will officially be the worst person in the world
6) Don’t fake the funk. Pretending you understand things that you don’t is the worst. Don’t sit down with a new recruit and talk about the awesome technical challenges associated with your product if you have no fucking idea what they are and why they are interesting…just saying “obviously was have some awesome big data challenges” rings incredibly hollow if you don’t even know your own stack and what challenges your engineering team is actually tackling…let your engineers speak about what’s interesting technically. “I’ll let our VP Engineering tell you about all the interesting work we are doing” rings a lot more true than your BS attempt to check the recruiting box of “engineers are attracted to hard problems, show them your product presents interesting challenges.” Further, the quality of your engineering team will sell itself…know where your competencies begin and end and be ready and wiling to defer where appropriate. That demonstrates a healthy working relationship between tech and non-tech as well. That chemistry is perceptible and a positive to outsiders if you can show you have developed it.
7) Fix your own fucking printer
