Fix your own fucking printer (a non-tech founder’s guide to starting up)
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
Jordan Cooper's Blog: startups, venture capital, etc... 
Great F*cking article and love the tone, emotion and energy. I too and all about impact and we are creating a product to help consumers and companies start to track their eco-impact in the retail world. Follow more @traxactions
Keep on keepin on!
Jared
Jared
May 7, 2012
When you say that you started as non-technical Founder …I assume youn mean non-coder? .tell us more about the how much coding you did over the four years and how the process profressed?
sagacityhappens
May 7, 2012
Zero coding start to finish
jordancooper
May 7, 2012
No shit! Is the history of the hyperpublic team in your blog history?
sagacityhappens
May 7, 2012
thank you! i’ll add a few more:
8. if you want to learn how to code, go to school. you hired me to code. hire a tutor to teach you to code.
9. you read one article. i’ve been doing this shit for 20 years. respect that i know what i’m talking about and what you are talking about.
10. don’t stand over my shoulder while i’m coding and ask me how the code is coming along. coding sucks right up until the moment it doesn’t. hire a good test team to tell you how the coding is coming along. test early. test often.
11.go away. i don’t want to see you several times a day. when i do it stresses me out that you aren’t building the business.
12. get a stockbroker. don’t ask me if you should buy a tech stock. yes, i have an opinion. make a choice. pay me for my opinion or pay me to code.
13. get a personal shopper. i don’t give a shit about your wife’s sister’s kid’s birthday present dilemma.
Christine (@cag123)
May 7, 2012
Starting from the other side of the fence, I can say that these are spot on. #1 and #5 are the most important in my opinion (and the most frequently violated). Engineers will flat out quit over #2 but usually managers are smart enough to not pull that kind of crap.
Jeff Revesz
May 7, 2012
Love this post. There’s a corollary. I was a computer science major in college and taught myself to program as a teenager. But I’ve been removed from writing code for decades. When I started my career as a product manager, I overplayed my “coding street cred” with engineers, who saw me as an MBA weenie. I figured out pretty quickly to not even try. So an 8th suggestion might be – Don’t think you know anything about coding, you don’t. I see too many young folks take an intro CS class, read a few blog posts, or hack around using the latest GUI tools and then come off like they know how to develop the back end of a mission-critical transaction processing system. Don’t even go there.
Jeff Bussgang (@bussgang)
May 9, 2012
heh
jordancooper
May 9, 2012
here’s the thing i often wonder. if you are in tech and you love it, why haven’t you bothered to learn anything about it? if you don’t love it. afaic, go do something else. i’m not saying everyone is a coder or a linux guru but c’mon already, learn the basics. be conversant.
merrillbeth
May 16, 2012