Forever Learning

Feed Rss

CTO Guide for Startups & Entrepreneurs

08.17.2012, Business, Tech, by .

This blog post is an MVP, please use the comments to provide positive and negative feedback from which I can learn and iterate on my idea.

I am thinking of writing a CTO guide for early stage startups[1] and entrepreneurs.  There are tons of people walking around with big ideas, but don’t know how to implement them.  Many of these people have a good mind for problem solving and understanding complex logic, but are missing some critical piece of the puzzle that would enable them to be a very effective technical co-founder or CTO.  To be a stud tech-cofounder you need to be someone who is comfortable with technology in general, knows how to code, knows how to develop a product, knows how to maintain systems, and understands how to best apply technology to serve the needs of the business. Throughout their time as a technical cofounder the CTO of a successful startup will have developed all of these skills, and this guide is meant to help enable or accelerate that process.

Target Market

As with any product, you need to define your market and understand who your audience is. I’ve identified 4 user-types who would benefit most from this knowledge.

The inexperienced generalist

This persona is a reader who understands the basics about most technical things, but has several gaps in several areas between where they are and where they would need to be in order to serve as a solid technical co-founder or CTO.  They’ve probably rented a shared server before and tweaked some wordpress sites, they understand the basics of SEO, have an interest in business, and taught their parents how to set the timer on the VCR in 1992… at the age 10 (apparently they’re turning 30 this year, what a coincidence).  They typically have a good understanding of windows or OS X, and they might have booted or installed ubuntu before to see what it was about.  A terminal window doesn’t scare them, but they’re not proficient by any means.  They probably know what a compiler is, but have no idea what “strongly typed” or “weakly typed” means.  They have probably built one or more computers for themselves or their friends/family in their lives, but most likely haven’t worked as a sysadmin.  These people have demonstrated a general technical proficiency which indicates the capacity to be the technical leader of an early stage venture.  My book should be able to bring the knowledge level of these people up significantly and serve as a general reference that they can turn to as the go meet the challenges of building a new company.

The awesome business cofounder

You know who I’m talking about.  To some it may seem like a myth, but there is such a thing as a business cofounder who is not only able to effortlessly squeeze funding out of a VC, close a deal like every prospect is their mom, and understand exactly what the market wants… but is able to get the analogy of a database being like a bunch of spreadsheets and whose head doesn’t blow up at the sight of a WHERE clause.  Basic programming control flow statements intuitively make sense to them (even if recursion doesn’t), and they were pretty good at chemistry, or physics, or math.  Most of all they have the perseverance and the desire to learn what they need to learn in order to fully understand their product.  This person cannot, and should not, be taking on the role of a technical cofounder or CTO, but they might need to bring one on board. They also might need to build the initial prototype of their idea in order to show people a working product (with some market uptake) and help get funding or make equity in their company more attractive to that software architect friend of theirs who make $180K + stock options + ESPP at their well-established company.  The best business cofounders are the ones who have a good grasp of technology and how their products are built.  The best technical cofounders are the ones who understand business and understand the needs of their market.  There are a multitude of ways that the business cofounder can benefit from my hypothetical book to make themselves more valuable to their venture.

The specialist

This is your prototypical enterprise developer or sysadmin.  They’ve done amazing things in code, but don’t know how to create a DNS server.  Or they’ve built systems that serve tens of millions of requests a day for *insert corporation X here*, but their coding is limited to 20 – 30 line bash or perl scripts that essentially just wrap a series of shell commands that they would have typed by hand to do the same job.  (I’m not knocking perl, I like writing perl… we’ll leave it at that.)  This person would typically be a very valuable cog in someone else’s wheel, but after getting sick of seeing the need to develop “other skills” in order to succeed in the corporate world (like rubbing the right people the right way at the right times) they’ve decided they want to stop trading their life for a paycheck and build their own wheel.   The journey from being a specialist to being the technical lead for a company can be difficult.  Specialists are used to knowing everything about their silo, and being a subject matter expert that everyone goes to for help on some complex issue.  Looking for help on some 17 year old web-designer’s blog when you’re trying to figure out why your button doesn’t work in IE is quite a change.  This person can benefit greatly from my hypothetical book by ramping up quickly in the areas where they are not particularly strong.  I’m not going to make them an expert over-night (they probably know more than me about their specialty [unless they are a developer 😉 ]), but I can give them a good start and help them move their momentum in the right direction.

