Ask HN: Going from CTO to Developer?

[thatguyagain]

Let's say you work as a CTO at a failing startup, and you are tired of all the responsibilities, management, etc, and you just want to go back to being a productive developer and write code again. Will this be perceived as a stupid career move or will people understand? Is it a bad move? Asking for a friend.

[simonw]

I've done this. I have friends who have done this.

I'm personally a big fan of the "Engineer/Manager Pendulum" model described by Charity Majors: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...

Engineers who have spent some time in management are extremely valuable. They have a better grasp on how things work, they have better leadership skills (you don't need to be in a management role to provide useful leadership within a company) and they're generally useful as all-round contributors.

There will be people out there who will mark you down for this. That reflects poorly on those people, but that doesn't mean they won't be in positions of influence where their poor judgement can still impact you negatively.

There will be plenty of other people who get it, and who will respect the choices you have made.

And you can always swing the pendulum back again later.

[convolvatron]

the only problem with this is that as an IC when your manager is really doing poorly and not grasping their job, its _really_ hard not to say 'dude wtf, that's just not right'. that can go pretty badly. so you really have to work hard to stay extra constructive and support them as if you were _their_ manager, without the authority that usually implies. and that's a heavy burden as an IC

[ldjkfkdsjnv]

This is partly why ageism exists. The longer you have worked, the more obvious the failings of your superiors are. Older workers are harder to trick into working on some project that will fail/produce no business value.

[jf22]

Conversely, older workers don't really care about what has business value and what doesn't, and if they did, they certainly care less about getting entangled in a discussion about it.

I know a lot of older workers, myself included, who don't want a seat at that table anymore.

[ed312]

As an eng manager, I always make it super clear (many times) when new engineers onboard they're always welcome to say "this doesn't make sense" ask for more details. Sometimes (maybe even often) they're right. I also enourage them to "assume good intent" from other devs and managers. Fundamentally no one manager knows everyone and no one engineer is right about everything.

[hnfong]

Yea, the problem is that bad managers likely end up being bad because they don't have this humility.

[convolvatron]

I don't think it's really a question of humility. it's more about placing the highest value on the functioning of the team. once your overriding goal is 'not looking bad', and 'escaping blame', that goal, which should be primary gets completely lost.

[VirusNewbie]

When I've had managers who have less experience than I do... I simply end up not really being managed by them. They appreciate someone who can 'manage themselves' and I don't have to deal with them coaching someone who could coach them.

I've also had peers become my manager, and vice versa, and that's the dynamic that seems quite successful.

Now if your manager is so bad that they can't recognize you are an extremely low touch employee...well, it doesn't matter the experience level, you'll be in for a bad time.

[yieldcrv]

hm, that might be happening to me, I'm an IC right now

I make it pretty clear during hiring that I don't have aspirations beyond IC anymore. Been there done that kind of vibes, I like to build. I say my value add is that I can add a vote for whatever policy or method would improve an org, people seem to like that.

But I'm currently on a team where leadership is doing everything outside of the sprint cycle, random demos in the middle of the week that nobody ever heard of before that day and so we must have all these features ready for right then, so I asked - I thought - a light question in the middle of the standup "are we using the sprint cycle?" because we have 2 week sprints and standups. and that was the.biggest.deal I've ever seen, all the leadership was convulsing amongst each other because they all have to show face to each other, instead of addressing their incompetence. "We- we- we'll take this offline!"

the meeting offline never happens. leadership can't be reached throughout the day. and the other IC's I do talk to (who don't know I've been in other non-IC roles before) act like I asked the biggest boat rocking question ever and I'm putting a target on myself.

To me, thats funny because the biggest boat rocking question would have been "why don't you do a demo from the staging branch that you're supposed to merge from dev in a schedule that's parallel and independent of the sprint" "why don't we have a staging branch, do you know what you're doing?" "why are you merging our pull requests in any order, not knowing the code base, and then yelling at us when there are merge conflicts, we should be reviewing each other's PRs"

Its actually a tolerable position,

but maybe there is a reality that I do have other jobs and maybe more comfortable about my prospects than other ICs there, and also have management experience that is impossible to hide.

[vrinsd]

This reeks of a situation where the people in the management position(s) really aren't the right people for the job and having a logical discussion or trying to explain how or why something should be done differently falls on deaf ears (or worse, antagonizes them).

Maybe I'm projecting from my own experiences but this usually is because the leadership has a "top down" mentality, "we know better because we are in this role" and your other team members who are likely less experienced than you can't tell the difference between "dissenting with evidence" vs. "being contrary".

Seems like the best plan is to keep your eyes open for other opportunities when it's no longer tolerable.

[yieldcrv]

edit: I got fired today for that

[yowlingcat]

You're a newly fired IC? In a comment several days ago about vesting schedules it sounds like you were speaking as a cofounder. If these were the same role then something smells suspicious about how your coworkers were treating you from the start IE any of these leaders and the general style of operating the company should have included your input. Moreover, I'm surprised they'd make a decision like this so flippantly as I'm not sure how it could be easy to fire a cofounder without significant legal headache to the company.

[mousetree]

You got fired for just asking "are we using the sprint cycle?" There must be more to this story, no?

[yieldcrv]

Yes, it is top down management, and comically ineffective for application development

We’ll see.

[AnimalMuppet]

> and the other IC's I do talk to (who don't know I've been in other non-IC roles before) act like I asked the biggest boat rocking question ever and I'm putting a target on myself.

That tells you much about the culture of the place. The other ICs know that you can't ask questions like that - they know that not only is the place dysfunctional as far as the sprint cycle, but it's vengefully dysfunctional - management will get you if you point out their dysfunction.

[tylerrobinson]

This is true, and it’s also true when you’re a manager. You always need to manage up and down.

[erkmene]

This is an exceptionally profound observation. IMO not having a strong ego helps and if it goes right, everyone benefits from this.

[PaulRobinson]

I did this from a hands-on CTO role at a 20-person startup to a senior engineer at a 200 person e-commerce outfit known nationally in the UK.

I was miserable for a long time, and sat down one day and made a list of all the things I liked about the job and all the things I hated. Everything in the “like” column was dev work. Everything in the “hate” column was the management work. So I slept on it for one night, quit, and went hunting for a dev job - this was 2015 so not too shabby.

There were a lot of things about this move I regret. The pay cut, the fact that my office in London got shut down as a consequence of my quitting meaning nearly everyone was made redundant, the fact that at my new role I was kind of resented a fair bit by other engineers.

But I was a lot happier and settled in my life. And nobody else can do that for me. I had to own the actions to make my short life on this planet better.

I’ve done management work since, and I’m now back to being an IC at a FAANG, but not as a software dev. I am now thinking about getting back into dev but it’ll get harder for me now I’m in my mid-40s.

I say if you aren’t happy, do it, but realise there will be some pain points. Ride that out, keep your head down and stay focused and you could be a lot happier.

[varispeed]

> but it’ll get harder for me now I’m in my mid-40s.

Only bad thing about age is that in many organisations you will deal with people that don't have that much experience as yourself and they are not aware when they are making a mistake doing something, because they read about solution on some happy clappy blog or something. Less experience people tend to go into arguments more easily to defend their position and you have all seen this many times over. Unfortunately there is no easy way to get around this. Typically you get to explain things over and over and it may get really boring, as new cohorts come in. In most places the problems to solve are all the same. Take data from one place, transform it and put in another. Progression to management in that sense is where you get people to do all the boring stuff, that is still fun for them and you keep an eye so they don't screw things too much while yourself taking care of the big picture.

Probably best way is at that point to start own business. More fun and reward.

[jmspring]

I’ve been in the same boat. My soon to be ending role was as a lead/IC but the actual work was more devops than actual development. It was cushy and pays well, opting to get more hands on writing code and building things which is much easier than at a large company.

[ilc]

Don't let age stop you, people make a big deal out of age discrimination.

There is some, but there are good dev roles out there for those of us closer to the AARP card than the college ID ;).

[__d]

Yes, it will be perceived as a stupid career move.

No, people won't really understand.

Is it a bad move? There are no bad moves, only bad reasons?

I was not CTO, but I was basically doing that job without the title. My company was slowly failing (although no-one would admit that at the time, it did go bankrupt 9 months after I quit). We'd moved to NYC for the company, on a company-sponsored visa. My partner and I had just had our first child. Like your "friend", I was pretty tired of management, politics, the constant scramble, and trying to fit some actual building stuff in between.

So I quit, moved back to my home country, took a few contracting gigs for a while, and then went full-time as a software engineer at a medium-sized company.

It was absolutely a backwards step, career-wise. Less pay, disconnected from the startup scene, outside the networks I'd spent years building. It easily put me back 5 years, probably more like 10, in terms of career.

OTOH, I was working from home, with heaps of flexibility, which was perfect when my kid was little. For a while, we both worked 4 days, one weekday off each at home just hanging out with the kid. Work was fine, but I kicked the obsession that it had just about become.

10 years later, I haven't tried to climb back. I do 5 days full-time now, but I'm just a senior engineer. I miss the challenges, but not enough to want to go back. I get paid less, but I'll probably live longer, and certainly better, this way.

Everyone's different. Some people leave tech, and make furniture in the woods. Some people just pull back a bit. You can pause and then have another tilt at it once you've recovered a bit. There's no rule book, really. Do what feels right and good.

