Looking for advice on developing my skills as a CTO

I'm currently in the process of building a startup with two co-founders (both are business people). Since I've been a developer in a wide-range of technologies I'll handle the CTO role.

This won't be a small project and I'll have a couple of developers to lead from day one forward. I have worked in teams before and taken management classes during college, but those were theory, not reality.

I'm a little worried I won't be able to handle some of tasks as well as I could if I had more experience in that area - namely leading and motivating people.

To better prepare for my role I decided to start with a book. Searching on Amazon yields mostly books from 10+ years ago with (few but good) reviews. I'm afraid they'd be a little out of date. The newer ones have no reviews so it's hard to tell if it's any good.

Can you offer me any best practices on being a good CTO, and developing my skills as one? I don't want to make some rookie mistakes and get fired.

Code complete 1st edition, 1993. Still relevant.

To be frank, if reading books was the solution to your problem then every MBA or a software developer can become a successful CEO/CTO.

From your question, it seems your career is taking a big jump. From a developer to a CTO. I would suggest stop thinking about the CTO tag for a while. Look, your going to be a CTO of a 4-5 people company. It is very different from a CTO for a 100 (or even a 20) people organization. Just focus on your tasks and get on with it.

From your profile, your just 24. In my opinion your reading the wrong books. Learn software estimation, requirements gathering, code testing, software engineering and diversify your core skills.

Hire developers who are self motivated. I get fired up when there is some complex problem to solve or when some interesting development comes up. I don't need some manager to come and motivate me.

To lead the developers, you will have to be better than them. They must look up-to you for solving problems or better solutions. You will have to earn their respect. A CTO tag will not help. It does not necessarily mean you need to be a better coder, but when someone comes to you with a problem or some issue, your response should be satisfactory to them.

You have worked in teams before, did your colleagues or managers look up to you as a prized asset? Were you the person everyone looked up-to to when things go wrong. Were you the person who was called to solve the nastiest of bugs? How efficient were you in speaking about issues or problems with the management? Are you a good negotiator when it comes to salary discussions? Your non-technical will be as important as your technical skills. Answers to some the these questions can help identify a good leader.

As a CTO for a very small startup, you will have to be Lionel Messi, Steven Gerrard, Iker Casillas, or Jose Mourinho as and when different situations arise.

Do you guys have any good literature suggestions for me? Something that also includes "Best Practices" would be nice. I don't want to make some rookie mistakes and get fired. Things don't happen in day. Don't be scared of failures (it seems your scared). Do not take decisions on the spot. Take your time. Be humble. Don't be a 'boss' but also not a 'friend'. Writing good code does not necessarily means better profit. Project deliverables will be your biggest challenge (read the right books as I said previously).

Have a good night's sleep every day.

I disagree with Aseem on the point that you have to be better than your team to earn their respect. I agree with his sleep comment. ;-)

A CTO isn't a better coder, they are a better leader. A CTO hires people who are better technologists than they are, encourages them, respects them, and ensures they have what they need for success. A CTO also holds them accountable, and ensures they work within the given process.

Given that you are a developer, I certainly would be coding with them side-by-side, but don't ever get in a pissing match about who's a better coder. Also, don't ram your ideas down their throat, but listen and evaluate them as objectively as possible.