"At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn’t possible to do both."
For me this is the key quote.
I have a friend who went the other way from the author of this article. He started as one of two company founders working out of an apartment doing all the technical work while the other founder focused on business stuff.
When the company grew to a point where he had to decide between staying technical and people management, he hired a VP of Engineering, stuck to coding, and still codes 6-8 hours a day.
The company is now at about 200 people, is profitable, raised a series A after figuring out the business model, and blowing past the goals set by the investors. His stake in the company is worth many tens of millions today.
Just an existence proof that 'sticking to coding', can be a viable strategy, if an unusual one.
He is not interested in blogging/social media etc, or else I'd have persuaded him to write up his experience.
I have to agree with dang. Most people running successful startups don't have (or take) the time to write about it.
Which is too bad (imo). We could use more writeups from the successful subset.
I'm another of those technical founders who choosed to stick with the code. Even though we are still very small, it has been a subject of conversation since the beginning between my co-founder and me, and after 2 years of trying to convince me to assume managerial tasks, she finally came to term with that idea.
It helps that a late-founder joined us and is already assuming the VP of Engineering tasks. This was done even before our seed round, at only 2 developers. The sooner the divide is made, the sooner you can fully concentrate on building the product.
I never really liked the "CTO" title, as I don't think of myself as a "Chief" or "Officer. I'd rather be called Lead Developer.
I think this is a critical point for engineers to see, and it sends a great message for engineers joining a company: "You don't have to go to the mgmt. track to have great career growth."
In many organizations I have seen the deep technical skills one gains through their career are not valued in the same way "Mgmt. Skills" are. "Mgmt. skills" are or at least appear to be much easier for an organization to see and reward. This is a great story!
I think that the pressure for initial programming founders to become head managers is a Peter Principle trap - your success at the tasks required as a senior engineer does not correlate very well with success as a manager. Even if it works for you (as it seems to have in this case!) it's important not to establish a culture in which you get promoted to managerial positions iff you are a good engineer.
I've seen a lot of fantastic coders get promoted to management and be bad-to-mediocre at it, and a lot of meh coders who can take over a room passed over for managerial jobs they'd probably be better at than their purely-technical ones.
For me this is the key quote.
I have a friend who went the other way from the author of this article. He started as one of two company founders working out of an apartment doing all the technical work while the other founder focused on business stuff.
When the company grew to a point where he had to decide between staying technical and people management, he hired a VP of Engineering, stuck to coding, and still codes 6-8 hours a day.
The company is now at about 200 people, is profitable, raised a series A after figuring out the business model, and blowing past the goals set by the investors. His stake in the company is worth many tens of millions today.
Just an existence proof that 'sticking to coding', can be a viable strategy, if an unusual one.
He is not interested in blogging/social media etc, or else I'd have persuaded him to write up his experience.
I have to agree with dang. Most people running successful startups don't have (or take) the time to write about it.
Which is too bad (imo). We could use more writeups from the successful subset.