[subpixel]

Thank you for sharing. I feel like this is sound advice though everyone’s mileage may vary, so to speak.

[thatguyagain]

Thanks, I appreciate your perspective!

[excto]

I'm an ex CTO. I ran the company as basically 2ic for 5 years before I quit.

Before I quit they offered me profit share which was stupid because profit can easily change.

I do not regret leaving at all from a mental health perspective. I was losing my friends, family and myself.

I do regret leaving because afterwards I'm just a loser developer, lumped in with the guy that moves the button left a bit, when before I was orchestrating tech strategies and winning.

I think I'd have been better off staying as CTO, not because "profit share" was attractive to me, when I had no say in expenses, but because I was good at making a business succesful. Sitting here pushing pixels and spreadsheets sucks.

Every situation is different though. The only lesson I learned was that every job is hard but in different ways. Going back to dev felt demeaning. Watching inexperienced sales people ignoring what matters to people buying services. Trying to have an opinion but being told in no uncertain terms they don't care because I'm a nerd and people don't buy from nerds.

Seriously it's been difficult going backwards. I think I would have been way happier still being in charge.

[vrinsd]

Very possible outcome for OP too.

The weakest part is usually the human factor and the need to bucket someone into a few categories like "rock star" or "loser" or "slightly better than unskilled labor" or "nerd engineer".

Have been in a similar situation and sadly found unless your peers have truly understood what you've done and how, they'll filter your suggestions or insight through whatever bucket they've placed you in.

[subpixel]

Perhaps when you’re willing to trade a prestigious title for some sanity and personal satisfaction you’ve already determined that it doesn’t matter what your peers think or what gets decided.

They key is that you can’t just stop doing what you hate but you have to be able to lean into what gives you some satisfaction.

[vrinsd]

In my experience its's less about caring what people specifically think of you, and more about how you are treated in whatever team you're on.

Example: I made a trade from a key role to a dev role in one job change. In dev role I was working with a technology I had significant experience with in my prior "key" role. In the new role, when the topic came up, I suggested we avoid certain vendors since in my prior role I was responsible for the technology vetting and I determined the chosen vendor was not forthcoming with some important limitations. My feedback (constructively and succintly presented) was completely ignored since I was "just a developer" and I ended up having to make the sub-par technology actually work.

