Ask HN: I don't enjoy being a CTO.  Now what? - <AUTHOR> I recently joined a startup as their CTO and I'm hating it.  They've been around a few years and have product market fit and now need technical leadership to grow the team and product.
It's my first senior management position, having been heavily code focused the last 12 years, with some small management as a senior/lead.
For my entire career I feel as though I've been working towards being the CTO and now I'm here I find it's not at all what I expected.  It seems to be mostly about dealing with everyone's crap, trying to fight fires and constantly battling with the other managers and tech team to get things done.  I haven't even written a line of code in months.
Over the past few years I've had a few gaps in my career where I have started my own business and been fully in charge of things.  Those times were amazing although I never reached any level of sustainability.  I thought perhaps being CTO in a startup would give me some of that same ownership, control and enjoyment but it just feels like another job.  I actually feel a bit depressed by the whole thing which is a new sensation for me and my personality.
Am I expecting too much?  Is it simply another job?  What can I do to fix this or should I leave and get back to a coding job?
I'd love to hear from people with similar experiences!
PS. Sorry for the throwaway account but my main account has too much personal info for this topic! <comment><USER2> tl;dr: in your situation many people go off and get an MBA. Don't do that. There's a reason there's only one CTO in HBS' 60,000 person alumni database (I am she.)

I was a very hands-on CTO for years after a decade of coding, and broadly enjoyed it. But as the teams I managed grew it became increasingly unfulfilling. When you're CTO, you're often excluded from business decisions which have a bigger impact on your team than any tech innovation, and the input you do have can be hard to relate to the shared business context of the CEO/COO/CFO.

So I went and got an MBA (Harvard).

Now I know exactly how to frame (and improve!) my non-technical contributions, have much more context on what "success" means, and have the credibility to really be a part of the senior team.

Unfortunately, there's no real place in the world for a highly technical business leader. You have to leave code behind at a certain point and spend your time on people/financial/planning issues. The ultimate end of that road is CEO, and not everyone wants to go there.

Also, I'd really misdiagnosed my malaise. What I'd been missing was not strategic input, but the opportunity to _build_ things. To weave together inspiration and ideas into innovation and growth. I love building things and challenging assumptions, it fulfills me.

Now I'm off to start a new venture as a solo entrepreneur. The only truly successful technical leader is the founder, and that feels right. My last day at my day job is June 30th. :)

<comment><USER3> >there's no real place in the world for a highly technical business leader.

Bill, Larry and Sergei, Musk and Bezos did ok

<comment><USER2> All of those people are founders.

My thesis is that there's no place in the world to be _hired_ as an engineer w/ an MBA (which is comparably compensated to and inaccessible to "just" engineers or "just" MBAs), and no place within traditional hierarchies.

<comment><USER3> Ah - got you. Though I could counter with Satya Nadella who had a degree in Comp Sci and an MBA before joining Microsoft.

<comment><USER2> But he hadn't been a practicing engineer, and never worked in an engineering or technical capacity at Microsoft.

</comment></comment></comment></comment></comment><comment><USER4> What I'm about to say may be considered harsh, but I promise I don't mean it to be.

Quit. Just leave. Go back to coding. It's obvious you don't enjoy management, there's no shame in admitting that. Rather than inflict your misery on the rest of the team, get back to your wheelhouse where you can be happy, your team can be happy, and ultimately your company (current or future) can be happy.

I have worked in a job where the CTO (my boss) was in your exact position (in fact, if it weren't for your style of writing - English was very obviously his third or fourth language - I would almost bet money that you were him, your stories are that eerily similar) and it was a _miserable_ experience. $CTO was an otherwise brilliant coder who was on his first cto-gig outside of 'team leader'. Outside of work, he was a great guy - warm, personable, funny. At work, he resented not being able to code in many different ways, often with the team bearing the brunt of his misery. He'd often make decisions for others to implement, then second (or third) guess himself days or weeks later, insist we throw out all the work, and start again. He'd often be irritable, make rash decisions, have temper flare-ups, ask for feedback then get upset when he got it, etc. It was a bad scene for all involved, but the dude was a walking personification of the Peter Principle. He would have been infinitely happier remaining a coder, and his team (myself included) would have been infinitely happier with a CTO comfortable in a leadership position.

<comment><AUTHOR> Thank you for this, it's the way my mind has been leaning but it's good to hear. I realize my original post makes it sound like I had no idea what being a senior manager might involve which is just not true. I understand a lot of fire fighting and dealing with problems is par for the course I just didn't know if I'd enjoy doing that or not. How are you supposed to know until you try? :)

I also felt like I'd have way more control than I currently do. Perhaps that is a problem with me and if I simply took control and treated it like my own business I could change things enough to suit me more. But is that a good decision for the business? I'm not so sure. What's the point in changing things so much that the business suffers?

Anyway, your points about your previous boss really resonate with me right now. I'm finding myself increasingly frustrated and dreading meetings because I feel that frustration is coming across to the rest of the team.

<comment><USER5> The fire-fighting thing sticks out to me a bit, in part because it's caused me pain in the past and in part because you keep mentioning it. I might venture a guess that one of the underlying issues that's really getting to you is not the lack of actually writing code, per se, but that you have always had environments where you can get lost in deep focus or flow, and now your brain is being actively rewired to support continual rapid context switching. This is uncomfortable and unfamiliar and your brain is rebelling against this new environment.

I've never had a CTO title, but I've been in many similar positions.

In case you decide to stick it out for a while, I would suggest several easily implemented opportunities immediately:

(1) Establish an #engineering-support channel in Slack and a Triage calendar in Google Calendar. Put your team members on a rotating schedule to triage any engineering fires that the business has.

The Calendar should pipe into the Slack channel at 9 am every day. For a few weeks, send an "@channel please remember $engineer is your point of contact for today." By then the rest of the business should get the idea. Instruct your team that you trust them to decide which issues need to be addressed immediately and which ones need to go into the queue, but if they have any questions they can escalate to you. Also explain you understand that context switches are expensive, and you are totally okay if this causes a productivity hit on their given triage day.

It doesn't mean you won't be interrupted with real fires, but it does keep the less urgent ones from creating a context switch for you. Include yourself in the schedule, and you can send the message to your team "we're all in this together" instead of "hey I'm too good for this nonsense."

(2) The Business guys will respect your calendar, and if they don't, you have leverage to call them out on it because The Calendar is sacred in the business world. Block out 2 or 3 hour chunks throughout your week to work on hard problems. You drive a lot more value this way than with the fire fighting, anyway.

(3) The Calendar also works for time with your family. Daughter's Ballerina Recital? Block out 4pm-8pm on your calendar as soon as your hear about it—"Blocked—At Home"—and again, leverage if somebody wants to interrupt you with a fire.

(4) Train everyone on how to add each others' calendar to their own calendar view; this seems obvious to engineering, but less engineering-minded people may not know they can do that.

</comment></comment></comment><comment><USER6> The main problem I'm seeing with this kind of topics is this notion that "management" and "coding etc." are on the same vertical. That as an end result of a successful career as a professional is to move into management.

Well, that's just bonkers.

I used to be a coder. Now I'm in management and I've learned, the hard way, that management is it's own specialty ... and that the best managers don't see them self's as "above" their team, but the "team coordination & external communication" specialist of the team. The only reason for the extra pay is the expectation that a manager take the brunt of the "external" crap (aka. having responsibility for the team) so that the rest of the team don't have to and can keep working. Which means that just as you need knowledge and experience to be a good coder, you need knowledge and experience to be a good manager. I find the notion of going from "best in your field" back to being "the green guy" at the height of your career as utterly crazy.

But that's just me.

<comment><USER7> My very large company has 5 lanes. Purely technical is at the far right, purely management is at the far left. Our CTOs do not spend the majority of their career in the company in either lane and that seems to have worked out okay. I don't think people are particularly encouraged to stay in the management lane either.

<comment><USER8> Interesting. Can you put some descriptive labels around the three "middle" lanes as well? I'm trying to figure out the distinction that would make someone 25% management, 75% technical, vs 50/50

</comment></comment></comment><comment><USER9> If you are a hacker, then try to just hack the suckiness out of the job.

Take a mental step back, and look at the business as a large computer, everyone's crap as bugs, fires as serious bugs and dealing with other managers as a high level architectural/resource allocation problem.

Then get to hacking! Refactor the program (your role and tasks) until its running smoothly (i.e. you're happy) then start adding features. Learn to apply (not so shiny) new technologies (management methods, time management, people management). Set up a test suite to compare what you want to what you actually get. Red - Refactor - Green. (Seems like all your tests would be a solid red at the moment:)

Do top down and bottom up analysis - make specs for what you want as a CTO, and make specs for what you'd want (as a programmer) from an ideal CTO.

Set up your own performance benchmarking suite with the metrics that matter to you: Fun factor, coding opportunities, battle to relax ratio, etc...

Just make sure to stay ethical, DRY and most of all, keep it interesting and fun. No black hat hacking when dealing with people.

(Oh, and if you know parallel programming, start a new thread called $JOB_SEARCH to run concurrently while you do all this)

P.S. I've trained (successfully) quite a few new managers, specifically highly experienced technical staff that move into new positions of management. The most recent one I did was for a global telco hardware provider. I can send you some of my workbooks (for a 3 day course, covers the main basics about moving into management and being happy and great at it) if you want to hit me up - email is in my profile. I pinkie swear I won't out your real profile, or you can just set up a throwaway email if you're really worried.

<comment><USER9> Hey, I aimed that ^ comment at OP, but someone else responded, and I just sent them the workbooks. So I just want to let you all know, the offer is open to anyone who contacts me.

The only thing I ask is don't mass share the files I send to you. Send to your friends or whatever, just don't put them up on megashare or some shit like that.

(I know that that will happen, but at least I tried :)

</comment></comment><comment><USER10> Learning is painful, and it's tempting to just go back to your comfort zone. You dont really learn much in your comfort zone, and learning often feels a bit uncomfortable. Check out the Ideas behind "growth mindset" for more about this [1].

You mentioned the idea of management being about cleaning up crap and dealing with people instead of writing code. A few thoughts on that. There is a lot of people and management work involved in making code pay off for an organization at scale. Code by itself doesn't offer any value. It has to be in production, it has to be used by the customers, it has to be something that adds value for the customers. And it has to be managed in a way that the code is delivered before the competition gets a chance to sink you. Also code doesn't write itself, teams of people do, and those teams need to be built and maintained and recruited and taught. Making all of those things happen involves people relationships and soft skills. Your job is to make those things happen smoothly, guide and grow the engineering teams, prevent the fires, and establish the relationships that make that all happen smoothly and scalably.

It's a different set of skills from writing code, but it can be learned if you apply yourself to it and recognize the value it'll provide to your organization if you do.

[1] [https://www.ted.com/talks/carol_dweck_the_power_of_believing...](https://www.ted.com/talks/carol_dweck_the_power_of_believing_that_you_can_improve?language=en)

</comment><comment><USER11> I love being a CTO. You can design the technical organization you want to lead. If you are unhappy, change the design of your organization. It takes time (and money), but totally worth it.

I think the key when you achieve product market fit is filling the roles in your technical organization with stronger leaders than you, and stepping out of those management positions. Plus, you can learn from and partner with these people.

If you're a technical CTO, and want to code more than manage/build a team, then hire/promote a VP of Engineering with strong soft skills to grow/manage your team. If its the reverse, hire/promote a VP of Engineering who's technically stronger.

If you're constantly being pulled into engineering battles, hire/promote an architect you respect to negotiate.

If you're running engineering meetings (ipm's, retros, etc), hire/promote a SCRUM master or equivalent.

If you're battling sales, operations or marketing, hire a Director of Product Management with solid communication skills. That person will 'fight' your battles (and probably love it!).

If you're putting out fires in production, hire/promote a Director of QA. They'll work on designing systems to catch those bugs.

If your infrastructure goes down a lot, hire/promote a senior devops engineer.

On the engineering/coding front, I find it super helpful to rotate into teams and pair one-on-one with engineers. You get exposure to their day-to-day code battles/challenges/environments, the tech decisions at the lowest levels, the ability to code/manage daily and respect with your team. You can then prioritize stories/epics to fix problems that you see across your organization that plague a technical team like debt, environments, knowledge gaps, etc.

Don't step away, stay positive and solve for the organization you want to lead.

<comment><AUTHOR> This is a great response, thank you. Unfortunately for me, it's unrealistic as we simply don't have the budget to hire all these people.

I see a future over the next couple of years where I have someone great in each of those positions but it will be a long, hard journey to get there.

This whole thread has given me a lot to think about and I wish I could personally thank everyone. However HN is limiting my responses so it might take a while!

</comment></comment><comment><USER12> > I haven't even written a line of code in months.

CTOs generally don't write code. But, in a typical startup designations don't matter so much. How different is your current role from the one you were offered during the negotiations?

> I thought perhaps being CTO in a startup would give me some of that same > ownership, control and enjoyment but it just feels like another job.

Do you feel connected to the overall vision of the company? If you did, then you should look at the things you're unhappy with as bumps on a road worth traveling.

Since you do have the ownership (through your designation), you have power to change things that bother you. It's only when you start making visible impact, you will start truly belonging.

Finally, I would urge you to talk to other senior folks in the company openly about what's bothering you. Maybe you are missing another perspective that they will be happy to share with you.

<comment><AUTHOR> You are absolutely correct, I need to talk with the other senior folks and this question here was my way of hearing some thoughts before going through that process.

> Do you feel connected to the overall vision of the company?

If I answer honestly, then no, not really. I think it's an interesting idea that will end up making a lot of money but no, the central 'theme' of the business doesn't touch any interests or passions of mine. The role came about via my network and I was much more interested in moving into the role of CTO than the product. Writing that out like this makes me realize that was a big mistake.

</comment></comment><comment><USER13> The challenge of leadership is that of leading people, not of writing code. Dealing with people can be messy, frustrating, and depressing, but it's what needs to be done.

As a CTO, I code about 30% of the time, but I expect that to go down as our company grows. Much of the time I deal with people who were offended that so- and-so shot down their new design, or they think their career is being harmed because they can't rewrite the entire product in Clojure, or senior management is freaking out because of one minor bug that hits an important customer.

If you can see a path to where you want your company and team to be in a few years, then stay and try to move down that path. It is very rewarding to see tangible progress in your product and your team. If you want to be coding all day, find another job.

</comment><comment><USER14> That's life. The higher you go, the more crap you have to eat so those who deal with executing can execute without distractions. If you don't want to eat crap, you have to stay at a lower level (team lead/distinguished engineer/r&d labs)

On the other hand, being that high should indeed get you ownership and control, if you don't have it question your relationship with the CEO/rest of the company. You should own and be responsible for all the technical stuff, that is the upside of eating all the crap you can eat.

On a related note, if you are a good coder, you can and should schedule some time to do pair programming with the team to stay on top of things and actually write some code. But only as long as you are more of a help than a hindrance.

<comment><USER15> So.. about that non-eating crap low level job, any open position for me? :)

<comment><USER14> Depends on your skillset, but indeed we are hiring devs for our Madrid office. We are not ready for remote yet. We pride ourselves, among other things, in eating all the crap at the top.

Required Skills: C#.

Caveat: We want people that like learning new technologies, as we do use some other tech stacks other than .NET's. We will train you if you don't know it yet, as long as you are interested and capable.

<comment><USER16> Could you help me relocate? Inside EU. I don't know C# very well, but I worked with F# and also learned about some 110 other languages ([https://klibert.pl/articles/programming_langs.html](https://klibert.pl/articles/programming_langs.html)) and never considered stopping to learn new ones.

(Mostly just testing if it's really that easy ;-))

<comment><USER14> Sent you an email.

</comment></comment></comment></comment></comment><comment><USER17> I'm surprised that no-one has suggested getting a VP Eng alongside you.

[http://avc.com/2011/10/vp-engineering-vs-cto/](http://avc.com/2011/10/vp- engineering-vs-cto/)

<comment><USER18> I can't up vote this enough, this absolutely true.

This is the same arrangement I have at my company (me the CTO), I can focus on the code, architecture, devops and the VP Eng. can help build the team, work out personal troubles with the developers. Obviously there needs to be a good relation between the two for this to work.

</comment></comment><comment><USER19> I think part of the problem is that we often see CTO as the holy grail for the technical side of things, where that is the final stop in a linear career path. DEV > SR. DEV > ARCHITECT (maybe) > TECH LEAD > DEV MGR > VP/DIR > CTO

If you love coding and solving problems, you may find yourself less fulfilled farther down that line.

We're also talking about titles that end up being somewhat arbitrary and non- transferrable once we take companies of different sizes into account. CTO of a 10 person startup might translate to Tech Lead in an enterprise software business. CTO at a startup might still get to write code (I know many that do), whereas CTO at a company with a couple hundred developers might not even see code.

If you aren't happy, find somewhere that you can do what you enjoy doing. If this is truly your first senior management position, it might be clear that senior management isn't for you - or this isn't the organization that you should be in a senior management position. You could certainly find Sr Mgt or CTO roles where coding is part of the everyday routine.

</comment><comment><USER20> Key question is WHY did you take up this job in the first place? Do you really believe in the mission of this company or just the CTO title and a lucrative pay attracted you here. If you truly believe in the mission of the company, you're doing the right thing by taking all crap and making progress towards end goals. You are probably not coding because your time is better spent doing what you're doing now. Will you make more difference to the world if you went back to the coding role?

<comment><USER21> I have to agree. In my experience some of the best managers have been the ones who shielded their employees from bullshit, taking the brunt, making sure we can keep moving quickly towards completing the goals.

<comment><USER22> This is one of the main goals of a tech manager: "some of the best managers have been the ones who shielded their employees from bullshit". If a manager of a tech group isn't doing that, they're failing at their job, and likely have some form of attrition problems, quality issues, feeling of uncontrolled chaos, etc.

</comment></comment></comment><comment><USER23> > It seems to be mostly about dealing with everyone's crap, trying to fight > fires and constantly battling with the other managers and tech team to get > things done. I haven't even written a line of code in months.

Welcome to management! You're dealing with the crap so your people can do their job. If you get to code a few weeks a year then you're lucky.

If you really don't enjoy it, go find something else. There are a lot of highly technical jobs that should prove a real challenge.

</comment><comment><USER24> Sounds exactly like the CTOs job. I think too often the folks in SV abuse the CTO title when they really mean senior architect or engineer.

I'll offer advice but it comes from someone with no experience:

Take this opportunity and grow from it. So it's not the job you wanted or expected; you can still find a way to be successful. Really get to know the teams, figure out who has the emotional and intellectual capacity to deliver for you, and reward those folks. Good luck!

<comment><USER25> > I think too often the folks in SV abuse the CTO title

I believe part of it is overall title inflation, which makes it confusing for some people to understand what the actual role is and what you will be doing.

</comment></comment><comment><USER26> I feel ya! So my experience is not exactly the same, but I really get where you're coming from... About a decade ago was the last time that I touched any code as part of my dayjob. I was a web developer for 6 years, and I've been either a project manager or product manager for almost 10 years...and funny enough, for the latter couple of years as a dev. I yearned to move to a position where I sat between the "tech" teams and the "business" teams. I thought this was a natural progression _up_. I was told that I had a knack for explaining complex and technical things in easy-to-digest way for non-techies. So I tried the non-dev route. Fast-forward some time, and I've changed companies a couple of times since then, and without looking almost a decade has passed. My current and last job has led me to the most disappointing moments of my professional career. I won't say _depression_ but feels pretty close to it. In my case i think it feels like nowadays I'm not _building_ anything. The feeling that I used to get as a developer was that I was building something. I totally get that _building something_ means different things between someone who sits at a desk and churns out code vs. people who build essential things such as wells and irrigation systems for some struggling third world country...nevertheless, at the end of my days as a "coder" i still felt like I introduced something into this world; I had such a sense of accomplishment, even if my salary didn't express that. In the last decade, I'm lucky enough to have had something to take my mind off things: in essence, my family. If it wasn't for my wife and daughter to fill my days with joy (and yes the usual family ups-and-downs, but hey, its still a distraction!)...if it wasn't for my family, surely I would have slipped into a deep depression. What makes things tough - _now_ \- is that after almost a decade of not touching code, its that much harder to "go back into codding", at least as a dayjob. Ok, I'm stopping now because this is mere blathering (and i should just post on my own).

...Suffice it to state: YOU ARE NOT ALONE with the remorse you feel with direction of your professional career! The only tiny bit of advice I can provide to you: find a healthy mix of non-work-related distractions in your life AND jump around to different companies. The fact that you have such great experience is something some relevant company will find useful; you simply need to tell them your goals, and hope things align.

Good luck!

</comment><comment><USER27> As CTO of a mid-sized insurance company, I spend less than an hour per week writing code. My job is to lead the architecture and infrastructure teams in meeting company objectives. It is not my job to personally deliver solutions.

CTO is all about leadership. If this doesn't work for you then I suggest your "what next?" is a return to Lead Architect or Lead Developer roles at another company.

</comment><comment><USER28> I took up a job as CTO after being a lead developer and junior partner at a bunch of startups. OMG what a punishment.

I've now resolved to just go out on my own because it's too painful working for anyone else in this curious position of great responsibility but not enough power.

<comment><USER29> Was the money even good?

</comment></comment><comment><USER30> This is one of life's conundrums. Work hard at getting really good at doing something you love doing, and then stop doing it. My advice would be to find someone or some people that are the adjacent jigsaw pieces to you - a set of skills you don't have, maybe it's the stuff that was missing previous times you ran your own businesses – and then start a business with these people where you can carry on doing the thing you love. For me, I had to do it with someone who had all the networking and new business skills that I so painfully lack.

</comment><comment><USER31> It sounds like your biggest annoyance is the fire-fighting. These kinds of fires don't just "happen". They're not forces of nature, they're forces of man. Either directly or indirectly, but always the source of it.

Usually a failure of process, expectations management, or both.

You've mentioned feeling a lack of control. Is that lack of control over the fires being set in the first place or a lack of control over being able to appropriately handle the arsonists? Have you clearly identified the arsonists in your case?

Is the arsonist the CEO; by making insane external sales or Board promises?

Are the arsonists your customers; by making product/pricing/support demands that render the overall value proposition of your company moot; i.e. getting you to focus too many resources on basically charity work to "get their logo"?

Are the arsonists your team members; by having a strained relationship with best-practices, consistency, reliability, velocity, productivity, etc.?

</comment><comment><USER32> I highly recommend following Camille Fournier's blog, she writes/speaks extensively about being a technical leader and CTO. Priceless lecture especially that it comes from someone very experienced.

Check out this post about transitioning to hands-off position [http://www.elidedbranches.com/2016/04/ask-cto-navigating- han...](http://www.elidedbranches.com/2016/04/ask-cto-navigating-hands-on-to- hands.html)

</comment><comment><USER33> There's a story that Woz tells about how he was feeling as though he was being pushed in to management as Apple grew and the anxiety, etc., that caused him. Eventually he realized (and/or someone pointed out) that he didn't have to follow the role changes and could remain in a hands-on engineering role.

I've worked with a few people along the way who were senior enough and wise enough that they easily could have found themselves a management position if that's what they wanted. But they either had tried it and decided it wasn't for them, or they just knew they would be happier coding and maybe doing some mentoring of the junior staff.

tl;dr: Transitioning to management may be the 'normal' career path, but why do it if it makes you unhappy?

</comment><comment><USER34> Somebody has to do these things. They can be done more or less well. This has a big impact on your company's success and on the happiness of your team. Those are the only good reasons to endure the hardships.

You're coming to understand what executives do and how that's necessary in a company, at least until humans find better ways of working together. This isn't something you really see clearly when you're the CEO because you're above the fray. And this isn't something you see when you're an individual contributor if the executive of your group is doing his or her job well.

People are paid in part based on how poorly a job can be done. The CTO is a role where real catastrophes are possible. It's a job the rest of the business often doesn't understand well, managing a team the rest of the business understands even more poorly. It's easy for bad choices to do a lot of damage to a company over a long period.

If you're the rare individual who can bridge both worlds and do this job well, then it's likely your company and your team won't find anyone who can do this better. And if they have to look, it's quite possible they'll find someone who does it a lot worse, makes your team miserable, and drives the company into the ground.

The reason to do the job is to make the company successful and to make the lives of those on your team better. If you believe enough in the company's mission, the other executives, and your team, then you'll figure out the rest.

Humans can endure a lot of hardship if it fits within some context we find worthy. It's not an easy job. But if it's a worthy cause then carry on.

</comment><comment><USER35> As a CTO myself, i see there is a lot of vagueness in the whole role of CTO. Almost all other roles in an organization are well-defined and have clear goals and responsibilities. The role of the CTO varies so widely between each organization, it is something that has to be specified clearly when going through the hiring process or even when starting a startup.

Why does this happen? I have found it has a lot to do with the investors and management team. I've seen the definition of the CTO varies as far as "The CTO should be the technical evangelist, super SEO." all the way to, "The CTO is in charge of Product and delivery."

IMHO giving CTO titles to the "evangelist, super SEO" undermines the role, because that role does not warrant either "Chief" or "Officer" in their title.

\----

As far as myself, i retain the CTO title because am the owner of the technology; in that i make sure that technology is all the things we are trying to achieve as a business; looking beyond the current implementation and plan out how we need to build the product over the coming years. This goes alway down to components required, system architecture, external interfaces and how we can do things better, faster, cheaper. I also write pieces of the code and help out in engineering task as needed. This keeps my competency in day to day ENG high. Involvement with ENG tasks and coding is what keeps my sanity.

If someone asked me if i liked my role as CTO i would say yes but there is all the things you listed (fight fires and battling with managers and tech team).

</comment><comment><USER36> The best translation I ever heard for "CTO" was "Chief Talking Officer" (from someone who had been "promoted" into the position.

Several different jobs can be assigned the title CTO but they are all technical _leadership_ positions, not direct execution. The company should be getting leverage from your position -- you should be enabling the growth of the company, by being th external technical face of the company, by helping direct technical development internally, by representing the technical / architectural issues in the management team, or by defining the technical direction based on the exec team's decisions on company direction. Different companies need different mixes of these. BTW it's often a way to retire a founder without losing their technical input, or to keep them from meddling :-).

In your case you were hired on, so they wanted you to use your technical expertise to help guide the company (or keep the tech from getting into trouble -- but even on the execution side, that's the VP of Engineering's job).

So if it turns out this isn't what you really like doing, there's no harm in that: you should find something you would enjoy more, and help the company find someone else to do the job they need doing.

</comment><comment><USER37> By and large, you are describing people management. It is quite about dealing with crap. I don't mean that as a complaint, merely a fact.

Good managers take crap so others don't have to.

Ideally, we get good enough to prevent the crap from happening in the first place. But it is most certainly the job. It's entirely understandable if you find it's not for you.

</comment><comment><USER38> Maybe its too big a company? "Around a few years" sounds like they have a sizeable staff. So a CTO position there would be very different from a CTO at a new startup. Pretty much like you describe it. A management position, heavy on the 'officer' and lighter on the 'technical'. Managing a team of technologists make you responsible for making the right decision. Too many folks think CTO means you 'get to' make technical decisions. No, you're actually responsible for making sure the right ones get made. Which means listening to your competent team, understanding what they tell you, and reconciling that with the business.

</comment><comment><USER39> A CTO's role should be technical leadership. If a major part of your role is dealing with everyone's crap and putting out fires, I wouldn't necessarily consider that technical leadership.

I've been in a similar situation, and for me, the right solution was having the right people under me that I could trust to fight the fires.

You should be deciding how the fires are fought, but your team should fight them. At least _some_ part of your day should be available for steering your team/organization/product.

(But code, not so much. :)

</comment><comment><USER40> I've been in the same position. Was first to join a couple of founders, built the first few iterations of the application, small group, great fun, lots of challenges, lots of code. As funding came, team grew I became the CTO officially. But then the fun stopped. Technical decisions which were meant to be mine were dropped on me by one of the founders despite my objections (most if not all proved to be mistakes). In the end I stepped down and we invented a new role where I'd be in charge of innovation. That worked well. The CTO who replaced me run away himself after a short while and after that we were CTO- less.

Thing is there are many forms to the CTO role and different people see that role in different eyes. To me the CTO is a technical leadership position. You are meant to decide the technical strategy of the business. Decisions from which servers to use, to what language to how things are done, architecture from the top down, etc. Someone mentioned about the VP of Eng. role which I can't agree more - That role is there to support you with the crap. That person needs to be more manager than tech. He is there to make sure your time is dedicated to the core of your position. Not everybody saw this roles as I did which is why I was happy to stand down than try to fight it. I was there from day 0 to acquisition about 7 years later.

</comment><comment><USER41> I have the opposite problem, which is that I think I would enjoy and be good at a CTO type role, but since I don't have a personal background as a coder, I'm not sure how to move toward it. Almost all the job listings I've seen require a CS degree and a decade+ of experience as a developer. Startups, in particular, seem to believe that CTO = lead coder.

I've managed websites for years, overseeing design and development teams, setting product roadmaps, negotiating contracts, even testing and debugging websites and server configuration. I understand the stack of technologies that make up a website, although I have not written web applications myself. The little bit of code I've written is on the margins: shell scripts, one-off JS widgets, etc.

I'm not bad at managing people, and I enjoy it. I'm not bad at managing peer and executive relationships, and I enjoy it. These are the sorts of things that a lot of developers seem to really dislike about elevating into CTO.

So: is it possible to land a CTO role without being a experienced and expert code-writer? Or am I thinking of the wrong thing?

<comment><USER42> Well, if we believe the Fred Wilson post that someone linked to above [0], what you're looking for is a VP of Engineering position, not a CTO role.

[0] [http://avc.com/2011/10/vp-engineering-vs-cto/](http://avc.com/2011/10/vp- engineering-vs-cto/)

</comment></comment><comment><USER43> In our culture we always strive for a "better" job. Better jobs pay more, and have more societal prestige and status. In our culture we associate better jobs with being managers. The higher up the management chain you are, the better job you have and the more important you are and the more money you get. (and more money is always better too). If you can make it to CEO you can make 1000x the lesser workers who do not have as good a job.

Is that a valid cultural paradigm? Are management jobs always "better"? Should they get paid more because they are so much better and more desirable positions to have?

Sometimes this attitude seems like a remnant of a feudal age where the management positions were held by nobility (our betters). Certainly some of the pay inequalities are now forming the basis for civil unrest.

The craftsmen are the true heart of the companies production and IMO the rest of the team should be focused around supporting the craftsmen rather than the craftsmen focused on supporting the management. (regardless of your product)

I think our culture is a little broken.

</comment><comment><USER44> Find out what you REALLY want. Find your motives. Find the underlying essential motivation. That's much deeper than coding or not handling crap. Those are superficial symptoms, not what makes you move.

Find a good professional coach that can help you with finding this out. Pay money for it. You probably can spend several thousands $$$ on this. Not that it needs to be that expensive, but $1000-$2000 is easily spent.

If you quit this good paying job, while it may actually have the opportunity to bring you to your dream job, it's worth staying there long enough to get your things together.

[http://simainternational.com/coaching/strategic-life- career/](http://simainternational.com/coaching/strategic-life-career/) This is a link to SIMA, about motivational assessment. There are more methods. This is just a starter, but it may be right for you. Be sure to find an experienced coach.

<comment><USER45> I just read something along the same lines on the way to work this morning:

[https://medium.com/code-like-a-girl/why-i-left-management- th...](https://medium.com/code-like-a-girl/why-i-left-management-the- engineering-technical-track-vs-management-track-abef5b1d914d#.g0cswbi5s)

The author was in a similar spot, and chose to go back to the tech track.

Her takeaways were:

What gives you energy and what drains you? How do you feel accomplishment? What drives and excites you?

Answering those three questions honestly will give you a better idea on what kind a role would best fit you.

<comment><USER44> Answering those three questions can be really difficult. You probably have a big blind spot there. A professional coach can take that away.

</comment></comment></comment><comment><USER46> You can also look at the CTO role as slightly different style of hacking; you program with teams, training, and planning in addition to setting technical direction and leadership. Many CTOs design and code as well (I do) as a senior-senior designer or architect, but you should think about the meta- programming as exciting on its own. Many senior level architects love to train and lead teams technically, and a CTO often focuses on these things. Senior level architects also curate the technology and design, which CTOs also often own. It's a great role, though it sounds like you may need to grow into parts of it. I suggest that it's totally worth it.

There are various ways to cast the role too; many organizations also have a VPE (or VPD) and other mid-level leaders. These roles can allow some flex in what a CTO is responsible for, though ultimately the role is responsible for direction in technology.

</comment><comment><USER47> I've been Tech Evangelist, Chief Technologist, and CTO in the past few years, both at large and small companies.

I think it's wrong to generalize - a CTO experience can be good or bad depending on several factors. It is entirely possible that you could be VERY happy in a similar situation, but with a different company.

Usually CTOs can be divided into engineering types, and outward-facing types. The former is hands on, codes, handles the engineering team, or at least has a strong bond/influence with the VP of Engineering. The latter is more in touch with customers, does more public speaking activities, and tries to condense feedback and requests in a way that the VP of Engineering can translate it into the product. Right now I'm the outward-facing type. I am enjoying it, mostly because the two co-founders are great individuals and leaders.

Let me know if you have questions - I would be happy to try to answer.

</comment><comment><USER48> You wanted to be the lead developer and you got CTO. You can be both in a very small startup, but CTO is a management position, not a coder. Maybe you should find a job you'll enjoy more and leave. Or find another CTO to replace you and become lead developer, but that could lead to awkward relationships inside the company.

</comment><comment><USER49> as a CTO you're not just an employee of a company, but also one of its leaders. you have control over what you do. if you don't like the day to day process, change it.

</comment><comment><USER50> As a technical leader, the biggest hurdle I faced personally was understanding how to measure and improve myself in the right ways.

While success in an engineering role can generally be described as "write good code" (with all the nuances therein), technical managers are measured on totally different things, and it isn't obvious how to improve most of them.

When I transitioned and realigned myself to these things, my outlook changed, and I started really enjoying leadership roles:

* Embrace the idea of being hands off technically. I have never seen a hands on technical manager that worked out well - politics will always come into play. Instead, encourage friendly inter-team debate, which you can coach and steer into a healthy dynamic to make the right decisions. Feel satisfaction that the team you build creates better engineering than you could alone.

* Focus on helping your team lead fulfilling careers and lives. See in them what they could become in 10 years and help them achieve it, even if it sometimes conflics with your short term interests.

* Build amazing products - The leader is way more instrumental in this than often credited.

* Create a great team environment that people want to be a part of.

* Get a seat at the business table - you should absolutely be a big part of the product roadmap. Done right, eventually you should have sales/customer teams coming to you for advice and input like 'Customer X wants Y, what do you think?'

* Create great communication flow - make sure everyone else knows how important your team is, and help your team see how what they do contributes, and how the market/product is changing and why.

On your comment about fighting fires and other managers - you can change this. These things make any job unpleasant. I strongly recommend reading The Phoenix Project to get some ideas from an IT perspective - it can easily be read in a weekend and addresses exactly these common problems.

</comment><comment><USER51> I was a manager and a lead technical analyst (basically a CTO with a much narrower scope than a full company). I now refer to the nine years I spent doing this so-called "work" as The Lost Years, because I wrote very, very little code and my skills dried up.

There are some people who enjoy it. But I found it to be exactly as unfulfilling you described it, for much of the same reasons (spent too much time fighting management fires and not enough time solving technical problems), and it ultimately drove me back to being a software developer. Thank goodness my skills hadn't atrophied completely, but I'm definitely behind my cohort in terms of expertise, and I spend too many cycles regretting the lost time I could have spent growing my skills.

</comment><comment><USER52> My advice is to realize that you are hired as a _leader_ in the organization. Use your leadership to change what needs to change so that the company succeeds. An important factor for the success of the company (as long as you are still hired there) is that you are doing what you _love_ doing and what helps the company, because it'll make a big impact. If you like writing code and write 2 lines of code, it'll raise the morale of the team and get them motivated to work more.

What I am trying to say is assume your leadership and do what you want to be done. If the company likes it, then great. It is a win-win situation. If not, then next steps are clear.

</comment><comment><USER53> I have a similar problem... and similar to DelaneyM

In 2007, I got my MBA in Finance, which is the worst time to get one at the beginning of great recession.

Anyways, I taught my self to code in 08-10 and somehow convinced people to pay me to code!

After being unemployed for so long in 2009-2010, I was happy to move down this coding career path cause the money was so easy.

But only in the last year or so I have come to realize (after all the money wore off), I have no desire to be CTO or a coder, I'm having a hard time being a coder, lol.

I'm a entrepreneur, that knows how to code, is my new catch phrase. I have a enough leadership and communication skills I'm just wasting those talents when I'm just a heads down coder.

</comment><comment><USER54> Fighting fire is no reason to be sad of if you are in control. I recently quit because I was fighting too many fires, was underpaid and was not in control of things.

I'm not sure about your pay structure, but if you are a CTO you definitely have power to change things. I think you should do that. If computing is what you love there is no better place than to be a CTO. You may review code, even write some modules and dictate how things should be done. And you should do it so that the system is stable with less fire. If you are not capable of doing so, you should hire someone who is capable of doing just that.

Email me if you want to talk privately.

</comment><comment><USER55> > It seems to be mostly about dealing with everyone's crap, trying to fight > fires and constantly battling with the other managers and tech team to get > things done

Welcome to any senior/management/executive position ever.

<comment><USER9> I partly disagree:

It doesn't _have to_ be that way. That is a sign of shitty management.

But the reality is, there are a lot of shitty managers out there, therefore it is the norm.

</comment></comment><comment><USER56> CTO is a coding role. Also, coding roles are less valuable than CTO roles.

If you like the money, keep the money and do your job well.

If it's not about the money, get a coding role somewhere and know that your goal is to be a great coder, not to work up the company ladder.

Being a coder is great, but realize that different jobs have different work and different values attached to them. Make sure what you want to be and what you do are aligned correctly so that you get what you actually want.

It seems like what you think you want, what you are working towards, and what you are really doing aren't aligned.

</comment><comment><USER57> I work for a company and the CTO submits PRs for two projects, and does some QA testing, and helps guide my team's R&D software. It is a medium sided company. For him it is a chance to lead the future of the company while still writing code and he embraces it fully, albeit he is very busy, but you can tell he gets energized by the way he plays the role. This would not be possible without the right company culture. However as CTO you are probably the best suited person in the company to shift culture toward this, if you wanted.

</comment><comment><USER58> Thought provoking. I read it earlier today, dropping in to add my two cents. I've been toggling between roles that either fits into 'product manager' or 'product developer'. That included a short stint as a startup founder.

IMHO (and experience) an A1 CEO/product/sales/business-guy can't be an A1 CTO/tech lead/research-guy and vice-versa. My operating keyword in this argument is 'A1'. This is counterintuitive to our natural inclinations.

Edit: Typo

</comment><comment><USER59> Well, the issue with coding is that in theory a good CTO makes way more money.

I am dealing with the same problem, though I am not sure what makes me happy exactly. I think sometimes we get into this carrier path thing and just move forward through inertia. Things are good on paper, but in reality you feel like crap.

I don't know, I am slowly trying to move away from my current job. I am planning to use savings to buy websites, the idea kind of excites me, which is a great feeling to have.

</comment><comment><USER60> Maybe this transition comes too soon but moving from coding in to management is a normal progression. It is another job , but in general it values the same qualities you should have as a coder: Understanding the dynamics of the situation and finding the best solution to get the job done. As CTO you should have the flexibility to find other people to help in the things you hate the most and focus on the fun parts.

</comment><comment><USER61> > For my entire career I feel as though I've been working towards being the > CTO and now I'm here I find it's not at all what I expected. It seems to be > mostly about dealing with everyone's crap, trying to fight fires and > constantly battling with the other managers and tech team to get things > done. I haven't even written a line of code in months.

Please tell me you are trolling.

</comment><comment><USER62> I think you're finding exactly what it seems you're finding; the CTO role is not for you (as it isn't for me either.) It is exactly what you're experiencing; dealing with bullshit, trying to get people to do things, get people to find common ground, etc.

If you're not enjoying it you should go back to being a lead developer. You may make less money but you'll be happier.

</comment><comment><USER63> There's not a lot to say other than: find a mentor now.

Start cold-emailing CTOs in the same portfolio as your company. They'll be happy to help.

</comment><comment><USER64> Correct me if I am wrong. But it sounds to me you are still struggling between a coding job and a full time management job. And to be fair, i think this is what you would be expecting for most of management position in lots of the companies.

You mentioned you have done some small management as senior/lead. Then think back, which part do you enjoy when you were there.

</comment><comment><USER65> > trying to fight fires

Your leadership should help people avoid that fire fighting.

> I haven't even written a line of code in months.

That's a good sign for a CTO.

</comment><comment><USER66> I did it for 11 months, and I hated it too, so I quit. Now I'm figuring out something that'll make me happy. :)

</comment><comment><USER67> gdb wrote a brilliant post about his experience that you should definitely read: [https://blog.gregbrockman.com/figuring-out-the-cto-role- at-s...](https://blog.gregbrockman.com/figuring-out-the-cto-role-at-stripe)

</comment><comment><USER68> Maybe seek out a VP Engineering role at a smaller company. To me VP of Eng is usually more hands-on technical vs CTO which is more strategic like applying technology to business and big picture.

Not sure how old you are but a CTO role might make more sense later in life.

<comment><USER69> My experience is that VPE takes on more of the day to day management stuff and CTO takes on figuring out how to apply technology to solve business problems.

OP sounds like they want a VPE to work alongside.

</comment></comment><comment><USER70> I had a similar experience. I'm a great coder with good communication and leadership skills. In 2009 I co-founded a hip startup in the TV space. I had experience as a senior / architect prior to this, but this was my first time as CTO, let alone any management position.

I LOVED the first year. I was solving difficult problems, working productively, coding like crazy, learning a lot about business and startups. But it was just me and a contractor or two.

In the second year we were growing and I started to recruit. I didn't really like finding people, but I loved creating a great culture and productive environment, so it wasn't bad. I found some great people to hire and continued to be the lead dev. I started to experiment with process and getting teams to run themselves.

By year three we had 12 devs, and multiple teams. I was spending a lot of time cleaning up after unwise decisions and trying to implement process to keep us productive. Our apps and team got big. I loved being in flow and coding so much, I would drop the ball on management tasks to finish features I was shipping. I was involved in too many things: product decisions, partner deals, traveling, and our customer development research (we were floundering and making the wrong product at this point).

I hated it. Every time I procrastinated something I got more stressed and depressed. I tried changing my role to lead dev, but it was a mess and I left.

After wandering around and experimenting with different things for years, I think I've figured some things out. I'm contracting with multiple long-term clients. The skills and network I earned doing my startup have been great for finding work. I only take projects where I can have a high level of ownership and creativity (no team to deal with). I have been able to work with fun technology across multiple disciplines (in the last year: React, Haskell, Elm, iOS, Swift, Clojure, among others).

I do mess around with my own ideas sometimes, but I realized that what I really love is to create products, and I don't like management, or selling things I've created. So I'm most effective creating products with/for other people who are taking the business risk.

Not sure if there's anything in there you can use, but good luck! Figure out what you love to do, keep experimenting. I hated being a CTO too. There's no shame in figuring out it's not right for you, but it IS hard to allow yourself to go down in status. For me it was this big ego thing holding me back. Don't make that mistake :)

</comment><comment><USER71> hey. meh, general rule: listen to your gut and follow it. It's that simple ;)

</comment><comment><USER72> How do you advance to leadership roles?

I try to pursue it when it seems like it appears in companies I'm around but it feels mostly like crapshoot.

My other best guess is start my own company, which I think about all the time.

</comment><comment><USER73> >> It seems to be mostly about dealing with everyone's crap, trying to fight fires and constantly battling with the other managers and tech team to get things done.

That's 99% of what management is.

</comment><comment><USER74> Great question and some useful advice. What online forum/community is the best match for this type of question? Maybe it's too niche, but it would be nice have one.

<comment><USER44> LinkedIn, with a fake profile if you want to stay anonymous. Stack Exchange is a good place, but find the right sub. Then Reddit. Enough places to find advice.

</comment></comment><comment><USER75> I've been in those shoes and still feel a bit of that. Would love to chat and share some personal notes if you want to reach out - email@example.com

</comment><comment> FLUX-YOU I would just leave unless there is some major financial incentive in your contract that you don't want to give up (hundreds of thousands or more).

</comment><comment><USER76> Honestly, it's not far off from a typical CTO role. Being CTO is about connecting the technology side of the company with the vision and business goals of the company, and making sure the two match. There are great ways to structure the technology and build out the product that don't contribute to the business goals or even the vision of the startup (and can even be opposed to it), and there are sometimes less-than-ideal ways of building the technology of a company that get it where it needs to be when it needs to be there.

The CTO's job is about half technology and half business when it's a small startup. As the startup grows, you can't possibly make every technology decision, and so your job is more about getting the right people in place who can make the best technology decisions on your behalf as long as you keep them appraised of what the business needs are driving each of their decisions. And because getting those people in place and managing those people is almost all on the business side, your role becomes more about active business management while maintaining an in-depth awareness of the technology so that you can step in and correct course as necessary.

These are all just generalizations of course, as every startup is different. I imagine if you're the CTO of a startup that caters to software developers and code, you probably get to continue devoting some portion of your time to coding. Even in other startups, I've seen a lot of CTO's (myself included) get to actually do some code occasionally, but it's more like once every 1 to 3 months, which sounds about in line with what you're doing.

I think the CTO role you desire does exist, but it's in a specific, somewhat narrow stage for a startup. It sounds like you desire to be a co-founding CTO of a very early-stage (possibly idea-stage) startup. I think your desired traits for the responsibilities of a CTO can also continue to exist years into a startup's operations if the startup remains bootstrapped and self-funded.

From my experience (both with bootstrapped and venture funded startups), when a startup takes venture funding and forms a board, the CTO role becomes more about managing expectations, facilitating understanding of the technology to the depth needed to those who need to understand it to make the proper business decisions, and more importantly, contributing to and making the business decisions that require the knowledge of the technology that only you bring to the leadership and management team. The smae change in responsibilities happens to bootstrapped startups that become big enough, but the change is more organic and occurs over a longer period of time (which actually makes sense when you consider that venture funding is intended to make non-organic growth occur over a faster timeframe).

More cynically, I guess this management of expectations and facilitation of communication could be described as "dealing with everyone's crap," but really, it's probably what the startup needs. If you truly think it's not what the startup needs, then speak up! You are the CTO after all, and that's now part of your job to make sure the company is making progress. But recognize that the business side of a startup is as important (often more important depending on what the startup does, how it's funded, what it's milestones are, etc.) as the technology side, so make sure you understand the importance and motivations of what everyone else is trying to accomplish in the company before dismissing their actions wholesale.

</comment><comment><AUTHOR> Some amazing comments on this thread, thank you everyone. Reading through as fast as I can and will respond soon

</comment><comment><USER77> No, you're not expecting too much.

This sort of thing happens surprisingly often-- the typical solution is to approach the CEO/board and seek a transition: quietly open a search for a new CTO and you find something that matches your passion. It's better for everyone: startups are no place for people without deep passion.

hope this helps!

</comment><comment><USER78> Welcome my friend.

</comment><comment><USER79> >PS. Sorry for the throwaway account but my main account has too much personal info for this topic!

If I was a CEO or founder, I would of course tolerate this kind of thing.

</comment><comment><USER80> you should try meditation ^_^

</comment><comment><USER81> Isn't it crazy, you spend so many years training and building your experience to become great at your job. So much so that you get rewarded with a promotion to management. A position you are given no training for. It is a hard transition and most people have difficulty with it.

First of all, congrats on the promotion.

You need to ask yourself, was coding what made you leap out of bed in the morning or was it that you were building something?

If it was coding then you need to go back to your old role. Please repeat to yourself this is not a failure despite what popular media and the start-up bro culture tells you. If you find a job and role that you love you are beating 90% of the workforce and win at life!

If it was building then you might still be able to make this CTO role work, just in a different way than you are used to.

Forget about technology, you are now a people manager. People are now your tools to build something. Fighting fires and dealing with everyone's crap is usually a sign of some kind of micromanagement. Have you placed yourself in the middle of everyone's decision making process? Are you their road bock for getting stuff done? This is often a result of giving your team tasks to do instead of goals.

Activities describe how people spend their time, whereas goals are the results that they seek.

Give each team member a goal and some kind of structure on how they can make their own decisions to achieve their goal. For example you can tell everyone any decision that takes less then half a day to implement they can decide. Anything that takes more time than that they should discuss with you. Your goal is to set their goal and then get out of their way. You need to run interference between them and distractions from other parts of the company. Check in with them regularly to mentor and coach them to achieve their goal. Can you empower team leads below yourself to do some of the mundane management? When I worked for a performance management company I posted this over on Quora on goal setting. [https://www.quora.com/Whats-the-difference- between-a-goal-an...](https://www.quora.com/Whats-the-difference-between-a- goal-and-a-task) Setting a goal changes the conversation from them coming to you with problems to coming to you with ideas and solutions.

One lesson I learnt when dealing with other managers, departments and up the line is that you have to over communicate. Everyone is mad busy in a start up and they will not remember what you discussed and all agreed last month. You almost need to market yourself, your team, goals and achievements to get their buy in. Run some regular workshops to get further buy in from them.

Your depression may stem from the feeling that you are not doing a good job more than the role itself so keep that in mind.

I have gone through the painful transition myself from doer to manager and I have made all the mistakes :) Design and marketing is my area, not tech. Happy to answer any questions you might have alan at spoiltchild.com

Alan

</comment><comment><USER82> Did you really think being CTO means writing a lot of code? :D

</comment><comment><USER83> I came up with a story that intuitively shows the difference of doing the seemingly exact same thing on different levels when I lived in the SF Bay Area - where I had ants in almost all apartments I lived in during the summer.

The story is about KILLING ANTS.

 _(Note: I lived in mostly peaceful coexistence with "my" ants - they had their roads through my living room and I ignored them, unless they started to crawl around my food. So no need to get upset, no excessive ant-killing took place in the development of this example.)_

\</comment><comment>-----

You kill a few ants in your kitchen. You can do that with your thumb or any object. However you do, it is a physical interaction between you and the ant(s). To kill more you repeat the same physical action. Killing one ant: one thumb press. Killing one hundred: one hundred thumb presses.

So the critical skill and the concrete action you will be doing throughout your ant-killing career is the "thumb press". Or if you use poison your skill is thumb pressing the spray can to distribute the poison.

\</comment><comment>-----

Let's jump a few layers.

You become so good you attract the attention of the California governor. He puts you in charge of ant-killing in California.

\</comment><comment>-----

QUESTION:

Will you do the same thing you did before, only more of it? A billion "thumb presses" instead of a few hundred?

Of course not!

You will never see or even touch a single ant yourself in your new job.

Instead of with ants you now work with a) humans, b) lawyers, c) regulations, d) logistics, e) statistics(!!!). You need to hire thumb-pressers, you need to organize poison - tons of it. You need to distribute the poison. You have to create maps and tell the middle managers where they should send their troops. You need to deal with absentees, internal politics, laws regulating work hours and poisons, people who were poisoned by your ant-killing troops because they misused the poisons. You need to collect numbers: Where were ants seen in the state? How many before the killing, how many after a week, a month, a year? Were the measures effective?

\</comment><comment>-----

Compare the skills you need to control - kill - ants in your apartment or house with the skills you need to kill ants in ALL houses all over the state or country.

It SOUNDS like it is the same task - "kill ants". But human language is deceptive - 100% context dependent. "Scale" changes a problem _completely_.

If your ant-killing employees see any benefit at all in seeing you too kill an ant occasionally it is purely subjective "he's one of us", objectively each hour you yourself spend killing ants means you don't do your actual job of _managing_. It helps when you have _past_ (!) experience - but joining your workers now really means that a) your are not doing your job or b) the problem still is low-scale (small startup - or, in the case of ants, even though you are responsible for ant-killing in the state there only are a handful of houses where there is anything to do).

\</comment><comment>-----

Or another example, moving soil: If you need to move a tiny bit of earth you can use your hands. If it's a little bit you use a shovel - already you will no longer touch the soil directly. If you need to move even _more_ soil you use an excavator - you now are even farther from the actual soil, and you need to know a lot about the _machine_ , organize diesel fuel, spare parts, etc. If you need to move a vast amount of soil you get to the same problem as above, you don't even _see_ the soil any more, you direct an organization, people, logistics, statistics, etc.

<comment><USER84> Nice simple analogy

</comment></comment><comment><USER85> [Not the right community for discussion and you can't delete old hacker news posts so let me nip this in the bud.]

<comment><USER74> If you do nothing but write code all day every day, you're not providing leadership, not managing, and not helping to others to develop their skills.

</comment></comment><comment><USER86> just take a nice vacation for a few months. ill fly in to do your job in exchange for 50% of the salary. after you've made up your you can either come back or not (and ill be a rich mofo muhahaha). the lesson being: if you get such a position and then complain about it being no fun then you are the problem. its an honor to be the boss. it makes a lot of money. if its no fun, well cleaning toilets for $5 an hour is no fun either but people do it anyways.

</comment><comment><USER87> Can you re-architect the product from scratch? This should be doable if the raw building blocks (modules etc.) are properly designed and easily incorporated into a new design. If this is not the case, then all the more reason to rewrite the code!

<comment><USER88> Over the years; I have found very few valid business reasons to re-write a code base that is still supporting the relevant business.

As a CTO, there is a good chance the poster would not be materially involved in such an effort.

From a business perspective; something that works is more important than something that is well architected.

<comment><USER87> Tell that to the Facebook team who recently rewrote their entire front end codebase using React.

<comment><USER84> I wonder, did they really rewrite or refactor. Did they chuck out every single last line of code at once, or transitioned it slowly? Do they no legacy code left at all?

</comment></comment></comment></comment><comment><USER89> From my experience, if the following two conditions are met, you should continue. if not you should quit:

1) Are you ok with not coding and just have a technical vision and dealing with people constantly ?

2) Does the CEO respect technical part of the project ? that means he doesn't think that he can imagine anything and then the CTO will do it with his team.

