I’m fortunate enough to have both a degree in computer science and a degree in business; it’s like being a Swiss army knife: you can build products and sell them too. In the early stages of a business, you need more than a PowerPoint; you need a working product. You need to put your ideas “on paper” to show folks what you mean. Something they can touch and play with and understand what you are trying to accomplish. That’s where engineering comes into play. You can just roll up your sleeves and build something. It doesn’t need to be perfect it just needs to work. From there, you can put your business hat on and figure out how to make revenues or raise investment capital. You are in full control of your own destiny: no tech cofounders that you need to woo with “equity only” compensation packages, no friend’s and family’s money that is now at risk because your outsourced developers cannot execute, and no “idea” guys that you have to work with that end up taking all of the credit.
But, these two minds can sometimes act as an angel on one shoulder and the devil on another, pulling you in two very different directions. As an engineer your thought process is much different: You won’t stop until things are perfect, reality is what is built and not “vaporware,” and esoteric details rule the day. Business people, on the other hand, well you need to deliver product now, sell the dream and the future, and think big picture, letting operations (or engineers) take over the painstaking details that are typically glanced over. You can imagine that combining these two mindsets leaves you with a Jekyll and Hyde syndrome to mess with your mind. How do you combat these issues?
Shipping Product:
There’s a fine line between a broken product and a product in progress. Windows, Office, Photoshop and many of your favorite software programs are still being updated and improved 20 years later, and they still inevitably crash! Engineers want to make sure the product is bug free and works perfectly, while the business people understand that a bug free product is useless if no one wants it. Add on top of that the risk of over-engineering or tinkering too much with a product, see New Coke or Windows Vista, and you have the business-product dilemma. Since most of computer programming is debugging (20% thinking, 30% doing, and 50% debugging) and most of the bugs occur for edge cases, say 5% of your users, you can apply a modified Pareto’s Principle here and build your product for 90% of your potential customers. While the businessperson might not want to lose that 5%, it sure beats not being able to capture the 90% and more importantly proving your hypotheses.
Sales:
Engineers love to solve problems and sales people love to sell products. In the beginning of your company, these two goals may not jive. This joke embodies the engineer’s mindset: A lawyer, a doctor and an engineer were being sent to the guillotine. The lawyer is first, but when the executioner tries to do his job, the guillotine fails; the lawyer has memorized the law, tells the executioner about the double jeopardy clause which prevents the executioner from killing him again, and is thus set free. The doctor, who learns by imitation, is also nearly killed, but when the guillotine fails, he invokes the lawyer’s argument and is let go. The engineer, now, stops the executioner prior to utilizing the machine and says, “I see exactly where your problem is.” In fact, Palantir Technologies utilizes this in selling their products: their “salespeople” are their engineers. Engineers cringe whenever they are brought into sales meetings and the sales person starts selling. “All this stuff that isn’t even on the product roadmap yet! What are they doing? I don’t even know if this data set can interface with that one, and yes, its scalable but only for 1000 concurrent users, not your entire global customer service team with over 25,000 users!”
The Details:
Engineering problems are sometimes so esoteric and minute yet they are mission critical. A forgotten semicolon typically makes the difference between compilation success and syntax errors. Business people often say that they are losing the forest for the trees when the details arise. After all, they must sell the vision, the dream, the “what it could be” versus what it is today. The sales person knows that a foot in the door leads to that dream, whereas the reality sometimes doesn’t. In 1977, Bill Gates sold that dream to America, a “computer on every desk” even though popular consumer computers like the Commodore 64 with its 1.2 MB 5.25 inch floppy disk drive was mostly used for gaming. Without that initial vision, we would never be at this point today.
I struggle with my internal conflicts daily; when do you go versus when do you refine, when do you sell versus when do you support, when do you dream versus when are you grounded in reality? How do you strike compromise when negotiating with yourself? This is where “gut” plays a role. You can’t explain it, but you just know that it’s the right move. Hence the dilemma, being from the logical mindsets of either engineering or business, the “gut” choice will always leave you second guessing since its neither quantifiable or justifiable. And since you can see both sides of the coin and understand the rationale to go either way makes it even more difficult to go with your “gut.” How do you develop a “gut” instinct? Experience. Having done it one way and succeeding or having done it the other way and failing. No magic here. What’s the good thing about being able to build your own products and sell them too? You can fail faster so that you can build your experience, and create your own “gut” instinct, that magic formula of entrepreneurship.
Image credit: CC by Christopher Penn