Fix your own fucking printer (a non-tech founder’s guide to starting up)

Posted on May 7, 2012. Filed under: Hyperpublic, startups, venture capital |

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

Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

9 Responses to “Fix your own fucking printer (a non-tech founder’s guide to starting up)”

RSS Feed for Jordan Cooper's Blog: startups, venture capital, etc… Comments RSS Feed

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

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?

Zero coding start to finish

No shit! Is the history of the hyperpublic team in your blog history?

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.

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.

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.

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.


Where's The Comment Form?

    About

    I’m a NYC based investor and entrepreneur. I think there is one metric that can be used to measure the value of a human life and that’s impact. How did you change things? How many people did you touch? How different is the world because you lived in it and how positive was the change that you affected? (p.s. i don’t use spell check…deal with it) You can email me at Jordan.Cooper@gmail.com

    RSS

    Subscribe Via RSS

    • Subscribe with Bloglines
    • Add your feed to Newsburst from CNET News.com
    • Subscribe in Google Reader
    • Add to My Yahoo!
    • Subscribe in NewsGator Online
    • The latest comments to all posts in RSS

    Meta

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: