It’s crazy how intensely the learn-to-code fire is burning and spreading. Everybody wants to hire developers, and everybody else wants to become a developer. As a developer myself, I figured I had a huge advantage in my first startup effort. Unfortunately, it wasn’t enough to preclude any of my biggest mistakes up to now, some which were fatal for my attempt.
My current thought experiment is considering whether or not developers make bad entrepreneurs. If you’re an engineer, is your engineering alone enough to start a successful company?
Seven or eight months ago, I believed that if you want to start a company, you’re stacking the cards in your favor if you have at least one “top-line skillset.”
On a cash flow statement, the number representing total revenue goes on the very first line. This number is called the top line. Every line below revenues is an itemized expense. At the bottom of the statement is your earnings, equivalent to your revenue net your expenses. The number representing your net earnings is called the bottom line.
I refer to any revenue-boosting skillset as a “top-line skillset.” Conversely, any skillset which cuts costs is a “bottom-line skillset.” Obviously both are important, and bucketing any vocation into either “top-line” or “bottom-line” is a semantics exercise with limited usefulness, but for the sake of this discussion I argue that you need a top-line skillset to start a company. You need a skillset which will immediately increase revenues.
On the one hand, bottom-line skillsets are useful to companies big enough to warrant hiring people just to cut costs. On the other hand, top-line skillsets are useful to companies of all sizes, big and small. Even a one-person company needs to increase its revenue.
I won’t dig too much into which jobs I believe are top-line vs bottom-line, but a good heuristic is to see which jobs small startups, less than ten people, are hiring. Those roles are top-line.
Engineers are generally thought of to be top-line employees. In theory, with more engineers, you can ship more product, and thus earn more revenue.
Presently, I still think top-line skillsets are important. However, if your interest is enterprise software like mine is, I don’t believe that engineering is enough. I’m starting to believe that developers are bad entrepreneurs if they want to sell to B2B customers.
The exception: developer tools
Developer tools are the main exception, naturally because developers are best suited to design and develop developer tools. It’s the classic case of “scratch your own itch.” Companies like DigitalOcean, Cognitect, and Docker are run by highly technical and experienced founders. Developers are stingy assholes, and I’m pretty sure I speak for all of us when I say that we’d only spend money on tools which work EXTREMELY well. Being a developer can only help here. It’s probably a requirement.
Business people don’t care about technical debt
But just as developers are stingy, so too are CIOs or whichever business person is in charge of hiring engineers.
Any Jaded Programmer (TM) knows one or more Dilbert-esque managers who can’t help but to regularly fuck up the code and the development process. The Jaded Programmer knows that technical debt multiplies development costs by 2x, 5x, or more than 10x even. But the CIO is the one spending the money, and the CIO doesn’t care. That’s why the typical (and stereotypical) CIO doesn’t care about things like culture, code review, testing, and modularity.
Divorcing positive economics from normative economics
Us developers can be a silly, stupid bunch. Developers, myself included, frequently view things in normative economics, in terms of fairness, ideals, and values. The proper business vantage point should be based in positive economics, in empirical evidence, because you need to look at empirical evidence to see what works and what sells.
Literally the worst startup advice came from expert spectator developers. One priceless nugget that a developer told me is that market validation is simple. He said, “Just ask them if they would pay money for it. If they say yes, then validated. If they say no, then not validated.” Uh, what. No, market validation is not simple. It’s a long, expensive, arduous process, and I’m convinced that anybody who thinks it’s simple hasn’t actually tried it before, at least within enterprise.
Another gem from a developer was that cold emailing potential customers and emails is a massive waste of time. Uh, what. What. WHAT. If you’re relying on your network to validate your market and product, you’re doing it wrong. Strangers will always be more honest with you than your friends. You need to be able to have a message with resonates with strangers if you think you have a promising idea. If you’re not famous, your network isn’t enough to properly validate anything.
The root of the misinformed startup advice that I got from developers stems from positive economics vs normative economics. Developers are commonly highly opinionated, contentious, and condescending. If you want to start up, you need to test things for yourself and see how it works. Don’t let your own opinions prevent you from trying new things.
If I could say one thing to a developer who wants to start up, I’d recommend being more openminded. You don’t know all the answers, no matter how much of an expert spectator you think you are. Your dogmatism might be helpful for your developer productivity, but it makes you an awful entrepreneur and probably also an infuriating person to talk to.
Sales forgives all problems
This is something that I believe all Jaded Programmers know as true but struggle to accept: sales forgives all problems. No matter how expensive and incomprehensible your codebase is, your company will overlook it if its sales are up and to the right.
Yes, in theory, the chart will be even higher up and to the right, maybe orders of magnitude moreso, if management listens to the Jaded Programmer on how to make the engineering process better. The CIO is already happy with a modest upwardly sloping curve though. Too bad!
If you’re interested in selling enterprise software, know that companies are much more willing to invest in areas of the company closer to the revenue and the customers. Just as top-line skillsets are more valuable to startups because top-line skillsets produce revenue, areas of the company which are closer to the revenue are also more valuable to the company and more likely to receive further investment. Engineering is usually far from the customer. These days, progressive companies advocate engineers do customer support. It’s really an awful shame that this idea is considered progressive. How could it be anything other than obvious that engineers should do support? The answer is to remember that we’re thinking in positive economics, not normative. The reality is, the typical division between engineering and customers signals that businesses want to spend money on engineering just until it’s Good Enough (TM), then they redirect the rest of their capital to levers closer to sales and marketing.
Michael O. Church, a programmer whom I consider immensely talented and experienced, gave a presentation on how programmers should sell better engineering practices to the business side. I’d recommend it to anybody who wants a quick tour of the most common proprietry software development antipatterns, particularly in the context of selling haskell to management but applicable to all contexts. The presentation’s highlight which is most relevant to this post is that you have to be able to sell on a business benefit, not an engineering benefit.
Sales might forgive all problems, but the ability to sell will empower you to actually get stakeholders to buy-in and actually solve problems instead of sweeping them under the rug. Developers tend to suck at this.
If not engineering, then what?
If I choose not to be a full-time engineer anymore, what will I do next?
My current goal is to be in a much stronger position for another startup attempt within enterprise software. If or when I do that, I expect to be far more risk-averse than I previously was. To strengthen my starting position, I’d like to gain experience in solving a problem with the following criteria:
- It’s closer to the revenue and the customers
- It’s something I’m passionate about
- It’s something I can become an expert in
- It can be solved with engineering
I want to be closer to the revenue because that’s where enterprise customers are much more likely to spend their money. The second and third criteria’s purposes are more obvious. The fourth is because I want my engineering background to multiply any future efforts.
So now, I have a new set of challenges. What new problem do I want to become an expert in? How can I move closer to sales & marketing? Can I combine that with my existing engineering ability?
Most importantly, am I reasonable to think that being a developer is not helpful enough to start an enterprise company?
If you enjoyed this post or would like to give me any feedback at all, I'd love to hear from you! You can tweet me at @dillonforrest or email me at firstname.lastname@example.org. It'd make me super happy to hear from you!