Tell me more ×
Answers OnStartups is a question and answer site for entrepreneurs looking to start or run a new business. It's 100% free, no registration required.
up vote 3 down vote favorite
1

Maybe i'm mixing CTO with VP of Engineering here. But as a CTO early on in a 5 person startup that haven't built a prototype yet...What are the key topics or areas that you must have a vision for once you pitch your prototype to an investor, or assist the CEO in successfully pitching?

I'm thinking overall system architecture, technical roadmap, how to scale the system towards a certain market goal in the next 3 years, how the technical architecture will serve and empower the business need....am I on the right track?

Assume this CTO was a senior-level software architect and developer that breathes technology day in day out

share|improve this question

2 Answers

up vote 3 down vote accepted

What are the key topics or areas that you must have a vision for once you pitch your prototype to an investor, or assist the CEO in successfully pitching?

In my experience none of this "overall system architecture, technical roadmap, how to scale the system towards a certain market goal in the next 3 years, how the technical architecture will serve and empower the business need" matters, directly, to investors. They might care about some of the details when you get to the point of nailing down terms - but they are details.

What investors care about:

  1. Where is the prototype?

  2. How is the prototype performing in the market you're trying to address?

  3. How are you going to grow that market over what time scales?

  4. Why do you need our money and how are you going to spend it wisely?

To get investment you have to have convincing answers to those questions. Some aspects of those answers will likely be within your domain of knowledge. What those answers will need to be depend on your business - so it's hard to give generic lists of things that will be of concern.

I'd strongly recommend trying to meet and network with people working at companies at as similar stage to where you are now - and companies who are a few months on from where you are now. Talking to people about how the investment process went / is going. If at all possible meet with investors before you are asking for investment. Find mentors.

A lot of the stuff I read about CTO roles online is just plain wrong, or company specific. If you go talk with several companies, and several investors, you'll begin to see that people's idea of what a "good" CTO is changes quite a bit between organisations.

To some extent investors will not care if you are the right CTO for the company in three years time. They care if you're the best person to get from now to 18-24 months from now where you are actually showing some traction and growth. After that - they can always "encourage" you to take another role ;-)

share|improve this answer
up vote 3 down vote

Taken from SoCalCTO website - CTO or lead developer:

A good Startup CTO will naturally address these.

  • How much will it cost to build what we need to build? How can I control costs but effectively get stuff developed?
  • How can we phase development to balance cost, features, risk, etc?
  • What options do we have? How do we balance those options? What makes the most sense for us?
  • Given likely market changes, how will we design and build so that the systems can respond to marketplace changes?
  • How do we need to structure the systems to get ahead and stay ahead of the competition?
  • What are the biggest areas of technical risk? How can we address this risk?
  • What technology research is required?
  • What technologies will we use? What existing systems will we leverage, what programming languages, software development methodologies, web application frameworks, revision control systems, etc.?
  • What other kinds of systems will we likely need? Accounting? Reporting?
  • What are the important security considerations? How do we balance concerns vs. cost?
  • Where are the likely future integration points with other systems?
  • What areas of the application are likely sources of scalability issues? What kinds of spikes in traffic could we have? How will we address these without significant cost?
  • How are we going to manage the product roadmap? Make sure we make short-term progress, but not at the expense of longer-term objectives?
  • What do we build in-house or outsource? What parts might we do off-shore, on-shore, in-house? What does the staff need to look like over time? When will key hires come on?
  • What other kinds of capabilities such as graphic design, user interaction, product manager, QA will we need? Who will do that? Who’s responsible for what portions?
  • How will we find and interview developers?
  • How do we motivate and manage developers?
  • What do we need to do to make sure we can survive technical due diligence by investors and partners?
  • What specific technical innovations might make sense?
  • What can we build that might be protectable?
  • What metrics are going to be the key startup metrics and how do we get those metrics without too much cost?
  • Where and how will we host the systems? What’s our purchase, licensing, SaaS strategy?
  • What other CTOs can I ask about complex questions to see how they’ve addressed these issues?

Some of these questions are high-level, complex, inherently fuzzy and hard to answer. In fact, they interact with each other to greatly increase complexity. Technologies you use, how much will it cost, future capabilities, scalability, in-house vs. outsourced all intersect.

Theoretically a great lead developer can address all of these issues. But experience points to the fact that they often are not addressed and the result can be fairly painful. I’m not claiming my list of questions is unknown – heck it’s right there. Of course, it’s never complete. Each situation will have different questions. But still, even if you prompt a good lead developer to address these issues, you likely will still have a bit of a gap. The lead developer will often be:

  • Limited by experience and breadth of knowledge – may or may not be aware of other systems.
  • Most interested (and rewarded for) diving in to build things.
  • Challenged to pull together a good team.
  • Naturally motivated short-term because that’s the focus of development.
  • Tired at the end of a long day of development and probably not interested in thinking longer term.
  • Uninterested in or unable to add much value to investor presentations, business proposals, new business meetings.

Again, I wouldn’t claim that it can’t be done. But it’s just really hard for everyone involved.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.