The tech-only leader

This person, like the specialist, is strong in one technical area but is also decently well versed in others.  They have probably been developing professionally for years, but have also maintained production systems either on the side or in some past role.  They can code the hell our of an app in development, can deploy the app to a production environment, and with a little goggling can scale the app up to say a million users without breaking much of a sweat.  So what’s the problem?  Well this person has never been interested in the business aspect of things.  Intheir current form, they’re most useful as a “Lead Developer” or a “Lead Administrator”.  If you were to hand them a “completed” product they wouldn’t really know what to do with it, how to market it, how to sell it, etc…  They are a user of software and have product development experience so they can brainstorm use cases, but they don’t understand how to guide product development and how to best leverage the product to meet the needs of their market.  Sales = forget about it, funding = forget about it, marketing = they probably know what a “genetic algorithm” is, so they should understand the power of A/B testing fairly quickly, but they don’t know to even do it.  Networking, who needs that?  I put this persona last because the tech-only leader is the person who needs the least help from me of this group.  In fact a few years ago I definitely fit this persona.  I would guess (no data to back this up) that most successful technical co-founders come from this group, but require a very solid business lead to balance them out.  The tech-only leader will eventually, maybe begrudgingly, learn the lessons in my book but, unless they devote considerable time to developing their business skills (which they probably won’t), it will take them longer than it should.   These people probably won’t buy the book due to their lack of desire to learn business stuff, but maybe the “awesome business cofounder” will give them a copy.

Who I would NOT be targeting

I’ve also identified two user-types who do not fit the profile of someone who would benefit from reading my book.

The “Idea guy”

Sorry “idea guy” but you need more help than I can provide in one book.  Problem #1 is that you consider yourself “the idea guy”.  Feel free to buy my product, but you’re going to have to give it to that friend of yours who likes to watch those boring TED talks, or the one who showed you how to make those “balls of fire” (it’s called plasma) in your microwave, and convince them to do the work for you.  Those with no technical aptitude whatsoever, no desire to learn, and lacking the perseverance to execute would be better off spending their time refining that elevator pitch again or tweaking the copy on your marketing materials.  To be clear, I’m not saying you’re useless, you’re just not useful in this capacity, and by considering yourself the idea guy you have indicated to me that you just don’t have what it takes.  In fact, here is a blog post by someone complaining about business co-founders not being given enough credit (from which I stole the above graphic).  This guy eventually pushes through and builds a prototype, an act which moves him farther from the “idea guy” persona and closer to the “awesome business cofounder” persona.  But, what really made me link to that blog post was the top comment on it.  A guy going by Josh Strike (who I’m assuming is this guy:, posts what I consider to be the single greatest random-internet-blog-comment about this topic ever written.  I will probably have a future post dedicated to the awesomeness that is this blog comment.  Go read it.

The person who has already figured it all out

Congratulations, you are one of the few people who already know everything in my book.  You have probably run a startup that has a large customer base (pay or not) and you were a strong business founder who learned the technical stuff or a strong technical founder who learned the business stuff.  If this persona is you, and somehow you are still here reading this, please give me some comments below to help improve this idea and help everyone else.  Also, if you have a large network to help distribute this product, and would like to help… then let me know.


