
Ask HN: I don't enjoy being a CTO.  Now what? - unhappycto
I recently joined a startup as their CTO and I&#x27;m hating it.  They&#x27;ve been around a few years and have product market fit and now need technical leadership to grow the team and product.<p>It&#x27;s my first senior management position, having been heavily code focused the last 12 years, with some small management as a senior&#x2F;lead.<p>For my entire career I feel as though I&#x27;ve been working towards being the CTO and now I&#x27;m here I find it&#x27;s not at all what I expected.  It seems to be mostly about dealing with everyone&#x27;s crap, trying to fight fires and constantly battling with the other managers and tech team to get things done.  I haven&#x27;t even written a line of code in months.<p>Over the past few years I&#x27;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.<p>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?<p>I&#x27;d love to hear from people with similar experiences!<p>PS. Sorry for the throwaway account but my main account has too much personal info for this topic!
======
DelaneyM
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. :)

~~~
tim333
>there's no real place in the world for a highly technical business leader.

Bill, Larry and Sergei, Musk and Bezos did ok

~~~
DelaneyM
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.

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

~~~
DelaneyM
But he hadn't been a practicing engineer, and never worked in an engineering
or technical capacity at Microsoft.

------
lwhalen
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.

~~~
unhappycto
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.

~~~
nthj
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.

------
sputr
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.

~~~
lanaius
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.

~~~
sokoloff
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

------
nekopa
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.

~~~
nekopa
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 :)

------
unoti
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)

------
sfmelton
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.

~~~
unhappycto
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!

------
karterk
> 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.

~~~
unhappycto
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.

------
bqe
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.

------
koide
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.

~~~
PedroBatista
So.. about that non-eating crap low level job, any open position for me? :)

~~~
koide
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.

~~~
klibertp
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 ;-))

~~~
koide
Sent you an email.

------
tomblomfield
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/)

~~~
TheGuyWhoCodes
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.

------
fecak
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.

------
rajanchandi
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?

~~~
serg_chernata
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.

~~~
taude
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.

------
BetaCygni
> 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.

------
spydum
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!

~~~
elliottcarlson
> 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.

------
mxuribe
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!

------
sswaner
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.

------
ninjaa
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.

~~~
tajen
Was the money even good?

------
drcongo
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.

------
im_down_w_otp
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.?

------
mszyndel
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)

------
goatforce5
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?

------
tc
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.

------
throwawaycto
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).

------
gumby
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.

------
mwsherman
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.

------
JoeAltmaier
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.

------
naberus
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. :)

------
harel
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.

------
snowwrestler
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?

~~~
ScottBurson
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/)

------
rotten
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.

------
arviewer
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.

~~~
gorbachev
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.

~~~
arviewer
Answering those three questions can be really difficult. You probably have a
big blind spot there. A professional coach can take that away.

------
robotpony
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.

------
simonebrunozzi
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.

------
pmontra
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.

------
keredson
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.

------
BCharlie
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.

------
tat45
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.

------
knighthacker
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.

------
chad_strategic
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.

------
zippy786
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.

------
repomies691
> 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.

~~~
nekopa
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.

------
programminggeek
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.

------
ruffrey
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.

------
dj_doh
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

------
kfk
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.

------
filvdg
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.

------
_pmf_
> 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.

------
ebbv
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.

------
toothrot
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.

------
steve371
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.

------
nailer
> 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.

------
rawrmaan
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. :)

------
borski
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)

------
up_and_up
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.

~~~
ffumarola
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.

------
embwbam
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 :)

------
bartq
hey. meh, general rule: listen to your gut and follow it. It's that simple ;)

------
dookahku
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.

------
gadders
>> 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.

------
WhitneyLand
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.

~~~
arviewer
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.

------
dangoldin
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 - dangoldin@gmail.com

------
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).

------
JangoSteve
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.

------
unhappycto
Some amazing comments on this thread, thank you everyone. Reading through as
fast as I can and will respond soon

------
asah
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!

------
knodi
Welcome my friend.

------
yuhong
>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.

------
hathym
you should try meditation ^_^

------
alanorourke
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

------
countryqt30
Did you really think being CTO means writing a lot of code? :D

------
LionessLover
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.)_

\-----------

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.

\-----------

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.

\-----------

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?

\-----------

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).

\-----------

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.

~~~
bbcbasic
Nice simple analogy

------
Kequc
[Not the right community for discussion and you can't delete old hacker news
posts so let me nip this in the bud.]

~~~
WhitneyLand
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.

------
timwaagh
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.

------
amelius
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!

~~~
reboog711
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.

~~~
amelius
Tell that to the Facebook team who recently rewrote their entire front end
codebase using React.

~~~
bbcbasic
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?

------
misaghshakeri
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.