Let me explain each point:

The first one: as a CTO most of your time is spent on:

\- [Hiring] this part will probably take 20% to 30% of your time. you have to interview them technically and be able to sell your company and motivate them.

\- [Communication] Communicating with the CEO and other key roles: this is everyday, you have to be involved in every decision concerning the product. and you should be able to explain clearly why you are against or for a feature in the product (this one takes maybe 30% to 40% of your time!)

\- [Technical] Macro architectural decisions, code revision, etc.this is paradoxically the easiest part ! it should not take more than 20% of your time.

\- [Management] Making sure that developers are motivated enough, talking to technical team every morning and trying to understand their feelings and vision and deciding if they are in line with the culture of your team. this part should take 20% of your time. if it takes more than that, that means that you didn't do the hiring very well. so you should spend your energy on firing and hiring again.

The second one: Does the CEO understand that technical decisions are vital for the project so he has to include you on any business decision ?

If yes, then it is a good news. but if the CEO is that old school guy who thinks that any idea can be implemented by engineers and the CTO is the responsable for any non respected deadline then just run. quit, don't even try to change his/her mindset cause you cannot. usually it is really easy to figure out that the CEO respects technical part or he just pretends to respect.

Hope that helps :)

PS: Most people (myself included) cannot dive into code and dealing with people at the same time. When I am coding I don't even here what people is telling me. so I cannot be good at management. that's why I think that a CTO should not code at all.</comment>