It was frustrating and painful, not because of ego, but going into the task knowing it would suck since the wrong decision was made and now I was the guy having to make broken pieces meet some demanding requirements because "a developer" couldn't possibly know more than an "architect".

[ipaddr]

Save your opinions for your own projects. Let someone pick the wrong vender and pay more. This won't affect your profit share because developers don't get it anyways.

[vrinsd]

Normally I'd agree with you, the exception is if you're the poor "schmuck" that has to deal with the aftermath of said opinions or decisions.

I don't know about other developers & engineers but I've already learned quite a few lessons the hard way and don't need to burn my evenings and weekends knowingly doing something the wrong way.

You might say "That's OK, that's what they're paying you for" but if you've been in this situation, usually someone less knowledgable, bordering on clueless will draft a schedule and you'll be the guy to make it happen. So a bad technical decision turns into a pressure cooker which then turns into more stress. Which is similar to another poster who said (I'm paraphrasing) "each job will suck in different ways".

[ipaddr]

You left previous job because you didn't have enough control but moved into a job with less control.

[ldjkfkdsjnv]

Not sure why this is getting downvoted, its a real experience.

[CSMastermind]

How big is your team?

People overestimate the importance of titles.

Anyone can start a company and call themselves a CTO. Plenty of line managers at big tech companies have more responsibilities than CTOs at start ups.

As long as you're not 5+ years into people management and have a team of less than ~50 it shouldn't raise any flags with most interviewers. People switch between manager and IC all the time.

Just have a good story ready, be humble, and demonstrate good self-awareness and you'll be fine.

[jgrahamc]

This is kind of what I did. I was VP of Engineering etc. at different companies and wanted to go back to coding, see: https://blog.jgc.org/2012/02/programmer.html.

Of course, I then ended up being CTO again!

[thatguyagain]

Cool, sounds like it worked out fine for you!

[vrinsd]

Wow, Madge! I once deployed Madge PCI Token ring NICs. Worked damn well.

[jgrahamc]

I probably wrote code for those, although I actually started coding on the Madge token ring NICs during the ISA/EISA days.

[thebeardisred]

No one is forcing you to name the role as "CTO" on your resume. Be creative.

[vrinsd]

This is a great suggestion.

[triyambakam]

If the start up is not well known and depending on where you interview, you can just change your title to Lead Engineer or something similar.

A small start up CTO is nothing like a CTO of a big successful company.

[michaelt]

> Will this be perceived as a stupid career move or will people understand?

Most people in tech know everyone who founds a startup immediately grants themselves a grand-sounding title, it's traditional.

Nobody will think it strange if a 22-year old startup CTO with 4 reports switches to being an IC at a big corporation.

[beardyw]

My career was a rollercoaster. You will never know what might have been, but it is important to be happy (enough). Ended my working days as a WFH contract developer which by then was perfect.

[tptacek]

I flinch whenever I see people talking about "being a CTO", because there's really no such thing. The title doesn't really mean anything. In startupland, three possible (and possibly overlapping) meanings of the title are:

1. The corporate officer title a founder that isn't the CEO gets because they're on the board, purely as recognition of their seniority ("why is this person on the board?" "because they're the CTO.")

2. The consolation prize a founder or early employee gets when the mature engineering organization takes away their commit privileges.

3. The fluffy title a founder or senior employee gets when they transition to a customer-facing role so that prospects are (ostensibly) impressed.

These are all situational and don't really describe a "role". Excepting case (1), I would be a little alarmed if a company I worked at asked me to assume a "CTO" role. Either way: having been a "CTO" says basically nothing at all about whether you're lateral to software developers.

Your question makes more sense if you consider the move from VP/Engineering to developer. Either way, you're completely fine from a signaling perspective, but you're especially OK if your title was "CTO" and not "VP/E". The last thing in the world you should want is a career trajectory defined by "CTO-hood". Yikes!

[adastra22]

CTO is an actual role with well defined responsibilities in most companies. I’m sorry the ones you worked at sucked.

[tptacek]

Yeah? What do you think that role is?

[adastra22]

CTO/VP Engineering have the same separation of tasks as CEO/COO.

The CTO is the chief engineer he or she sets technical direction for the company. VP of Engineering is the top manager for that division and executes the CEO’s vision using technical choices made by the CTO.

In many companies these are the same person, but not always. In my last startup they were separate people. The best chief engineer (CTO) isn’t always a good people person (VP).

Software companies that differentiate by some metric other than core technology might not need a CTO, which would explain your confusion if that’s your background.

[tptacek]

"The CTO is the chief engineer" is both false and somewhat circular. It's false because plenty of "CTOs" --- maybe most of them! --- work outside the engineering organization, and are more closely aligned with product management than software development (CTO is very often a customer-facing "role"). It's circular because it leaves open the question of what a "chief engineer" is.

I worry that a lot of HN "CTO discourse" is really wishcasting, about what an "if I was monarch of all the developers" role would be (and then about what it's like to aspire to such a role). No healthy engineering team has such a person!

[adastra22]

The chief engineer is the one who makes final engineering design decisions.

What industry are you in? In deep-tech / hardware the role of chief engineer is well understood. In biotech it is sometimes called chief scientist.

[ldjkfkdsjnv]

Surprised to see such a cynical and negative comment from such a well known account. CTO at early stage startup is often the most important person in the company, technical delivery/execution, hiring, early decisions on which frameworks, integrations, helping with sales, etc.

[tptacek]

I could not disagree more strongly about the importance of a "CTO" in an early-stage startup. With few exceptions, you're talking about functions of engineering management. CTOs of established companies are almost as a rule not engineering managers.

[senorrib]

The obvious cynicism aside, what you said doesn’t really contradict point #1. All those responsibilities can be taken by any IC in pre-seed/seed startups (except the wrongly stated “most important person on the company”).

[ldjkfkdsjnv]

Sure, but then that IC, if executing correctly should just leave and found their own startup. And true, sales/building the right thing is often #1.

[tptacek]

This is like saying that every successful product manager should go found their own startup, which, come to think of it, fair enough.

[senorrib]

Agreed.

[varispeed]

Small company would typically call their lead developer a CTO. Though I've seen once this was actually backed up by giving the person real share of the company and a seat on the board.

[tptacek]

Why would a small company call their lead developer a CTO?

[MakeThemMoney]

Because titles are important to some, and can be used as an incentive to lure people in.

[tptacek]

I'd be interested in some examples of where this "recruiting talent by offering to call them 'CTO'" strategy --- which I know has happened! --- has worked out, and what the actual role description for those "CTO"'s was.

[bcaxis]

I've seen such title inflation work for people.

Recently watched a relatively young person parley a position at a small company with a VP title that resulted in a slot at a regionally well known organization as a director and then president of a much larger startup.

Over about 4 years he went from front line sales to running a sizeable company with the key step being the VP title at the small company that rocketed him up.

I also recall a former co-worker that was denied promotion and generally failing to progress in his career. He took a slot at a tiny company explicitly for the title. I think it was director. He managed to parlay that into very positive career moves.

Personally, I don't care as much about titles these days. I just don't want to work for places making terrible tech decisions and forcing me to work within that. I'm happiest making the decisions and really don't want to stop, whatever it's called.

[lulznews]

Extremely based and uniquely insightful comment. CTO is basically a bullshit job. At small companies it’s just an eng manager or lead eng. At BigCo’s it’s just some guy they pay a lot and trot out for occasional keynotes.

[flashgordon]

Ive done this a few times. Depending on the startup (size, domain, technical complexity, resources) it could just a coder with a fancy title. Now nothing wrong with that if you are getting to build freely, solving hard/interesting problems or working on problems that somebody is willing to pay tangibly for or you are trying to just get your startup creds up for your next play.

But I have found often startup CEOs look for CTOs for a few tactical and myopic reasons. They cannot code (or worse cannot design beyond copy-pasta from stackoverflow) or just to bolster their "look we have a faang-er as CTO" creds. Just as often the CEO has very little business or product sense (not to mention any leadership) but just needs a coder to build out their ideas (usually half baked ones in a very reactive fashion). Here you will also find that there is a new direction each week based on what a lead told them in passing.

Worst of all you will have very little resources (are you the sole coder/CTO?) but will be blamed for all the wrong choices (dont worry about writing tests - we dont have time ===> why are things breaking?).

The pendulum in this case is not a bad choice. Typically after you are burnt by one startup it doesnt meant all startups are bad. Just that you could use that big-co IC role as a charging station. Or if you actually like management (and there are lots of reason to) you could always switch to management in a big co and then go back to a startup more worthy of you. Now obviously you are the mercy of the hiring committee/team/market so a better story for why the switch definitely helps.

[Black-Plaid]

I did exactly this, was CTO at a startup, it failed, went back to being IC at a large company, then went into management again and realized I am just not happy in that role.

Went back to IC roles, no regrets, much happier with what I am doing. Money isn't everything, as long as you have enough to live well, you don't need to make 7 figures, just make sure you are working toward a couple million in investments for retirement if you are in the US.

[vrinsd]

As much of a non-answer as this might seem, it will really come down to the people in your team and your new management which you won't really find out until the interviews and more realistically only when you're actually working with the new team.

If you have solid team members who are secure in what they know and their position they'll appreciate your broad(er) skillset and will want to work with you and it will be a non-issue. If anything they'll respect you tried something "beyond" what a normal senior engineer might do or get to do.

If you have one or more people who are insecure or "not an A-player" they'll likely view you as a threat to their career progression and you'll have to be cautious around these people.

A good / great manager wants people of diverse backgrounds and experiences, a mediocre manager might feel threatened by you because your insight might challenge his authority or the concept of it.

If you're interviewing with a team they'll likely know your background, but if it doesn't come up I wouldn't go out of my way to discuss your CTO role, just stick to the technology parts you've worked with.

[iamflimflam1]

I would suggest that a lot of the negative feelings you may be having come from being in a failing startup.

The problem you have in a failing startup is you don’t have any scope for bringing in help for yourself. Can you hire a VPEng or Head of Engineering to take on a lot of the day to day management and delivery responsibilities? You can move yourself into a much more technical/R&D role.

Another thing to remember is that “CTO” can encompass many different things depending on the size of a company.

Very small early stage startups - the CTO is generally the most prolific IC. It may be that this the sweet spot for you.

Businesses often require different CTOs for different stages and there’s nothing wrong with being a particular type of CTO. You can say - “the role has evolved and I’m no longer the right person”. Or “my strengths are in these areas, I need people to fill in these gaps”.

[mattlondon]

Not a CTO but I fairly recently went from an engineering manager at a Big Co (I had 8 to 12 engineer reports, some junior, some more senior than myself) to an IC engineer at the same company.

If nothing else I think I am a much better engineer as a result of several years of being a manager because now I know the "other side of the coin" and won't shy away from the people-parts of engineering. I am much happier and way, way, way less stressed. I think other engineers respect the decisions and you have greater impact and influence since you are a great engineer AND you can also do the management dance so others look to you as a natural leader.

I'd recommend a few years as an engineering manager for any aspiring engineer.

[piterrro]

If you want to go back to IC role, that should not be a problem anywhere really.

If you are tired of "all the responsibilities, management, etc" then you will probably not follow that path anymore, you tried and it's not for you.

However, if you ever decide to follow that path again, be advised, boards/founders want to hire C-level people who have a proven track of building successful organizations through good and bad times. Having even a single occurence that signals you were "tired of all the responsibilities, management, etc" will disqualify you.

[SkyPuncher]

I’ve done this several times. I’ve also worked for and managed several.

In my opinion, it’s great because ex-CTO types know what their managers need and are typically very easy to manage.

[lr1970]

One of the most interesting examples is Mitchell Hashimoto of HashiCorp fame (13B publicly traded company). His career path was: HashiCorp CoFounder -> CEO -> CTO -> Engineer -> finally left HashiCorp in December 2023.

Now he enjoys private life while creating a super-cool Ghostty terminal in Zig [0], currently in private beta.

[0] https://mitchellh.com/

[sgt]

Something tells me Zig is going to overtake Rust! Anyone, anyone?

[hinkley]

It’s going to lead to questions, especially if the time frame was long enough that they can’t just leave a gap on their resume.

One scenario I could see working is moving from CTO to founding IC for another startup, but that conserves a number of things your friend might be tired of. Like long hours, and sitting under the Sword of Damocles 24/7.

[rufius]

Having watched this first hand, you won’t be treated the same. Maybe that’s a good thing, but people will assume you get to do whatever you want which, generally, shouldn’t be true.

It sets a strange precedent sometimes too if not well communicated and managed.

[suyash]

It might be considered a failure by some, but so what, do what you feel is best for you.

[madsbuch]

I would say that the right thing is a sabbatical. tell your friend to take 6 months to work on something they find is super. interesting or important. new opportunities will emerge and feel natural.

[gravypod]

I'd love to hear about the other direction. What kind of skillsets or prep can a problem solved do to transition into more leadership roles? Is it primarily getting an MBA? Getting lucky?

[simonw]

No need for an MBA. You can make your own luck here: start by taking on voluntary leadership roles such as mentorship, or running initiatives within your company (setting up an informal team to codify source code management practices, that kind of thing).

Make sure your own management know that you are interested in this path.

The book The Manager's path has excellent advice on ways you can prepare yourself for management positions: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

[gravypod]

> start by taking on voluntary leadership roles such as mentorship, or running initiatives within your company (setting up an informal team to codify source code management practices, that kind of thing).

This I have been successful with at multiple companies. Often bringing a complete shift in development practices / headcount allocation strategies. I've setup multiple teams and initiatives at my current FAANG employer as an L3/L4. My most recent one was a library which is being used by extremely high priority projects with VP-level visibility.

> Make sure your own management know that you are interested in this path.

This is where I have been extremely unsuccessful. I explained that at some point in the future I wanted to be at the Director or VP level. One of the higher level employees that I was discussing this with laughed at me (she also did the same about my library and other initiatives only later to applaud when our VP thanked me for landing them).

My manager and skip level manager are advising to "take your time" and "you may not actually want that" and similar things. They say to focus on L+1 which I do understand as a priority but what I am really trying to communicate is:

1. Long term I'd like to be higher level leadership

2. I don't know if the skills I am learning right now will put me on this path

3. I want to in the short term work on high impact projects and in the long term build the muscles needed so that when I say "I'd like to be a director" no one laughs at those ambitions

[ldjkfkdsjnv]

Only advice I can give you is pick your team/company very carefully. Choosing the right team can open up promotion opportunities that other teams might not have. Half the battle is putting yourself in the right situation. Also, big promotions commonly go to people that have lasted a long time in some organization. I saw people at FAANG spend a decade in one organization, then finally get recognition and ended up a few levels higher in a quick fashion. The people you spoke to were laughing because the high ups probably got there very early, there is no path to their level because the cake is baked, that company doesnt have growth opportunity.

[vetrivelcsamy]

Yo, fake it till you make it, I just changed "software developer" to "product designer".

[KingOfCoders]

(CTO coach here) Several of my clients have gone that way. Though I would ask people to just write code. Look at DHH, you define the CTO role and you can delegate stuff, not go to meetings and write some code.

[brudgers]

Does your friend think it is a stupid move?

That's what matters.

Life is much bigger than careers.

Good luck.