I was the technical co-founder. My job was to code, work with a few other people who code, and be the overall passionate guy about the quality of the code. I find it helps to have a stake holder in this position, you end up with better code, and someone who is going to take true ownership of the code.
My co-founder was a true marketing/selling machine. So it worked out for us I think.
I somewhat agree to an extent, my take on things is that a successful startup needs two founders; a technical founder to do the programming and a business development founder who possess's high amounts of confidence and a vision to push both the development and end goal of the startup.
Having said that, I'm currently a solo entrepreneur trying to balance work, life and startup all by my lonesome self because I don't know who or where to ask for help with my startup ideas with spending a lot of money.
"I somewhat agree to an extent, my take on things is that a successful startup needs two founders; a technical founder to do the programming and a business development founder who possess's high amounts of confidence and a vision to push both the development and end goal of the startup."
As a founder and programmer, I found this post really interesting and well written, but rather than lamenting about how it must be impossible to do both roles where eventually you will have to give up programming - why not just accept that it is just much harder? Also, I certainly hope that I will never spend 50% of my time pitching..
Balance is the key to any startup, the opposite side of the coin are founders who have never been in the developer's chair, which is both common and worse.
No, you don't. I can't code my ass from my elbow, but I know how the technology works, I know where to find the kind of technology I want in my product, and I can find the people who can put it together.
I guess the distinction I'm trying to put is that there's a distinction between "non-technical" and "non-programmer". I can't program, but I know all the technically pertinent details of my product that any VC or customer is going to care about. To some extent, I think it frankly works better that way than if I was doing the coding, because I know what's really important in the product, and won't miss the forest for the trees.
You don't need to know how to code to be able to handle the technical responsibilities of actually running a tech startup. You just need to know the technology itself.
Not yet, but that's probably because we just started our market entry process about two weeks ago. That said, our operating costs are tiny (all combined they're currently less than my rent) so we'll hopefully get to that level in the near future.
the opposite side of the coin are founders who have never been in the developer's chair, which is both common and worse.
I disagree. I've worked at a couple of startups founded or co-founded by a guy with no hands on technical experience and he was great. He came up with the ideas, found the right people (or sometimes the other way around) and then let them do what they did best, with only gentle prodding to keep everything going in the right direction.
What he had was a good high level understanding of the relevant fields, plenty of experience starting and running companies, a vast contact network, an amazing knack for raising money and was very good at getting out there and selling our product.
Am I correct in assuming the following characteristics? The guy you are talking about:
* Trusts you to do your job, and assumes you are pulling your weight in whatever way you see fit. (contrast: "We need your ass in the chair 08:00-16:00 so we know you're working.")
* Trusts you to do your job, and accepts your technical decisions even if he doesn't fully understand them. (contrast: "I just don't see exactly why GitHub would be better than our existing Team Foundation license, so we won't switch.")
An hour… well maybe you can fix a quick bug or two. But you won’t get anything hard done.
I work full time at a startup, and I have a 6 week old daughter at home, and I'm working solo on a proof-of-concept on nights and weekends. Since I've got my hands full with the baby at home, I've learned to be very efficient with my time. One decision that made things a lot easier was deciding to go with node.js. Since the entire app is written in JavaScript, I can quickly test out ideas on my phone or tablet browser using JSFiddle, and integrate it later when I have a laptop handy. Sometimes I only have an hour of uninterrupted time, but that's usually enough to write a function or two.
That approach might be fine for small projects/webapps, but I stuggle to see that approach working for anything more complex/hard. Sometimes the only way to make effective progress is a full day of uninterrupted progress where you can hold the relevent parts of the system in your head at the same time...
Sometimes you need several weeks of working on the problem in this way to make progress! (e.g. machine learning improvements, distributed system design).
Well, not that I don't think you have a valid point but some very smart people have done otherwise...
"When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I'd sleep till about 11 am, and come in and work until dinner on what I called "business stuff.""
I pretty much agree. Although I think it's important to have the tech background and have the ability to code (the same ways CEOs need to understand basic accounting) it's hard not to get immersed in the rat race and lose sight of the big picture. As the OP said, you need to spend a big part of your time pitching. Both to investors and as importantly to potential recuits.
Isn't the whole point of startups that they are usually funded (at least initially) on about enough money to buy ramen noodles for a year?
Sure, if you have enough funds to buy some rockstar programmers then go for it.
Otherwise what are you going to do? Outsource it to the lowest bidder? Then spend all that time worrying if they will produce something that matches your vision and worrying about the quality.
No, you put in the time to find a good programmer who will work for a reasonable price. Typically that means finding someone who graduated fairly recently and is looking for additional work, or someone that doesn't have a lengthy track record/portfolio. It's not easy (I've probably talked to a hundred some odd programmers in the last year, and maybe three would fit the bill), but you can find the right people if you put in the work.
It's no different than finding a good salesman, or a good PR person, or a good anything. You can find great talent at a reasonable price if you're willing to dig. Rockstars don't always come at rockstar prices, because a lot of the time they don't even know they're a rockstar.
That's dangerous, because very often they'll figure out they're a rockstar as soon as they accomplish something useful for you, and move on to firms that will pay them rockstar money. Meanwhile you're left high-and-dry with a bunch of code written by a talented-but-inexperienced coder, and you have to find a replacement - often right as people start taking interest in your product.
I worked pretty cheaply for the first year or two of my career, as did several of my friends. I'd like to think that my employers got quite a bargain. But I only stayed with them a year or two, as my $32K/year job became a $66K/year one became a six-figure income, or as my friend's $15/hour wage became $75/hour became $72K/year employment became six-figures.
The expectation would be that our revenues will grow to the point that retaining talent won't be a problem. We only just started the market entry process at the start of the month, so it's too early to say, but if I'm losing talent in a couple years because I can't afford to retain it, then our problems go way beyond our talent growing too expensive.
There are other costs besides price. Someone who graduated recently, or doesn't have a length track record etc may also need a lot of time for self learning, mentoring, accumulate a ton of hidden technical debt, not write maintainable code, have bad naming practices and code conventions, limited experience coding in a team environment, low output, etc. And getting someone to come in to clean up the mess will cost more time and money and effort. This is on top of nostrademons' the market corrects itself eventually.
And I am someone who used to outsource many technical projects to Eastern European developers, and wound up becoming a developer. You maybe getting good talent at a good price, but there's always a cost.
The biggest problem I see startups having (at least the ones I have insight into, consulting and whatnot,) is their founders are too far from the technical. I agree founding and coding is hard to manage, but without a developer on the same level with the same goals, you're shooting your business in the foot.
Hence the classic combination of a tech cofounder and a business cofounder. Or, the more usual in real life combination of two tech cofounders, one of whom actually does mostly "business stuff".
Just change the title to "Why CEOs shouldn't be developers". As soon as your startup has a team of people instead of just you and your buddy you can start applying this rule.
What it looks like to go from being the first real coder to being a full time manager of a pretty large eng team over the course of 3 years in git commits per month:
Refactorings to help make our codebase less of a giant hairball and more of a DAG. Big project that a lot of people helped out on and that I cared about a lot. Also it was relatively easy for me to pitch in cause most of the work was tedious but uncomplicated.
I can understand missing coding, too, but your team will be able to sense that in the same way children can sense the stress of their parents. As a manager, it's important to get over that so you can take yourself and your team to the next level.
I run my own start-up and I have to do everything. I am the sole employee. Some days I wear my designer hat, others its server config, and others it's customer service. Is it a bit crazy? Sure, but I really enjoy what I do.
I don't have meetings. I don't go to conferences. I don't pitch my company to VCs. I don't try to raise money. I don't care what other companies are doing. I don't try to use the latest tech because I'm expected to.
LAMP is fine.
I concentrate on building the product, satisfying my customers, and increasing my revenue. Everything else is bullshit.
The founder should be able to do everything. Being a developer is one of those things.
Nothing wrong with a "lifestyle" company and making a couple 100k for yourself. No need for all the headaches of running a public company and possibly getting kicked out of your own company by VCs, boards, etc. like Jobs did.
There is a lot of room between a 1-man show and Intel/Tesla. People really think it's all or nothing and there is so much room in between.
It doesn't mean it's a lifestyle business either, you can have a business earning over $10 million revenue p/year in this in between and with no funding. Is that really just a lifestyle business?
Most people i've met seeking venture capital have zero chance of being capable of building the next giant company. Yet many have succeeded in raising capital regardless. VC's generally aren't willing to take on much risk, so you see them spending lot's on low-capital requirement companies that are +EV. And little on companies that need large amounts of capital to scale.
Three years? Exactly the same here. I am a one man show and I highly enjoy the current situation. Next year I'll think about hiring one or more student to help me out on minor parts, but I still wonder if I can do without. Caring about employees might not be worth the trouble.
I'm in exactly the same situation right now and I ABSOLUTELY agree with you on everything. One minor thing here though that I don't call it a 'startup', it's rather a 'small business', which grows linearly, not exponentially (not yet at least).
Amen. I'm in exactly the same situation. Took me a few years to get there but now I'm totally happy with it. I actually like the fact that I have to do everything myself. That's what keeps it interesting (and challenging once in a while).
What's even worse is when one of the founders can't spend time coding any more due to investor meetings and other concerns about running the business, but still thinks they know what's going on in the codebase, and demands to be able to micromanage it. I know one CTO who fought tooth and nail with multiple meetings to keep AAC compressed audio out of a codebase after agreeing to a plan to improve overall app size, not understanding that the AAC+ compatibility problems in some versions of Android didn't apply. He just didn't understand audio encoding, didn't have time to research it, but he be damned if he didn't get to decide what's used.
This is true for another reason. Programmers make horrible designers, and they should stick to programming when the product is user facing. They can forge perfect tools, and sometimes just the tool is valuable enough to make a profitable product. Many times though, the product needs to work for people, and giving the executive decision powers in the hands of most of the developers is a recipe for a disastrous product.
I have given room for that. When the product is a tool, then you can't do much, but accept. The experience is usually similar to the one you have if you ask a blacksmith to make you a pair of scissors.
Please don't generalize, this is not always true. Being a programmer (with a formal CS background) who used to make a living as a professional designer, I have met a lot of people like me. Good design is about solving problems, good programmers usually solve problems.
When it comes to aesthetics, it's something that people do learn, and programmers can learn, too.
- giving the executive decision powers in the hands of most of the developers is a recipe for a disastrous product
I respectfully disagree here too, for the sole reason that developers can learn the ability of making decisions in a relatively rational way. I would even wager to say they might be more inclined to trust in data.
I should have started with "Most programmers make horrible designers"; my apologies for that. The point is, even making a not-so-bad design, takes a lot of thought; more importantly, it takes courage to push a design concern that will make implementation harder and take longer to finish. I certainly believe that people are amazing, and they are capable of doing amazing things. But also there is the issue of possible vs probable. And, I don't take it lightly when I see a good programmer and designer in the same person.
Correction: Most programmers make terrible designers. I've met and worked with some that can handle both well and a few that are exceptional in many realms technical and design.
Now the "designer" that glued the Metro interface on to Windows 8 should stick to smartphones. I'm about to write shim to make the OS boot into a CLI interface, so I can avoid the "Tiles" and get somework done.
I stopped reading after this, "A while back it was PHP in favour of static HTML." Actually it was PHP in favor of either Perl or C used in CGI, or VB in ASP.
I'd like to comment that the title should probably be "Why founders shouldn't be developing/programming". This title makes it seem like being a developer excludes you from being a founder/CEO
Comment bait title aside... That's why you do it in steps: you build the bulk of your product first before you have customers and need investment and then you shift your time to other things. Nobody is going to hire an engineer to free themselves up to pitch for money to pay for the engineers until that is a sound decision.
That's sort of the obvious thing, but on the other side you have people that you can't do any really meaningful product development without customers, or you're likely to build something nobody wants. Is there a good balance there?
96 comments
[ 5.1 ms ] story [ 171 ms ] threadI was the technical co-founder. My job was to code, work with a few other people who code, and be the overall passionate guy about the quality of the code. I find it helps to have a stake holder in this position, you end up with better code, and someone who is going to take true ownership of the code.
My co-founder was a true marketing/selling machine. So it worked out for us I think.
Having said that, I'm currently a solo entrepreneur trying to balance work, life and startup all by my lonesome self because I don't know who or where to ask for help with my startup ideas with spending a lot of money.
A Jobs and a Woz.
I guess the distinction I'm trying to put is that there's a distinction between "non-technical" and "non-programmer". I can't program, but I know all the technically pertinent details of my product that any VC or customer is going to care about. To some extent, I think it frankly works better that way than if I was doing the coding, because I know what's really important in the product, and won't miss the forest for the trees.
You don't need to know how to code to be able to handle the technical responsibilities of actually running a tech startup. You just need to know the technology itself.
I disagree. I've worked at a couple of startups founded or co-founded by a guy with no hands on technical experience and he was great. He came up with the ideas, found the right people (or sometimes the other way around) and then let them do what they did best, with only gentle prodding to keep everything going in the right direction.
What he had was a good high level understanding of the relevant fields, plenty of experience starting and running companies, a vast contact network, an amazing knack for raising money and was very good at getting out there and selling our product.
Am I correct in assuming the following characteristics? The guy you are talking about:
* Trusts you to do your job, and assumes you are pulling your weight in whatever way you see fit. (contrast: "We need your ass in the chair 08:00-16:00 so we know you're working.")
* Trusts you to do your job, and accepts your technical decisions even if he doesn't fully understand them. (contrast: "I just don't see exactly why GitHub would be better than our existing Team Foundation license, so we won't switch.")
I work full time at a startup, and I have a 6 week old daughter at home, and I'm working solo on a proof-of-concept on nights and weekends. Since I've got my hands full with the baby at home, I've learned to be very efficient with my time. One decision that made things a lot easier was deciding to go with node.js. Since the entire app is written in JavaScript, I can quickly test out ideas on my phone or tablet browser using JSFiddle, and integrate it later when I have a laptop handy. Sometimes I only have an hour of uninterrupted time, but that's usually enough to write a function or two.
Sometimes you need several weeks of working on the problem in this way to make progress! (e.g. machine learning improvements, distributed system design).
"When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I'd sleep till about 11 am, and come in and work until dinner on what I called "business stuff.""
(http://www.paulgraham.com/makersschedule.html)
Sure, if you have enough funds to buy some rockstar programmers then go for it.
Otherwise what are you going to do? Outsource it to the lowest bidder? Then spend all that time worrying if they will produce something that matches your vision and worrying about the quality.
It's no different than finding a good salesman, or a good PR person, or a good anything. You can find great talent at a reasonable price if you're willing to dig. Rockstars don't always come at rockstar prices, because a lot of the time they don't even know they're a rockstar.
I worked pretty cheaply for the first year or two of my career, as did several of my friends. I'd like to think that my employers got quite a bargain. But I only stayed with them a year or two, as my $32K/year job became a $66K/year one became a six-figure income, or as my friend's $15/hour wage became $75/hour became $72K/year employment became six-figures.
And I am someone who used to outsource many technical projects to Eastern European developers, and wound up becoming a developer. You maybe getting good talent at a good price, but there's always a cost.
(then I added in the 0 months manually)
Learned this just now via twitter btw: https://twitter.com/harryh/status/279010454376960000
I promise, if it weren't so annoyingly hard to implement, Linux would have command called nwodtuhs to turn the machine on. Those crazy geeks! :D
[1] https://github.com/holman/spark/blob/master/spark via ./spark 37 99 177 104 136 115 126 72 37 43 30 39 53 43 59 66 13 23 67 66 13 20 0 29 25 3 2 3 3 35 6 10 2 0 0 38 0 0 32 0
But hence the notion of not being a founder CEO. Let someone else take the reigns and you do whatever you want to do.
Though there exists a lot of potential of messiness in this.
I don't have meetings. I don't go to conferences. I don't pitch my company to VCs. I don't try to raise money. I don't care what other companies are doing. I don't try to use the latest tech because I'm expected to.
LAMP is fine.
I concentrate on building the product, satisfying my customers, and increasing my revenue. Everything else is bullshit.
The founder should be able to do everything. Being a developer is one of those things.
No offense, but what you call a startup might be more considered like a business by the HN crowd, and this is why you can operate this way.
Not every type of company can stay out of the now traditional pitching/VC game.
It doesn't mean it's a lifestyle business either, you can have a business earning over $10 million revenue p/year in this in between and with no funding. Is that really just a lifestyle business?
Please don't generalize, this is not always true. Being a programmer (with a formal CS background) who used to make a living as a professional designer, I have met a lot of people like me. Good design is about solving problems, good programmers usually solve problems. When it comes to aesthetics, it's something that people do learn, and programmers can learn, too.
- giving the executive decision powers in the hands of most of the developers is a recipe for a disastrous product
I respectfully disagree here too, for the sole reason that developers can learn the ability of making decisions in a relatively rational way. I would even wager to say they might be more inclined to trust in data.
Correction: Most programmers make terrible designers. I've met and worked with some that can handle both well and a few that are exceptional in many realms technical and design.
Now the "designer" that glued the Metro interface on to Windows 8 should stick to smartphones. I'm about to write shim to make the OS boot into a CLI interface, so I can avoid the "Tiles" and get somework done.