Ask HN: How do you *really* get a good Software Engineering job? - <AUTHOR>

It seems like anything I do is never good enough. I can know how to code in multiple languages and provide decent coding examples. But, there is always one little thing that I didn't have in order to get the job. It feels like job postings are not very honest at what they are looking for either. An example would be of a 'Frontend Engineer' job posting that I got an email response back from the hiring manager for, and he asked for a link to a fully functioning and non-trivial web app that I had built before. Wtf? I have not built that as of now (even though I am confident I could). And it would not have been in the companies preferred stack anyways. I just want to know one thing: WTF do hiring managers actually want? And why do they almost never seem know themselves? Sorry for the rant but it just seems like this industry is a load of bullshit. <comment><USER2> A lot of job listings are actually for internal candidates, and although the employer is required by law to perform interviews, the external candidate will never get the job over the internal candidate (since the external candidate is a higher risk). What hiring managers actually want is a candidate that has been personally vouched for by developers they trust, and ideally an internship or contract period at a lower pay rate so that they can pull out if the candidate isn't as good as they say they are.

So, make friends with people who have jobs in the industry and convince them that you have the necessary skills.

<comment><USER3> This is honestly not much better than nepotism. What happened to merit?

<comment><USER4> What happened to merit is that "make friends in the industry and convince them you have the skills" is a more reliable means of finding merit than a typical interview process. It also has tremendous blind spots and will exclude many legitimate candidates in an unequal way and that all sucks, but the goal is "find someone reliably competent you can work with." It's really hard to determine either of those without long term interaction.

