I'm curious what the path is to move from developer into a CTO/VP/Product Lead type role, for anyone here who has made the jump from nuts and bolts. How did you go about it? Did it just happen, or did you actively need to push for it? Would love to hear more from someone experienced, because from where I sit, it's hard to figure out how to jump that divide.
Similar to rheesyb. I'll speak mostly towards CTO/VP as I think Product Lead is fundamentally different path and I have no personal insight to offer there.
Work your way through direct technical leadership positions within squad/team/mod/whatever structure your company uses. Team lead is generally easy for technical folks as you can mostly fall back on technical expertise. Then try a multiple team leadership role, where you start to exercise more management, social, and coordination muscles. This will probably feel harder, and if it doesn't, check to ensure that you're actually doing it and not just leading from a pure technical point of view.
This should also give you exposure to budgeting, more experience hiring/promoting/coaching/firing and a clue of how much you like it and how much the employees working for you appreciate your style. If you leave drained of all energy more than a couple days a month, maybe it's not for you and you might want to stay at the team/squad or tribe level leadership roles.
Of course, all of this is in the context of "join a growing company, as that's where opportunities internally are constantly being created." It's much harder to be hired in from the outside into a leadership role if you've never led. The path to people leadership involves internal promotions along the way, IME.
One possible path is to push for a senior developer role and then afterwards a tech lead (or similar) role (perhaps not at the same firm). That will then open up CTO or dev manager roles in startups. It won't "just happen" - it will require a whole load of work on your behalf (you'll need to learn your way around a broad selection of technologies rather than focussing on mastering one language and one platform, as well as learn a number of managerial skills including effective communication, negotiation etc.). Good luck! Disclaimer: I'm not a CTO but have been offered a number of CTO and dev manager roles at startups and small companies.
Short TED-like version: do not follow, be followed. Easier said than done :)
I know what it is like to transition from an intern to sort of Product Lead in a small shop.
Such role will not be simply handed down, though the opportunities will. Collect worthiness points. Dress for the job you want, not the one you have. Some possible general opportunities I see (not everything applies in every company):
1. Assess whatever is important to your direct management and be reliable. The idea is to have more or less consistent performance.
1.1. e.g. Say they think feature A takes 100 hours, feature B takes 50. You know they both take 75. Do A first -> spend 25h on B -> release A -> finish B.
2. Make others happy. This is important to reduce resistance for growth.
2.1. If you have options to make solution elegant and easy for others to use/integrate with, take the latter. Code has to be maintainable, but if you are the sole maintainer, others will judge public API, not the internals.
2.2. Be helpful. Do not help with every struggle everyone faces, you have your own tasks (and to maintain worthiness points), but if you personally can do this task in an hour while it would take the one assigned much more take the responsibility. Maybe their solution is suboptimal or they lack knowledge/expertise.
2.3. Make yourself authoritative source. Do not give advice/answer where someone else could give better one, but rather direct the question to someone who could actually answer that. Unless it is an opinionated matter, e.g. git vs hg.
3. Increase you scope.
3.1. If you see a better solution or problems down the road - communicate those. Might be an oversight or might be judged unimportant by management. Show that you can assess the situation and that you care.
3.2. If you see an opportunity to work on broader issues - take it. This might mean jumping to a smaller project, but taking [small] managerial and architect-like responsibilities.
4. As a new hire you have a unique possibility to grow really quick: instead of doing what you were hired to, you can attempt to prove being able to take "higher" role. Most probably this would mean taking more responsibilities for the same pay.
5. Collect trophies.
5.1. Finish projects. Then you can say "I've done that" instead of "Worked in a company doing that".
5.2. Jump ships if the company/product is going to fail, but assess. Even if Tesla would have failed, engineers working there would still be valuable for creating awesome product. There is a difference between product failing because of being flawed/suboptimal/unsuitable for the purpose and failing because of poor marketing, sales or other market reasons. Git quite possibly would have failed as a commercial product.