Here is a proposed table of contents or outline of the book.  I lead with MVP because well, that is something that people should learn up front, before they start building out some massive web-scale (buzzword) system and call it an MVP, because they’ve seen people use that word on TechCrunch.  I follow that up with business because I want people to get that information early and have it in mind when they’re using the rest of the book to help develop their products.  I move to outsourcing next as a bit of a segway between business and technical, and ironically I was thinking of outsourcing this section to a (stateside) buddy of mine.  Once we get into the technical stuff I start with a high-level discussion of platforms, move to a lower but still fairly high level discussion of frameworks, and then get into product development.  Dev covers mostly process, but also UX (user experience) and bug tracking/maintenance.  Coding will be a significant portion of the book and I’m thinking I’ll probably focus on ruby+rack while touching on some other server side technologies.   We’ll be using bootstrap, jQuery, sass, haml, coffeescript, and mustache plus a few small libraries I’ll probably open source for this book in order to build our dynamic application.  Obviously I can’t write an opus on just coding in the middle of a book like this, but my goal is to give you a sufficient level of expertise to build & scale a prototype while using standard patterns.  Next we move on to systems where I focus on Linux (sorry windows developers) with ubuntu/centos, apache, nginx, ruby enterprise, MySQL, etc., general operational needs, and hosting.  What I dont’ talk about here is installing ram and patch cables, though I might tough on hardware in the colocation section.  We’ll see.  Finally we close with a bang by giving a full chapter, that you will hopefully have to use, on scaling your stack. This covers both code techniques and hardware configuration.  Ohh, and I will throw a little something about workstation administration or something.  I did spend a year with that technically being part of my job title in college, and it is sort of necessary.  I guess. I admit reluctantly. I’m thinking the appendix will contain some pointers out to other resources to further your knowledge so that this book both give you the foundation and points you in the right direction for more information.

  • MVP
    • Does P equal “Product” or “Prototype”?
    • build
    • measure
    • learn
  • business
    • vision
    • planning & finance
    • marketing (I might make this its own section)
    • selling
    • funding (I might make this its own section)
    • influencing people
    • handling business founders and the management team
    • hiring employees
    • talent acquisition (yes, this is different from the previous one)
    • operations
    • people management
  • outsourcing
  • platforms
    • web
    • mobile
    • desktop
    • enterprise
    • social (and the perils of depending on someone else’s platform)
    • persistent storage (mysql, mongo, cassandra, etc)
  • frameworks
    • MVC
    • Ruby + something (rails, merb, sinatra)
    • PHP + something (Yii, cake)
    • Python + something (django)
    • Javascript + something (so much can go here)
    • iOS SDK + xcode
    • Android SDK + Eclipse
    • PhoneGap (maybe?)
  • product development & maintenance
    • UX
    • waterfall
    • agile
    • lean
    • project management
    • bug tracking
  • coding
    • Git, HG, and SVN
    • hello world
    • dynamic web pages
    • asset handling
    • databases driven applications
    • webservices
    • mobile
    • jobs & queueing
    • desktop (afterthought?  I suppose.)
    • optimization
    • intro to scaling
  • systems
    • becoming a unix terminal pro
    • maintaining software (compiled & managed packages)
    • your stack
    • your first system… or two, or three
    • security
    • monitoring
    • VPS hosting (Linode, etc.)
    • Amazon Web Services (and hopefully some other competitors)
    • colocation
  • scaling
    • scalable code & caching
    • vertical/horizontal
    • DNS & Load Balancing
    • Type of servers: Web, DB, Cache
    • the different systems you’ll use)
  • Your corporate infrastructure (workstations & corporate systems = boring)
  • Appendix
    • Jeff’s ultimate (periodic) list of books for technical entrepreneurs
    • Jeff’s ultimate (periodic) list of websites & blogs for technical entrepreneurs
    • The Stack Overflow Podcasts
    • Tools for remote teams

So there it is, any takers?  Definitely, definitely, definitely feel free to pick this apart in the comments.  I read all comments and would love to crowd-source this into a great outline that I can then use to build a great product.


[1] – by “startup” I really mean technology startup, and by “technology startup” I really mean young company that will build a product that is composed of machine instructions that will be executed on a CPU.  If your startup is a new steel company (good luck) then this product isn’t for you.  Similarly, if your startup is a dog walking service, you probably don’t quite need a CTO just yet.