</comment></comment></comment><comment><USER4> Most important is to keep looking, and not let the search get you down (which is _hard_ , for sure). Remember that looking for work is a full-time job.

My current position I found through a connection, and that doubtless helped, but I've gotten jobs before through responding to university postings and craigslist ads. I've also been turned down at plenty of places that I've found both ways - for any given position, most of the time you won't get it (of course, since there are going to be multiple candidates).

<comment><USER5> >> Remember that looking for work is a full-time job.

+1

Being employed is side effect of that.

</comment></comment><comment><USER6> Hiring managers are looking for proof that you are as good as you say you are. Inexperienced / young programmers often vastly overestimate their own abilities and experienced managers know this. Having hired a couple of gung-ho self proclaimed supermen only to see them not deliver, the hiring manager now wants to see proof.

If you are new in the industry, you don't have people to vouch for you. That's why you get requests to see your actual work, rather than own cherry-picked code examples.

"I could do it easily if I just got the chance" won't fly if you are in a location where there are more developers than jobs. You'll have to make yourself stand out. The easiest way to do that is to build stuff. Doesn't have to be groundbreaking stuff, but it should work and be within your "specialty" language(s).

Then next time someone asks you for a non-trivial example, you can just send them a couple of your projects, rather than a couple of clever code snippets.

