Ask HN: I don't enjoy being a CTO. Now what?
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!
227 comments
[ 2.7 ms ] story [ 105 ms ] threadhttp://www.joelonsoftware.com/articles/fog0000000069.html
It can give OP a better feel for how the code is designed, and give them more opportunity to change things in a more structured way in the long term by repeating the process (rather than just fighting fires every time).
Ten year old battle tested spaghetti is more valuable than any benefits a complete re-write would provide.
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.
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.
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.
> 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.
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!
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.
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.
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.
(Mostly just testing if it's really that easy ;-))
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.
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.
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. :)
You mentioned you have done some small management as senior/lead. Then think back, which part do you enjoy when you were there.
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.
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.
...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!
http://avc.com/2011/10/vp-engineering-vs-cto/
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.
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.
Please tell me you are trolling.
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.
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.
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.
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.