</comment><comment><USER7> "there is always one little thing that I didn't have in order to get the job"

I hear you. Many times, it is not even you. Like you said, the hiring manager is probably too hung up on _one specific item_ that they really think will hit the home run. Now, that depends on the situation. If they need an expert in a very specific niche for a 1 month contract, they probably care about that one thing. If they are looking to hire someone fulltime who can grow in the company, being hung up on that one thing is plain stupid.

"WTF do hiring managers actually want? "

I have been interviewed by tons of managers being a consultant. I would say majority of them are not always sure what exactly they want. It can change. For example, I interviewed once for a role which required a very specific vendor system experience in finance. Apparently, that system was so niche and new that they could not find anyone unless they poached from the vendor directly. So the manager decided to look at other "relevant" candidates. The problem: He had no clue what to look for. True story.

So don't get too upset about this. I say move on and keep looking. There are many great hiring mangers out there who not only understand what they want/need, they also know how to interview and find the right person without being too hung up on one thing or other.

</comment><comment><USER8> I feel your pain buddy.

A lot of good advice given so far.

Perhaps I can add another perspective to it.

Relocate to where demand outstrips supply by a big amount. Relocation is tough, but if you pick the right spot, you will get a job by applying some of those networking principles others have mentioned.

Cities/Areas I'd consider (where you will find it easier to get a job and do interesting stuff) in no particular order: Silicon Valley, San Francisco, New York, London, Berlin, [insert city name here], etc.

I can't think of anymore right now, but those are great places to look at (unless you have enterprise-knowledge, in the form of C#, .NET - which changes things).

It's ironic that programmers use technology everyday to eliminate inefficiencies, yet nepotism in hiring is something even programmers face. Based on this, consider your CV dead for a little while and hustle till you find something.

Good luck!

</comment><comment><USER9> Don't assume it's your fault.

Hiring, often times has biases. There could be any number of reasons: either technical or personal. Hiring decisions are often subjective, despite the fact that they try to be somewhat objective. And it's especially hard for people with less than 5 years of experience. Keep trying, you'll get it eventually.

</comment><comment><USER10> One way to get a good software engineer job is to zero-in on firms that look like they are doing interesting work. Don't send them a resume. Instead, approach individuals in a friendly peer-level manner. Start a conversation-- as a fellow coder, I was curious about the work you do.

</comment><comment><USER11> Avoid recruiters like the plague. Go to Meetups in your area. Got my current job through doing that and it's awesome.

In DC, the custom at tech Meetups is to have a 10-minute "who's hiring" litany before the talks start. I'm pretty sure it's that way in most other cities, too. For mid-to-senior level devs lately, I hire pretty much exclusively from the pool of people I see as regular attendees at deep-language meetups. They are spending their free time getting better at their craft: best 1st-line filter ever.

</comment><comment><USER12> [https://medium.com/@mikeleeorg/how-to-find-great-software- de...](https://medium.com/@mikeleeorg/how-to-find-great-software- developers-15355bfb5880)

i guess this would help to some extent

</comment><comment><USER13> In my experience, even having non-trivial apps won't get you anywhere. Networking is the only sure fire way to get a position where I am, and a lot of that comes down to luck in finding the right people at the right time.

</comment><comment><USER14> I would say that besides technical skills, the number one reason I didn't recommend people for hire is because of poor communication or interpersonal skills. In today's environment, these are essential skills and you should practice if you struggle in this area. Nobody wants to work with somebody that is not a team player, no matter how brilliant they are technically.

</comment><comment><USER15> I couldn't find anything so I gave technical tutorials a shot. I found some companies to contract me, but the time involved basically makes the work a less-than-minimum wage 'job'. I know front end development to a degree, but I'm also below the poverty line. I can't answer your question but I can at least validate your perspective first-hand.

</comment><comment><USER16> Position yourself not as a programmer (or glamorous version of that: software engineer), but as a person who can boost residual value of a business. People like these are assets.

"Programmers", "developers" and "software engineers" are essentially liabilities. These are the first to let go when things gets uncertain.

<comment><USER15> This sounds great but there is one caveat. The person that does the hiring probably doesn't care about the business, they usually just care about their job. It's two different things. The exception are start ups where the person doing the hiring might be the founder or closely tied to them.

</comment></comment><comment><USER17> "know how to code in multiple languages and provide decent coding examples" "a fully functioning and non-trivial web app"

If you haven't written a full app in a language, can you really claim proficiency in it?

</comment><comment><USER18> get a open source contrib on your resume - something they will recognize by name, and hopefully quote something cool - "sped up rendering by 99%"

get a good past job that they will recognize the employer name

and you will have an easy time.

<comment><USER19> +1 for this. A caution: don't just "join" a project: you have to _do_ something in the project and be able to point at the actual code contribution you made.</comment></comment>


Y Combinator Moves Across The Street - <AUTHOR> http://www.bizjournals.com/sanjose/blog/real-estate/2012/09/y-combinator-crosses-the-road-moves-hq.html

<comment><AUTHOR> I noticed the article was written in September. Is the move still happening? If so, when?</comment>


The nausea problem is issue a big issue for Virtual Reality products - <AUTHOR> https://www.quora.com/How-big-an-issue-is-the-nausea-problem-for-Virtual-Reality-products/answer/Steve-Baker-9?srid=iAzv&share=f9d7324b <comment> T-A The "holographic" displays used by HoloLens and Magic Leap are supposedly immune from the depth perception problem, and should also be unaffected by the momentum problem, since they let you move around freely while wearing them (as does the Vive, to some extent; I also expect this to be true for future Daydream + Project Tango devices).</comment>


The Weaponization of Diversity - <AUTHOR> https://siliconhillslawyer.com/2020/06/03/the-weaponization-of-diversity/ <comment><USER3> Razor sharp and refreshingly honest. Touches on cultural issues that restrict supply side of a diversified candidate pool in "elite" professions, exploitation of diversity by culturally parasitic groups, and much more.

Blaming racism (an abstract bogeyman that can never be defeated) and focusing on equalizing outcomes (or meeting a diversity quota) is a problem because it sabotages the real efforts necessary to improve things that have very little to do with race: deeply dysfunctional governance, across justice, education, policing, and in policy-making.

It's easier to say "silent whites are complicit" than it is to ask how we can lift everyone up without tearing others down.

<comment><USER4> In US, fed vs local state split -- is also making reforms more difficult, but on the other hand -- it probably prevents monopolization of political opinion + economic will. So over all the separation is good.

I would like, however, federal laws to be updated to protect people from discrimination due to criminal past.

I think a federal law that prevents employers of asking/using criminal past in hiring decisions -- would go a long way of re-integrating previous offenders back into society.

Probably there are specific federal charges that should be hidden -- but majority must not be used for employers, and must not be asked during job application.

I am a sure if such a law would be in effect, a number of people who resource to additional criminal activity, after previous conviction -- would drop at least 10 fold.

These kinds of changes is a must on a road to a more just society.

</comment></comment><comment><USER5> The issue with this essay, while it is clear in it's wording (as written by a lawyer). It's still has it's fundamental flaw. It's argument boils down to this, which the author spells out

> If the world I was living in had deep, systemic discrimination against > latinos, surely I was an easy target. And yet here I am.

So many of these articles are a single person who succeeds and as a result declares racism must not exist. A personal anecdote is always convincing (as many people know), but anytime an actual rigorous statistical study of this comes up it's shows that clear systemic racism exists.

And people love to read anecdotes like this, because it's a very easy way to ease discomfort. The discomfort that shows that deep seated racism exists in the US, and that our country in a number of areas isn't doing a good job of living up to its ideals. But in the end it's an anecdote and data shows it's not the case.

<comment><USER6> > So many of these articles are a single person who succeeds and as a result > declares racism must not exist.

That is not the evidence the author is submitting. His argument rests on the fact that Cuban immigrants outperform Mexican immigrants in many metrics, which thus disproves the racial discrimination hypothesis. He likewise cites the dramatically different performance of Ghanaian immigrants versus African Americans. These statistics are not subjective.

He then draws on his own experience in the Latino community and hypothesizes the disparity of performance in Mexican immigrant communities stems from a parental culture that encourages short term gains at the cost of long term reward.

There is more to the article but I'm going to butcher it by summarizing it. It is well worth reading and thought provoking.

<comment><USER7> What I don't understand about the whole cultural piece is the selection bias. My understanding is that the Cubans that came here had different circumstances, different opportunity and different resources (they came because they were successful).

Otherwise are we just saying that Mexicans are lazy compared to Cubans and that is just culture? Or African Americans aren't as hardworking as Ghanaians and that stereotype is what it is and we should just operate around it?

<comment><USER6> > is that just culture?

Yes, I think that is the author's point. The values and habits of the Cubans who fled Cuba and Ghanaians who left Ghana are ones which lend to successful lives. These values and habits, such as placing importance on higher education and academic achievement, are partly what culture consists of.

The alternative hypothesis, if one rejects the notion of value and habit transfer, is to claim that intelligence is genetically transmitted. That opens a very ugly can of worms and to my (limited) knowledge is unsupported by scientific evidence.

In either case though, I think it is clear that the Cuban and Ghanaian example precludes the possibility of racial discrimination.

It seems to me this has deep implications about effective and ineffective policies to raise the living standards of Mexican immigrants and African Americans. If we fail to address the root cause (poor cultural practices vs racial discrimination), the problem won't get fixed.

</comment></comment></comment></comment><comment><USER8> I appreciate this writing - I too had to chose an expedient career over a shot at billions for exactly the same reasons.

It also gives me guidance as a father on how to help my children succeed just a bit better than I did.

</comment><comment><USER9> I think a lot of the papers and essays that are opposed to Affirmative Action and/or deny the existence of institutional racism seem to share a few characteristics, down to even the the words used (like being _honest_ and _decent_.) Examining the tone of the piece:

> But I'm afraid that a segment of the community [people of color] – either > well-intentioned or not – has chosen to weaponize the issue of diversity in > a way that is not only hostile and disingenuous, but counterproductive to > its own cause.

> Recklessly and indiscriminately warmongering over diversity is the business > world's equivalent of breaking windows and looting.

While some might characterize the piece as a little tone-deaf, they're the same sort of arguments that've been made since the introduction of Affirmative Action. First, a misrepresentation of sociological concepts like "institutional racism," and the conflation those who discuss its effects or potential solutions to "weaponizing" diversity or claiming that it is caused by malicious actors. The author even goes as far as to say:

> There are historical, cultural, and socioeconomic reasons ... that explain > why a disproportionately small number of people in certain ethnic/minority > groups are able to achieve the high levels of performance and economic > success

But the author doesn't seem to even touch on what those are, other than drilling into the issue being "cultural." The "culture" of people of color has long been blamed as the cause of inequality since at least the Civil Rights Movement. Other, rather cryptic references exist for what the _real reason_ for inequality is, right before the author jumps to a different point:

> If we're _honest_ , we'll first acknowledge all of the nuances and > complexities – some of them clearly uncomfortable – about the background > sources of the problem.

I'm not sure what exactly what that's supposed to mean.

I think articles like this gain momentum due to the "Candice Owens" effect, and the defensiveness of all people to perceived claims of racism. It is a fundamental misrepresentation of what diversity advocates actually advocate, in the name of being "honest" or "decent." It's unfortunate that the author doesn't engage with actual strong arguments in favor of diverse workforces, namely the clear, well documented benefits to both businesses and individuals that a diverse workplace provides, rather than this strawman of someone "weaponizing diversity."

<comment><USER10> I rarely hear opponents of affirmative action deny institutional racism as much as its proponents. It's proponents would rather eat their own hat than admit that systemic efforts to favor specific racism groups for employment (for the noble ends of countervailing other forms of systemic discrimination) are in themselves a form of institutional racism. This denialism has run so deep hacks in sociology have gone to the extreme of outright redefining the word racism to allow for the concept of "non-racist" racial biases in hiring. This is what I would characterize as "extreme defensiveness".

I don't actually think proponents of affirmative action are without a point I'm just tired of seeing a group of people in such deep denial of their own systemic racism seeing everybody else as the deniers and acting above it all when they're not even as non-racist as the average moderate.

<comment><USER11> I agree with your point but must take issue with your phrasing. Your conflation of _racial bias_ with _racism_ trivializes racism.

</comment></comment></comment><comment><USER12> The author acknowledges every culture has its own upper strata There are selection mechanisms which can amplify or inhibit the effect of this upper strata - compare Cubans and Mexicans. For black Americans, that selection mechanism is racism. In 1921, whatever the black upper class had achieved in Tulsa Oklahoma was burned to the ground by white supremacists - <USER2> were ruined by racism. Whatever opportunities the black upper class could have made of home ownership were dashed by redlining, the creation of suburbs excluded them from the foundational middle-class wealth building exercise of the 20th century. Policy created the ghettos at large, with economic pressure for exploitative landlords which incentivized short term earnings to pay the rent, including crime. For black Americans, the upper strata have never gotten a fair break by design of policy (until very very recently). Despite this, a lot of black Americans carry the exact same ethos that the author acknowledges - go read Malcolm X. The idea of 'let's lift ourselves up first' is very old in the black community - the reason it doesn't work is because racist policy always puts the boot on it.

The author comes close to describing the problem, but fails at the solution. "Let's do better guys!" doesn't work - even when a man as charismatic as Malcolm X proposes it. Nowadays, the failure of the black family is used to argue against government intervention to assist African Americans. But the man who pioneered the idea that a failure of the black family would lead to chaos, Daniel Moynihan, actually had genuine policy based ideas on how to rebuild the black family after years of racist destruction of it: [https://www.theatlantic.com/magazine/archive/2015/10/the- bla...](https://www.theatlantic.com/magazine/archive/2015/10/the-black-family- in-the-age-of-mass-incarceration/403246/) He would agree 100% with the author and Malcolm X and others who recognize the role of family, but he would put the blame directly at the feet of white supremacy.

I agree that diversification is being weaponized. The author acknowledged he was speaking from his limited perspective, and again just as a Latino. One thing I wish would happen is that we would go back to the language of redress for past injustice, not diversity. That was the original point of affirmative action. Every social justice movement has scope creep. We go from "Here are these African Americans, descendents of enslaved people who have been plundered and abused for centuries - we owe them redress and opportunities" to "Diversity is good". From "Black People" (and their very very specific struggle) to "People of Colour" (and feel-good-ism about diversity). Happens in the LGBTI movement too. It's gone from people with very specific, very innate differences which have made them targets of brutal violence... ... to the LGBTQ+ movement which is about every other teenager feeling quirky for 'experimenting with their sexuality' and 'not using labels' to be 'progressive'. We even replaced the most observably biological group in the acronym (I - intersex; literally born with mixed chromosomes, genitalia and/or hormone levels) to the most ideological/political letter we could (Q - queer; which is literally defined as something subversive and simply 'different' in a very political sense).

At least as far as black people are concerned, systemic racism is the problem - it has killed the black upper strata for centuries. It killed the black family and created the conditions which the author properly describes in his essay. And, like Moynihan said, it needs to be resolved with policy, but instead it's being 'resolved' with policing and mass incarceration, which has exacerbated the problem.

</comment><comment><USER13> That was a fantastic piece. The author takes great pains to point out the nuance and complexity behind successful outcomes that clearly belie the "structural racism" trope, while acknowledging the realities.</comment>


Is Scala the new Ruby? - <AUTHOR> https://medium.com/on-coding/8d53975e7297

<comment><USER2> If you are going for short code then the following scala example:

val arrayTwo = arrayOne.map { item:Int => item + 1 }

Can be written like this:

val arrayTwo = arrayOne.map(_+1)

"the availability of ruby gems is highly superior to the amount of SBT dependencies"

SBT is just a questionable version of Maven and I would bet money the amount of Java/Scala libs available in Maven repositories far exceeds the number of Ruby gems available.

</comment><comment><USER3> Stupid article, stupid comparison.

</comment><comment><USER4> good god i hope not. we don't need that faux rockstar culture in my pretty language.</comment>