> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel.
People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on.
I agree with the premise of the article, CTO should be technical, but I don't think that "technical" and "great at coding" are the same. One of the best CTOs I've had came from a product background. He was technical enough to understand the technical discussions and he was able to support his directors in hiring plans, technical decisions etc. but he wouldn't pass any coding test more complex than FizzBuzz. Still, he was great at his job.
Developers spend hundreds of hours practicing leetcode and hackerrank? Are they actually good coders? And that's required to pass an interview? I feel so out of touch. I haven't interviewed very many candidates, just a couple dozen maybe, but I've never heard anyone mentioning leetcode or hackerrank. If they'd admitted they'd admitted they spent that much time on there, I'd be seriously questioning why they didn't spend that time on making their github awesome.
What sort of person do these exercises? Is it fresh college graduates?
My current job, during the interview, didn't ask me to write a single line of code, but instead asked me to walk through (in great detail) how I'd go about building a GPS related feature for an application that they own. The application is well known and the problem space was well defined. This was a real (low priority) problem that they did eventually plan to tackle as a team.
I also at the same time, interviewed with the fastest growing startup in the area, who had way better comp, slightly better benefits, etc. They asked me to do a take home homework assignment that would've taken like 20 hours, so they could see how I work.
I ghosted the second contact, and after another round of interviews, accepted with the first company, and I'm by far happier with my work and the respect given to my input at this job than any previous one I've had. I'm certain that wouldn't have been the case at the latter company.
I truly believe that once you are beyond the junior level, interviews really are a two way street, and you should jump with the utmost caution unless you already dislike where you are.
Leetcode and Hackerrank I think, if they're used anywhere, are very much a Silicon Valley kind of thing. I've certainly never been asked to go near them when interviewing for startup jobs in the UK, and never used them when hiring myself.
They feel very much like the sort of thing you use in an environment where you've got way more qualified candidates than you have open positions, so you're optimising for screening people out. Certainly not a place I've ever been in over here, where the norm is to be desperately looking for even one qualified candidate.
Larger and more well-known companies do leet-code style programming challenges. I recently interviewed for a job in a ride hailing app company and they directly recommended practicing leetcode problems, even sent me examples of leetcode problems to practice solving. My sample is not big (it's 2 companies I iterviewed with recently), but it definitely feels like the industry is converging on this practice of testing leetcode-style problem solving in interviews. Community even built "workout plans" like this: https://www.grind75.com/
I'm 11 years into the profession. Solving leetcode is somewhat different from the problems I solve at work, so I struggled at first and had to practice, and practice a lot. I have yet to find out how useful this is outside of job interviews, but my brain started to forget some topics from CS after doing so much web stuff and it was a good way to remember these and practice problem solving.
Though I much prefer Leetcode to waterboarding (whoops I meant *whiteboarding), but I know more than one 10x developer who has failed at Leetcode/Hackerrank type exercises. Any system will have false negatives, and at least Leetcode is more fair than whiteboarding, but I wager that Leetcode will be gamed if it hasn't been already. Coding is being seen less as an intellectually stimulating career and more as a gold mine to be prospected by career transitioners and those who can't or won't get an education. Enough people will eventually figure out that all they have to do is memorize jargon, brute force their way through enough Leetcode, and fill out hundreds of applications to get a highly paid job. The Leetcode approach simply isn't sustainable for that reason. If we face a recession, you'll see tons more people who can Leetcode but are terrible programmers.
Maybe you should interview and find out why people do this. I have been coding for 10 years professionally, started coding in middle school and high school competitively. I live and breathe tech because I love it. Yet to work at all the nice companies I have to be able to identify an a problem pattern and implement an ‘optimal’ algorithm twice in an hour or it doesn’t matter.
Also what constitutes an awesome GitHub? Because unless you run a project with > 100 stars it’s little more than academic and doesn’t matter.
I have been asked exactly one contrived coding question over the forty years of my career. It happened during an interview with a startup in late 2003.
I was able to answer the question. Many did not, but the process was more about how you handled yourself through the process, how you communicated with the interviewer as you walked through the problem, than it was about reaching the actual solution. I know several people, bright people, that were hired there even though they never solved the puzzle.
After I got the proper solution, I asked the person that administered the quiz "Is this an indication of what kind of code gets written here?" He just started laughing and saying "no, no no". Because I would not take a job at any company that actually wrote code like that.
That interviewer ended up being my first manager, and we had a good work relationship. It was a great few years of my career.
I also hate leetcode as a measure of "coding competence." I don't think they're "worthless" but totally depends on your job. I notice that if I'm rusty at leetcode, it takes about a week to get ramp back up... but we're talking 10x better.
I don't at all believe I magically got 10x better at coding though... just 10x better at recognizing and remembering patterns.
I think the best type of interview for everyone is the "walk me through X" type. You can almost always spot BS in those and if you can't... should you even be interviewing? I would 100% rather have someone that knows how to glue pieces together vs someone that is good at leetcode... don't get me wrong, I'm amazed at how awesome people are at it and I've met people who excel at both... but I feel its just too weighted in interviews.
They didn’t spend time on making their GitHub awesome because the companies they apply to don’t care. GitHub can get you an interview at a big tech company, but you have to go through some Leetcode-type questions to get an offer.
It started with big tech companies, but I’ve also seen smaller or less prestigious companies doing that, too. There’s a whole small industry around the big tech interview preparation.
And it’s not only for fresh grads - a year ago I interviewed with some SV companies for senior positions (including EM) and I had to go through Leetcode interview as well
The director of marketing in my firm has a PhD in Physics. Every technical talk with him is a breeze. He gets data, complexity, the fact that sometimes easy problems are hard and that tech needs proper support. Point being: management skills are not technical skills, but technical skills or affinity sure help. Perhaps smaller firms the CTO should be a good programmer, but in any firm the CTO should be the one standing for tech and building bridges between tech and non-tech.
It has to be a function of company size here. If your company employs 100s of engineers the value-add of any CTO/VPE shifts from hands on technical to a more strategic view. If your company is in that 20-50 engineer range, having a CTO who is deeply and personally vested helps the entire team ship features to those critical first few customers.
You can program beautiful classes but can you actually architect or direct a team? Can you adapt with new information and find actionable solutions to roadblocks for your team and so on? Can you get along with your technical team and command the ship?
I dont care about your skill if nobody gets along with you. You will be the reason top tier talent leaves. A good engineering team is the one where everyone gets along. Everyone has memories of working with toxic people. Imagine if you replaced all those toxic people in former jobs with people you got along with. Would you have left at all? It makes a huge difference.
I think this just demonstrates a fundamental flaw with our interview process more than anything else. We are modeling interviews based on companies with insane hiring demands (FAANG). At our little 20 person company we have removed most of the BS leetcode style questions and have shifted towards a more discussion based interview process.
Effectively we have switched from quantitative to qualitative where the questions are similar to start but because of the fluid nature of conversation, drift further from other candidates.
If you can't code LC medium, then the odds of you being a good programmer are pretty low. That's the conventional wisdom. Everyone is playing safe and adhering to conventional wisdom.
A CTO has so many things under him, which are not coding... There are architecture decision, in the company where I work, also HW, for example. He cannot excel at every technical interview in the company.
Of course has to be technical, hast to have a huge background in development, and been in many of the areas he will oversee... but you cannot ask him to excel at every one.
I think it depends on the size and makeup of the development team. Smaller startups / teams need a CTO with strong coding and especially architecture skills. Larger orgs probably benefit from a CTO that has a strong product background and management skillset.
Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope.
I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year.
I'm terrified.
I'm terrified because I feel like I will let my reports down.
I'm terrified because a lot of the work I'm doing lacks transparency, how do I tell my compatriots about things that may not come to pass, especially deep political things -- and the amount of work necessary to onboard/offboard people, about "strategic partnerships" and why they're taken, or not taken or any of the hundreds of other things which are changing direction 3 times a day each.
I am technical, deeply, passionately technical.
I will not do service to people by being technical, my days are too fragmented, my worries too broad, it's impossible to dig into a small focused problem and give it the treatment it deserves - and even if I could then I'd be dooming one of my colleagues to maintain it forever because I couldn't possibly..
My being technical is good because I know the problems and I know what can make people feel valued; I can give people autonomy and direction and I can understand when help is needed and how to give it.
However, almost nothing in my work is technical, it's all presentations, discussions, breakdowns, timelines, contracts and negotiation.
The most code I write now is to do cost reporting.
My most frequently accessed cloud console pages are the billing sections.
This is not fun at all (and frankly, I didn't think it would be); but I fear what will replace me if I leave.
I've reported directly to good CTOs and really bad ones.
The shitty ones:
- Either never built trust or broke trust.
- Were impulsive and reactionary.
- Didn't rely on the expertise and skills of their reports as much as they told them what to do because they already knew everything. Didn't ask questions. Gave orders.
- Literally used the words, "because I said so".
- Believed that they were the only one doing any real work. Used the words, "easy" to describe work that was assigned to their reports.
- Were very insecure - questions were often received as
challenges to authority.
- Set in place policies which they were the first to violate.
This comment may have been the tipping point into seriously considering quitting. Deep down I already felt it coming on but seeing it laid out like this hit home. The person currently in that leadership position fits every one of these bullet points and somehow remains in that position.
All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale.
Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.
Interestingly this list covers "bad manager skills". Which emphasises the point that bad managers are bad.
Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice.
Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare.
Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes.
Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it.
So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.
The challenge in technical leadership is letting go of the specifics and delegating them and only in very rare specific circumstances issuing orders.
There are a lot of "person who did everything" types who end up in leadership positions who try very hard to continue doing everything of any importance instead of appropriate delegation and leadership instead of control. I've had that problem, it's hard to let go.
In defence of "because I say so", it sometimes necessary. And not a big deal in my book, if the person giving the order is also owning all the outcomes, good and bad.
Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.
Right? I've had this conversation with so many techies-turned-leaders. The way I look at it, managing means I've given up my chance at doing the fun work so I can create a context where other people can get shit done in a way that's effective and rewarding.
That does require being very technical, because you have to have a feel for the work and the issues. But it also requires giving up being very technical, because you just don't have the time or the headspace to get lost in a good problem.
Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays productive and on track. This will 100% require lying or being non-transparent at some point.
>My most frequently accessed cloud console pages are the billing sections.
Lol yep.
Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
I think I was good at the job, though of course I'm biased but even looking back there are very few things I would change. I really did try and will never feel like I was inadequate even though the company eventually did go under due to bad investments the owner made.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
Following this advice is another way of loosing employees, at least I'd leave a company quickly if the CTO started lying about potential problems not being problems.
In the end, depends on the company. Usually the company I've worked in, have valued transparency, so employees can decide themselves if they want to continue working there or not, when there are potential issues.
Not sure who it'll be good for if things are delayed in a project, you might be able to ship a good product but then the executive team is all like "Noooo, what you're hearing is just rumors, everything is fine and all will be good when we release".
> Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on.
Gross. I worked at at company where the CEO and CTO were hiding important things about the company from employees. When we found out, we felt lied to and betrayed, and there was a mass exodus. The company folded less than a year later.
I'm not saying leadership should be telling employees every little tiny thing. (And certainly some things just cannot be talked about in early stages of the deal, like funding rounds and being acquired.) But employees should have a pretty good handle on the health of the company and what's going on at a high level.
If employees get anxiety or start looking for new jobs because the executive team is being truthful, then either a) the company is doomed, and only an asshole executive would lie to keep employees around, or b) the company is just in a difficult spot, but leadership is not doing a good job of communicating the solid, likely-to-succeed plans in place to get things back on track.
I refuse to work for leadership teams who are not transparent. If they don't think they can trust me to act well in the face of difficult information, then I don't see why I should trust them to run the company that's responsible for my paycheck and livelihood.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
I've only been performing roles of director / vp to small/mid size companies so far, so maybe there's some secret CTO sauce I'm still missing.
To me this advice seems toxic and destructive. Vent upwards, yes. Manage expectations, yes. But you're hiring brilliant people who will eventually know when youre lying or concealing info from lack of trust. good luck with loyalty at that point.
> You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors".
Sometimes your employees can tell things aren't going well, and you bald face lying to them like this will make them leave even faster.
This is also a great strategy to fuck people over, where if they believe in the stability of the company right until the day layoffs are announced they might have just bought a house or something else that will make the next few months for them excruciating, if not disastrous.
So please don't take this advice to the extreme imo. I'm not saying you shouldn't be positive, or give every detail. But you should be realistic. Save the rose tint for the investors and just make sure people have what they need to do their best work, within your power.
I see a lot of responses to this comment, especially these lines:
> Transparency is not your job.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
To add my 2 cents I kind of agree. When I first got into management, I didn't realise how many fires they were, or priorities I needed to balance. Initially I thought "there shouldn't be this many fires" but I soon realised that that was my job, to put them out, escalate when required, etc all while making sure the ship is steady and doing it with a smile on my face.
Some examples include:
- News that a sales person has sold a huge project which will save the company, but we can't deliver or build with our current backlog / resources
- One key team member has been taking a lot of doctor's appointments recently - and suspect they might be quitting / job hunting
- There's a very obscure security issue which could be fatal if discovered, but is a huge task which will disrupt a project which is already delayed and over budget
If I ran into any of these when I first started I would have freaked out - and that would have disrupt my team as they couldn't be productive with that anxiety over their heads.
Instead I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Of course if something was too big to handle I'd escalate, or if something blew up I'd take responsibility etc - but I think job #1 in management is to shield the team from distractions and let them do what they're best at doing.
At this point in my career, I think the #1 responsibility for everyone above VP is to maintain everyone's fantasy of a stable paycheck in exchange for stable work.
Once you peek behind the curtain of where your firm's cash comes from and where it goes, you have to live with a deep existential fear that you could mess up a bunch of people's lives... and you don't want others to have to live with that.
> Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
Maybe they simply found out that you kept lying to them?
>You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors".
When you've been lied to enough you stop believing the lies, a leader who can't be relied on to tell the truth unless it's positive might as well not say anything at all or be there in the first place. Having to doubt and read between the lines for each and every message from leadership is a waste of my time and leads directly to me A) no longer caring and B) not trusting my leadership.
This kind of manipulation only works on stupid or inexperienced people.
There is a big difference between putting a hopeful spin and always fighting for the best outcome and straight up saying everything is fine until there's nothing left but ashes.
I would argue the opposite: transparency is one of the biggest part of your job. You're not in a leadership position, and it's your choice: do you want an opaque company where politics drive individual success? Or do you want a transparent company where employees respect their leaders and where the best insight wins?
> This will 100% require lying or being non-transparent at some point.
I've been CTO/equity partner/division director/tech lead/IC/etc... and this is terrible advice. The one thing you need as a leader is trust - your people need to trust you and you need to trust them. Treat people like the adults they are, tell them what's happening to the best of your ability, and people will work their asses off to accomplish the goal.
This is the job for 80% of corporations, the same 80% of corporations ruled by non-technical highly-political spin-based organizations, that dont really grok what they are up to.
Having technical depth in the leadership ranks, having real competency & belief & understanding in what you are doing, is, alas, not common. But wow, what a difference it makes for an org.
I could not even finish reading this comment. As a C-level leader in an organization, communication should be your strong card. It's unacceptable that you don't even know the difference between "you are" and "your".
If as an employee I get an e-mail from a "CTO" consistently getting confused with such elementary, trivial shit, I would fucking resign immediately as that makes it evident that the organization is led by illiterate people and has absolutely no future.
Sounds like you are making the technical to leadership transition extremely quickly. I think you will find that it’s the speed of that transition, rather than the transition itself, that is giving you difficulty.
One thing that has helped me, and may be helpful to you as well, is to look at your new role as an engineering problem. Logistics and process may not feel technical but they 100% are, and if you approach them with the same problem solving mindset and intellectual curiosity as, say, a coding task, you will enjoy them a lot more, and may even find that you become very successful at them.
Thank you for sharing how you feel. It's incredibly brave.
> I fear what will replace me if I leave
I admire the respect and dedication you have toward your reports (I assume the fear comes from what a successor may do to your reports rather than what a successor may do to the company).
However, if it falls on your to protect your reports from the company, then it may be worth considering how well the company's values align with your own. A terrible outcome would be to compromise your integrity for the sake of the company. If you leave, it's still possible to help those currently under you. Whether or not they would still want your help depends on your integrity.
I really like the model Apple are using is C grade only for CEO, Operation and Finance. The others are SVPs. There is no need for a CTO.
The first job of an SVP is to stand up to the CEOs when they are pushing for impossible deadlines.
The second job of the SVP is to stand up to CFO when they want layoffs. Or fight for more resources when they are pushed to the limit.
The third job, arguably the only thing that is technical, is to stop your sub coordinate pushing for what ever that is hyped in the industry to be used within your company.
It may sound easy in a small startup, doing the above three things in a large company is easily a full time job.
The biggest problem I've seen with this in implementation is that rolling the technical part of any organization under operations is usually disastrous, because ops will generally aim to keep their footprint as small as possible, and do the absolute bare minimum to try and retain talent. It's a model that heavily encourages thinking of technology as a cost center, developers (with domain knowledge) as easily swappable or replaceable units, and vendor SaaS as a preferred solution in almost every instance.
Personally I think having a CIO makes a lot of sense, even if you ditch the CTO, CISO, CDO, CAO panel that is generally subordinate to the CIO anyways.
You need to be technical enough to say no to a partnership, acquisition, or technical strategy that is bullshit. Most of the time, the Spidey sense to make that kind of a due dill judgement only comes through having been a technical employee. (Though having been a technical employee by no means guarantees that, either)
You’re leading with fear and anxiety, you’re letting that fear and anxiety trap you. There’s a great deal of value in thoughtfulness, in kindness, in using your passion to lead, but that value is often lost when the motivation for these behaviours is anxiety. A leader is as much what they signal as what they do.
There’s a variety of options available to you, options that can deliver the best outcome for the business, your reports and yourself — many of which can be fantastic outcomes for all.
Ultimately, building a business is a relay and you will at some point have to pass on the baton: if you fear that inevitability, that needs to be an immediate focus. What can you do to ensure that you can pass the baton on with confidence?
Positioning yourself as not “the CTO” but rather “the person establishing the business’ approach to technology” (which is achieved by utilising the CTO role today) can be a very powerful shift in attitude: you’re setting the technology organisation up for the baton to be handed over to the person ready to lead the next stage with confidence.
If I were in your position, I’d be talking with the other leadership in the business and clearly communicating that you don’t want this role indefinitely, I’d put a plan together for the next 12 - 18 months that involves bringing someone in to replace you, someone for you to pass the baton to.
A bad outcome for the business would be you spending the next 12 months silently stewing in your own anxiety and fear and then have a breakdown and disappear without any notice and the business is thrown into chaos.
As a leader, you don’t need to be perfect or a brilliant jack of all trades or a genius or even the smartest in the room, but you do need to operate with confidence though. If you don’t have confidence in something, focus on getting the confidence.
(For what it’s worth, the shift from where you are now to where you need to be is almost exclusively in attitude, it’s not some insurmountable challenge.)
If your org is 10 moving to 50 in a few months then you have a BIG change ahead. The good news is that you are responsible for how your team operates. You've identified problems, and now you get to fix them - not by coding, but through leadership & culture. This isn't to say it's easy, it's a massive challenge, but it is yours to solve and does require technical knowledge and skill.
No first time CTO's had it figured out either - continue to show the courage to ask advice (as you've done here) and figure it out bit by bit. Nobody has made your org before - there's no playbook only prior work.
The flip side is if that is of zero interest, you're likely in the wrong role. No shame, depends what motivates you.
The worst CTO I ever worked for thought he was the expert because he "cut his teeth on assembly" in college. He indirectly micro-managed everyone with a "goal setting" farce. You had to submit very specific goals each quarter. He would then revise all of your goals for you, and give them back. They were a curated list of tasks that you had to accomplish. You would then be graded on those tasks and publicly shamed. He was so proud of his acronym "SPEED" and believed he was a great culture shaper. I've never worked in a more toxic environment, and never in a less productive one. We would have been 10x more productive if we didn't have a CTO at all.
If I can give an advice quite different from the other comments: don't sweat it. You're not becoming responsible for the success of your team or your company, you're just taking a different role. Things would probably work fine without you. Hell, companies can run for months and years without CEOs (one of my previous company did).
What you can do is two fold: be technically involved (this is the topic of this thread) and be a good leader. The latter means a lot of things, but IMO it also means transparency. I'm really sad to see other comments saying that your role is to not be transparent, I totally disagree.
Congratulations for becoming a CTO but also it terrifies me to think that my CTO is terrified of his/her work. Of course as IC I will never know this but I just don’t get it. I feel like CTOs has been in management jobs at some point before becoming part of the Cs. I feel like in your narration you went from IC to CTO directly. I may be wrong.
That's why becoming a CTO shouldn't be treated as promotion or "next level". And there should be the same compensation level for individual contributors.
If you have that much chaos that you’re insulating your team from, it sounds like you need to try to set some barriers. I’m not sure how anyone could be expected to function in the environment you’re describing.
I'm curious about why and how you've become a CTO?
Presumably, you don't have to do it if you don't want to. If that's true, be nice to yourself and remember that on a regular basis :)
What you've described is pretty much the way many CTOs would describe the job. Don't worry. Treat it like any new discipline. Seek out expertise and learn from it. Make notes and crib sheets and read them regularly (they might be about financial management, or about people management, whatever you need).
Find a mentor if you can.
Don't burn out.
Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
Lying is shitty. Really, really shitty. Think about it.
Doubt is normal, but check yourself for imposter syndrome on the reg.
Firstly, I was recommended for the position by the managing director of a large (the largest?) Swedish games company, so I figured it was a once in a lifetime opportunity.
Secondly, I asked my old CTO if it was a good fit for me as I’d been a manager before and I felt I preferred IC, I also have an abrasive way of communicating which worried me greatly, his response was that the abrasive parts of my communication style will melt away because it is bore out of frustration.
Finally; I have worked in meritocratic cultures but only when there was significant external political pressure from the publisher. Theoretically I could replicate that culture but without the political cruft; additionally I would be in a position to set the company up with long-term technological investments and partnerships: which I was trying to do before but managers are usually focused on short term goals.
> Find a mentor if you can.
> Don't burn out.
> Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
> You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
This is good advice and I appreciate it greatly, I will wear these words going forward.
Maybe the question is what is (or should be) the role of the CTO. A lot of what you describe sounds more like Chief Product Officer (or Head of Product) rather than CTO.
That's a bit too extreme, isn't it? The situation simply might change in one way or another.
A skilled replacement might just appear at some point or the parts of the executive level they're fearing the most might leave. I've never seen a company without any changes in management personell over a decade.
I'd say it's important for a CTO to be a CTO. I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones.
IMHO, too many people chase the CTO title but few really want the actual job.
I personally believe it's easier for a technical person to become reasonably competent at process, cost and other management stuff vs a management person to become reasonably competent at technical things. When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes. I definitely believe a CTO should be very strong technically and have a good bullshit detector.
100% agree. Any decent CTO will have tech in their roots, but if you're coding all day, you're missing out on what's truly important about the CTO role - building teams, assigning resources to problems and steering the company in the right technical direction.
> When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes.
So true. CTO being so far upstream, mistakes made here through disconnection between the rubber and the road have compound effects downstream. It's the sort of role where bad decisions have huge, company-ending ramifications.
"I talked to my buddy at [FAANG] and he said microservices are the way to go. His team achieved awesome velocity by switching to microservices. Let's do it guys!".
While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
> I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones
A common pitfall among startups is to give the CTO title to whichever cofounder is leading the development when the team formalizes titles. Some times this person doesn't even have previous engineering manager (EM) experience at all, but as the most technically oriented person of the time they receive the CTO role by default.
Some times these people can grow into the necessary delegation, recruiting, hiring, performance review, people management, communication, and meeting skills necessary to be a CTO. Other times, they cling to what they know (coding) and turn into a micromanaging CTO who won't cede control of the things they want to do (code) while avoiding the things they have to do (managing).
This is one of many reasons why I advocate for avoiding C-level titles as long as possible at a startup. You can always promote someone up to CTO unceremoniously when the company actually needs defined C-level executives and they've been excelling at the role already, but it's much more problematic to ask someone to give up the CTO title and step aside to bring in an experienced CTO when necessary. Nobody likes being demoted, even if it's only a formality because they weren't actually doing the full management role. Any title demotion at startups is likely to lead to conflict and departures.
Some CTOs who have seen their companies going from 10-1000 don't seem to grow up in their role. They don't learn delegation or trusting others with making decisions. They end up becoming a glorified architect instead of an actual leader. Meanwhile since no one takes the lead in setting up processes and keeping an ear to the ground on quality, velocity etc and things go bad quickly.
This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.
Having been a cto for decades I can agree; the things that are part of the job that are not technical, are the parts I find boring and don’t like. I am good at them by now, but I don’t like doing them. They are needed and indeed not many people who can do them actually like them.
> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel.
I've interviewed over 300+ CTOs over the last 8 years. I don't think the author is saying this literally, but i'll bite - no the CTO doesn't need to pass your coding interview. CTOs need two capabilities to excel - technical ones and human resources ones. That's it. No need to get any more specific or broad than that because different levels of companies have different needs.
For example, a CTO of a 2-person dev team is also a developer. A CTO of a 500 person engineering team very likely doesn't know that his core infra team just wrote something in Rust and that's totally fine, but they sure as hell should know that they have a core infra team and that they're productive in advancing their core infra.
That's an awesome amount of interviews. Is there any sort of experience/book/theory you think a CTO should have to excel at the job (besides the technical and hr skills)? One thing I think I'm struggling with is competing for financial resources with the CEO. It's hard to convince the team we are desperately underfunded when on the surface it looks like we're doing fine. I always assumed that since I'm a positive can do person that when I indicate something negative it'll be taken seriously, but that's not how it works unfortunately.
This misunderstands the role of CTO which is to be a single point of responsibility and leadership for all the deliverables in engineering. And a lot of times CTOs are actually CPOs as well meaning they are also the final desk and driving force behind the strategic direction of new development as well.
Middle management overhead is real but this isn’t really an example of it — there is always a CTO and a CPO but not always in name. Sometimes they’re technical and in the trenches, other times at small companies it’s the CEO who’s wearing multiple hats.
Are we talking about the same thing? Most are talking about Leetcode - which is a separate skill from the job and requires months of dedicated practice.
I haven't seen any engineer managers pass the usual litany of tests that ICs get. (1 LC hard or 2 LC mediums in <40 minutes) Usually they get a very simplistic question or are given enough hints to get through it gracefully (something not afforded to ICs).
Is this what passes for management advice these days?
> CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality.
This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time.
I don't see the problem. Part of a CTO's role is to set the tone for planning and direction, including priorities.
The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.
If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more sensible. I've been on multiple teams that organically chose to try an approach like that when faced with growing quality debt. A CTO can globally foster a culture that is applied locally in concrete decisions.
Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake.
The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement.
One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established.
But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
I would fire any CTO (or engineer) that took this kind of absolutist approach. I find this kind of extremism associated with mediocre engineers and engineering leaders who cannot weigh competing priorities without a black and white answer key which doesn't map onto reality.
For sure. The sad truth is that a lot of people rise through the ranks by taking dramatic action, because that gets lots of attention. Confidence is much easier to detect than competence.
I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.
I can't say for sure about those particular cases. I'd have to have a lot more detail. But as I mention elsewhere, one of the best ways to rise through the ranks, especially at companies excited to be unicorns, is to do dramatic things, even if they aren't particularly effective.
~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out.
The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time.
In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.
I've worked at decacorns that used code freezes... Usually they were last minute "oh fuck we took down the whole website 3 days in a row now and this has cost millions of dollars" kinda reactions.
The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages...
I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
I’m a marketing director, not CTO, so take this with a grain of salt. But I believe leaders should be “good enough” in a wide array of disciplines. Certainly the disciplines involved in their department, but also, frankly, every aspect of the business.
Meaning a CTO should also be good (not great) at sales, marketing, cash flow, customer service, user experience design, etc.
Being well rounded means being able to garner the respect of not only the engineers but all stakeholders, from internal people to the customers to the general public, too.
I’m certainly not arguing that a great engineer won’t make a great CTO. It should probably the area they’re strongest in.
But if I had to pick between an amazing engineer who knows nothing about the rest of the business, or a reasonably knowledgeable CTO who is also reasonably knowledgeable on all other fronts, I’d pick the latter every time. No hesitation.
There is a caveat to this, though. Being a generalist means recognizing that on any given topic, someone knows better than we do. So you have to be able to recognize that and defer to expertise, while also completing the picture by thinking about all the variables that lead to a business being successful.
I’ve met plenty of engineers (and designers and copywriters, etc etc) who think everyone else’s roles are easily understood and accomplished. That’s fine if you’re a specialist. But a leader needs to understand the big picture, and no one is an expert in all areas. It’s just not possible, by my estimation.
There's a huge difference between a Dropbox and an Uber here.
Dropbox is a technology company. This is famously a place where deeply technical leaders can achieve competitive advantage. The whole company exists to support the tech, so if the tech fails, bad.
Uber (and most startups really) don't do tech, they use tech to drive sales. Of course the tech is important but it's a solution not a driver. Here I agree that a "well-rounded" tech-average CTO can be advantageous.
Tech strategy is where everything converges. If products literally live or die by it, you better have a crack technologist at the top.
For clarification: Are you suggesting Dropbox’s leaders aren’t well rounded? Or that they are and that they also need to be stellar engineers?
I think you make a great point either way. I’d elaborate on that and say a business leader needs to deeply understand the product they make/sell, so if your core product is tech, I agree and see your point. But I still think they need to be really good at all facets of the business. They still need to understand the market and how to promote and how to close sales. Those skills don’t really develop if the only thing you do is engineering.
Take HubSpot’s CTO Dharmesh for example. Brilliant engineer! But he applies his curiosity to understanding people and markets and solving unsolved problems. He understands the whole business. He also understands his own shortcomings and surrounds himself with people with complementary skills, because he knows full well that engineering alone isn’t enough.
I am a CTO, and have been for 20 years. 20 years ago I was co-founding a company, so that kind of CTO was very different than the CTO I am today. Starting a company meant I was the technical part of the company. Raising money, talking to VCs, customers, hiring, and all of the other usual growth stuff. Of course I developed code, architectures, plans, deployments. I deployed, installed network switching gear, configured BGP peering, and debugged database problems. As the company grew, the role changed.
I'm now CTO of the larger company that acquired me and the role is different in almost every way. The role is to lead a path to technology changes, but much of that is technology coming from the technology staff itself. The most valuable learning happens by listening to my team and the teams around us. There is as much business as there is technology, as much future guessing as there is past evaluation.
Through all of these changes, day 1 to today, the most important skill has been a desire to be technical. I still write code for my own projects, develop my own projects, design microprocessors, hardware, software, sensors, and everything in between. If someone asks me a question, I want to understand how to get to the answer, not just get the answer.
Of course I have to understand the fundamentals of the business, and of business. Of course I have to convince non technical people why we need to do things. None of that is easier done by being non-technical, and much of it is done wrong by being non-technical. Stay frosty.
(Funny side note.. in the beginning, I often said during a 'introduce yourself' part of a meeting "I'm Jeff, the Chief Technical Officer" by mistake. )
^ for context, Jeff S also has a vast array of technical hobbies whether it's restoring early 1980s microcomputers, tearing a subaru WRX down to its smallest discrete pieces and rebuilding the entire drivetrain, or designing his own home solar power system... He's basically a modern polymath of nerd like pursuits.
Jeff is the CTO version of the guy who wants and needs to "Get his hands dirty" in the cutting edge of whatever technical discipline he's engaged in, for the purpose of keeping himself mentally sharp and fully aware of the subject matter at hand. Even if he buys subaru engine parts from a specialist he puts a lot of time/research into thoroughly understanding what he's putting together. He's kind of locally well known in the pacific NW nerd community for these things.
Indeed, having a somewhat unique name allows quick identification. We are probably a bit closer to 700 people now, and in the 20-30 billion transactions/yr, so very data and critical infrastructure heavy... which in itself has been very much a learning experience.
You've been designing microprocessors for 20 years? By yourself, or do you mean that you're contributing to your team's microprocessor design? Were you sending out your own processor designs to MOSIS or CMP or something 20 years ago, or was this more an FPGA thing?
Oh no.. the microprocessor stuff is purely a technical hobby, although it was what I specialized in undergrad EE, and I worked at Intel for 3 years right out of college. I have done FPGA designs, simulated designs in HDLs, and even a few really cool 74X digital logic based designs and implementations... and so many on paper experiments during occasional long boring meetings.
The interesting aspect of doing microprocessor designs is the journey from the ISA concept through the implementation, discovering along the way all of the fantastic mistakes you have made.
It really makes a better software engineer out of me.
Doing deeply technical hobbies has improved my view and skill in so many areas, as well as helped me understand areas that I really suck at... which there are plenty!
Titles are just titles. An executive's role changes dramatically as a company scales. CTOs in a 5-person startup are vastly different than CTO at companies with even 100 people (much less 10k or 100k). Great CTOs are capable leaders and will hire more experienced engineers they can rely on.
> One of the key roles of your company’s engineering leadership is to balance working on new features versus maintaining quality and squashing bugs.
Even at companies with 100 engineers, if the CTO is focused on software bugs, there are larger issues at play (i.e., talent density is too low, poor prioritization by product, etc.).
Aditya[0] seems has experience here, but he's likely addressing the market of early-stage startups where he advises.
Readit News
People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on.
I agree with the premise of the article, CTO should be technical, but I don't think that "technical" and "great at coding" are the same. One of the best CTOs I've had came from a product background. He was technical enough to understand the technical discussions and he was able to support his directors in hiring plans, technical decisions etc. but he wouldn't pass any coding test more complex than FizzBuzz. Still, he was great at his job.
What sort of person do these exercises? Is it fresh college graduates?
I also at the same time, interviewed with the fastest growing startup in the area, who had way better comp, slightly better benefits, etc. They asked me to do a take home homework assignment that would've taken like 20 hours, so they could see how I work.
I ghosted the second contact, and after another round of interviews, accepted with the first company, and I'm by far happier with my work and the respect given to my input at this job than any previous one I've had. I'm certain that wouldn't have been the case at the latter company.
I truly believe that once you are beyond the junior level, interviews really are a two way street, and you should jump with the utmost caution unless you already dislike where you are.
They feel very much like the sort of thing you use in an environment where you've got way more qualified candidates than you have open positions, so you're optimising for screening people out. Certainly not a place I've ever been in over here, where the norm is to be desperately looking for even one qualified candidate.
I'm 11 years into the profession. Solving leetcode is somewhat different from the problems I solve at work, so I struggled at first and had to practice, and practice a lot. I have yet to find out how useful this is outside of job interviews, but my brain started to forget some topics from CS after doing so much web stuff and it was a good way to remember these and practice problem solving.
Also what constitutes an awesome GitHub? Because unless you run a project with > 100 stars it’s little more than academic and doesn’t matter.
I was able to answer the question. Many did not, but the process was more about how you handled yourself through the process, how you communicated with the interviewer as you walked through the problem, than it was about reaching the actual solution. I know several people, bright people, that were hired there even though they never solved the puzzle.
After I got the proper solution, I asked the person that administered the quiz "Is this an indication of what kind of code gets written here?" He just started laughing and saying "no, no no". Because I would not take a job at any company that actually wrote code like that.
That interviewer ended up being my first manager, and we had a good work relationship. It was a great few years of my career.
I don't at all believe I magically got 10x better at coding though... just 10x better at recognizing and remembering patterns.
I think the best type of interview for everyone is the "walk me through X" type. You can almost always spot BS in those and if you can't... should you even be interviewing? I would 100% rather have someone that knows how to glue pieces together vs someone that is good at leetcode... don't get me wrong, I'm amazed at how awesome people are at it and I've met people who excel at both... but I feel its just too weighted in interviews.
It started with big tech companies, but I’ve also seen smaller or less prestigious companies doing that, too. There’s a whole small industry around the big tech interview preparation.
And it’s not only for fresh grads - a year ago I interviewed with some SV companies for senior positions (including EM) and I had to go through Leetcode interview as well
I dont care about your skill if nobody gets along with you. You will be the reason top tier talent leaves. A good engineering team is the one where everyone gets along. Everyone has memories of working with toxic people. Imagine if you replaced all those toxic people in former jobs with people you got along with. Would you have left at all? It makes a huge difference.
Effectively we have switched from quantitative to qualitative where the questions are similar to start but because of the fluid nature of conversation, drift further from other candidates.
amount of data to be stored. Amount of traffic / users. Amount of servers and services you need. Architecture, scalability, infra, etc etc.
Where is 99% of the cases a small group of people would suffice, no micro services, and in terms of infra, a cheap VPS is more than capable enough.
People just don’t have a clue, bc they don’t understand what actual work needs to be done.
Of course has to be technical, hast to have a huge background in development, and been in many of the areas he will oversee... but you cannot ask him to excel at every one.
Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope.
I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year.
I'm terrified.
I'm terrified because I feel like I will let my reports down.
I'm terrified because a lot of the work I'm doing lacks transparency, how do I tell my compatriots about things that may not come to pass, especially deep political things -- and the amount of work necessary to onboard/offboard people, about "strategic partnerships" and why they're taken, or not taken or any of the hundreds of other things which are changing direction 3 times a day each.
I am technical, deeply, passionately technical.
I will not do service to people by being technical, my days are too fragmented, my worries too broad, it's impossible to dig into a small focused problem and give it the treatment it deserves - and even if I could then I'd be dooming one of my colleagues to maintain it forever because I couldn't possibly..
My being technical is good because I know the problems and I know what can make people feel valued; I can give people autonomy and direction and I can understand when help is needed and how to give it.
However, almost nothing in my work is technical, it's all presentations, discussions, breakdowns, timelines, contracts and negotiation.
The most code I write now is to do cost reporting.
My most frequently accessed cloud console pages are the billing sections.
This is not fun at all (and frankly, I didn't think it would be); but I fear what will replace me if I leave.
The shitty ones:
- Either never built trust or broke trust.
- Were impulsive and reactionary.
- Didn't rely on the expertise and skills of their reports as much as they told them what to do because they already knew everything. Didn't ask questions. Gave orders.
- Literally used the words, "because I said so".
- Believed that they were the only one doing any real work. Used the words, "easy" to describe work that was assigned to their reports.
- Were very insecure - questions were often received as challenges to authority.
- Set in place policies which they were the first to violate.
- Their actions and their words disagreed.
- Lost their best people within a year.
All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale.
Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.
Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice.
Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare.
Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes.
Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it.
So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.
There are a lot of "person who did everything" types who end up in leadership positions who try very hard to continue doing everything of any importance instead of appropriate delegation and leadership instead of control. I've had that problem, it's hard to let go.
Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.
Raw dominance is the dynamic governing primitive social animals.
Chimps are a bit smarter, and would collaborate as a group to beat up alphas that they hate.
A coach that never played can't teach.
Deleted Comment
Right? I've had this conversation with so many techies-turned-leaders. The way I look at it, managing means I've given up my chance at doing the fun work so I can create a context where other people can get shit done in a way that's effective and rewarding.
That does require being very technical, because you have to have a feel for the work and the issues. But it also requires giving up being very technical, because you just don't have the time or the headspace to get lost in a good problem.
It's a conundrum, and it's why Charity Majors' "Engineer/Manager Pendulum" resonates for me: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays productive and on track. This will 100% require lying or being non-transparent at some point.
>My most frequently accessed cloud console pages are the billing sections.
Lol yep.
Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
I think I was good at the job, though of course I'm biased but even looking back there are very few things I would change. I really did try and will never feel like I was inadequate even though the company eventually did go under due to bad investments the owner made.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
Following this advice is another way of loosing employees, at least I'd leave a company quickly if the CTO started lying about potential problems not being problems.
In the end, depends on the company. Usually the company I've worked in, have valued transparency, so employees can decide themselves if they want to continue working there or not, when there are potential issues.
Not sure who it'll be good for if things are delayed in a project, you might be able to ship a good product but then the executive team is all like "Noooo, what you're hearing is just rumors, everything is fine and all will be good when we release".
Gross. I worked at at company where the CEO and CTO were hiding important things about the company from employees. When we found out, we felt lied to and betrayed, and there was a mass exodus. The company folded less than a year later.
I'm not saying leadership should be telling employees every little tiny thing. (And certainly some things just cannot be talked about in early stages of the deal, like funding rounds and being acquired.) But employees should have a pretty good handle on the health of the company and what's going on at a high level.
If employees get anxiety or start looking for new jobs because the executive team is being truthful, then either a) the company is doomed, and only an asshole executive would lie to keep employees around, or b) the company is just in a difficult spot, but leadership is not doing a good job of communicating the solid, likely-to-succeed plans in place to get things back on track.
I refuse to work for leadership teams who are not transparent. If they don't think they can trust me to act well in the face of difficult information, then I don't see why I should trust them to run the company that's responsible for my paycheck and livelihood.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
I've only been performing roles of director / vp to small/mid size companies so far, so maybe there's some secret CTO sauce I'm still missing.
To me this advice seems toxic and destructive. Vent upwards, yes. Manage expectations, yes. But you're hiring brilliant people who will eventually know when youre lying or concealing info from lack of trust. good luck with loyalty at that point.
Sometimes your employees can tell things aren't going well, and you bald face lying to them like this will make them leave even faster.
This is also a great strategy to fuck people over, where if they believe in the stability of the company right until the day layoffs are announced they might have just bought a house or something else that will make the next few months for them excruciating, if not disastrous.
So please don't take this advice to the extreme imo. I'm not saying you shouldn't be positive, or give every detail. But you should be realistic. Save the rose tint for the investors and just make sure people have what they need to do their best work, within your power.
> Transparency is not your job.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
To add my 2 cents I kind of agree. When I first got into management, I didn't realise how many fires they were, or priorities I needed to balance. Initially I thought "there shouldn't be this many fires" but I soon realised that that was my job, to put them out, escalate when required, etc all while making sure the ship is steady and doing it with a smile on my face.
Some examples include:
- News that a sales person has sold a huge project which will save the company, but we can't deliver or build with our current backlog / resources
- One key team member has been taking a lot of doctor's appointments recently - and suspect they might be quitting / job hunting
- There's a very obscure security issue which could be fatal if discovered, but is a huge task which will disrupt a project which is already delayed and over budget
If I ran into any of these when I first started I would have freaked out - and that would have disrupt my team as they couldn't be productive with that anxiety over their heads.
Instead I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Of course if something was too big to handle I'd escalate, or if something blew up I'd take responsibility etc - but I think job #1 in management is to shield the team from distractions and let them do what they're best at doing.
Once you peek behind the curtain of where your firm's cash comes from and where it goes, you have to live with a deep existential fear that you could mess up a bunch of people's lives... and you don't want others to have to live with that.
Maybe they simply found out that you kept lying to them?
When you've been lied to enough you stop believing the lies, a leader who can't be relied on to tell the truth unless it's positive might as well not say anything at all or be there in the first place. Having to doubt and read between the lines for each and every message from leadership is a waste of my time and leads directly to me A) no longer caring and B) not trusting my leadership.
This kind of manipulation only works on stupid or inexperienced people.
There is a big difference between putting a hopeful spin and always fighting for the best outcome and straight up saying everything is fine until there's nothing left but ashes.
I would argue the opposite: transparency is one of the biggest part of your job. You're not in a leadership position, and it's your choice: do you want an opaque company where politics drive individual success? Or do you want a transparent company where employees respect their leaders and where the best insight wins?
Are you ok with employees and reports reciprocating by lying to you as well.
Deleted Comment
I've been CTO/equity partner/division director/tech lead/IC/etc... and this is terrible advice. The one thing you need as a leader is trust - your people need to trust you and you need to trust them. Treat people like the adults they are, tell them what's happening to the best of your ability, and people will work their asses off to accomplish the goal.
Having technical depth in the leadership ranks, having real competency & belief & understanding in what you are doing, is, alas, not common. But wow, what a difference it makes for an org.
Totally destroyed morale, made the best people leave, and created a toxic work environment where there was no trust in management at all.
If that’s your goal, good work I guess.
I could not even finish reading this comment. As a C-level leader in an organization, communication should be your strong card. It's unacceptable that you don't even know the difference between "you are" and "your".
If as an employee I get an e-mail from a "CTO" consistently getting confused with such elementary, trivial shit, I would fucking resign immediately as that makes it evident that the organization is led by illiterate people and has absolutely no future.
One thing that has helped me, and may be helpful to you as well, is to look at your new role as an engineering problem. Logistics and process may not feel technical but they 100% are, and if you approach them with the same problem solving mindset and intellectual curiosity as, say, a coding task, you will enjoy them a lot more, and may even find that you become very successful at them.
> I fear what will replace me if I leave
I admire the respect and dedication you have toward your reports (I assume the fear comes from what a successor may do to your reports rather than what a successor may do to the company).
However, if it falls on your to protect your reports from the company, then it may be worth considering how well the company's values align with your own. A terrible outcome would be to compromise your integrity for the sake of the company. If you leave, it's still possible to help those currently under you. Whether or not they would still want your help depends on your integrity.
The first job of an SVP is to stand up to the CEOs when they are pushing for impossible deadlines.
The second job of the SVP is to stand up to CFO when they want layoffs. Or fight for more resources when they are pushed to the limit.
The third job, arguably the only thing that is technical, is to stop your sub coordinate pushing for what ever that is hyped in the industry to be used within your company.
It may sound easy in a small startup, doing the above three things in a large company is easily a full time job.
Personally I think having a CIO makes a lot of sense, even if you ditch the CTO, CISO, CDO, CAO panel that is generally subordinate to the CIO anyways.
There’s a variety of options available to you, options that can deliver the best outcome for the business, your reports and yourself — many of which can be fantastic outcomes for all.
Ultimately, building a business is a relay and you will at some point have to pass on the baton: if you fear that inevitability, that needs to be an immediate focus. What can you do to ensure that you can pass the baton on with confidence?
Positioning yourself as not “the CTO” but rather “the person establishing the business’ approach to technology” (which is achieved by utilising the CTO role today) can be a very powerful shift in attitude: you’re setting the technology organisation up for the baton to be handed over to the person ready to lead the next stage with confidence.
If I were in your position, I’d be talking with the other leadership in the business and clearly communicating that you don’t want this role indefinitely, I’d put a plan together for the next 12 - 18 months that involves bringing someone in to replace you, someone for you to pass the baton to.
A bad outcome for the business would be you spending the next 12 months silently stewing in your own anxiety and fear and then have a breakdown and disappear without any notice and the business is thrown into chaos.
As a leader, you don’t need to be perfect or a brilliant jack of all trades or a genius or even the smartest in the room, but you do need to operate with confidence though. If you don’t have confidence in something, focus on getting the confidence.
(For what it’s worth, the shift from where you are now to where you need to be is almost exclusively in attitude, it’s not some insurmountable challenge.)
No first time CTO's had it figured out either - continue to show the courage to ask advice (as you've done here) and figure it out bit by bit. Nobody has made your org before - there's no playbook only prior work.
The flip side is if that is of zero interest, you're likely in the wrong role. No shame, depends what motivates you.
What you can do is two fold: be technically involved (this is the topic of this thread) and be a good leader. The latter means a lot of things, but IMO it also means transparency. I'm really sad to see other comments saying that your role is to not be transparent, I totally disagree.
*I have never worked in games.
Presumably, you don't have to do it if you don't want to. If that's true, be nice to yourself and remember that on a regular basis :)
What you've described is pretty much the way many CTOs would describe the job. Don't worry. Treat it like any new discipline. Seek out expertise and learn from it. Make notes and crib sheets and read them regularly (they might be about financial management, or about people management, whatever you need).
Find a mentor if you can.
Don't burn out.
Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
Lying is shitty. Really, really shitty. Think about it.
Doubt is normal, but check yourself for imposter syndrome on the reg.
Ask yourself: what do you want?
If you don't like who you're becoming, move on.
Good luck :)
The reason I became a CTO is three-fold:
Firstly, I was recommended for the position by the managing director of a large (the largest?) Swedish games company, so I figured it was a once in a lifetime opportunity.
Secondly, I asked my old CTO if it was a good fit for me as I’d been a manager before and I felt I preferred IC, I also have an abrasive way of communicating which worried me greatly, his response was that the abrasive parts of my communication style will melt away because it is bore out of frustration.
Finally; I have worked in meritocratic cultures but only when there was significant external political pressure from the publisher. Theoretically I could replicate that culture but without the political cruft; additionally I would be in a position to set the company up with long-term technological investments and partnerships: which I was trying to do before but managers are usually focused on short term goals.
> Find a mentor if you can.
> Don't burn out.
> Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
> You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
This is good advice and I appreciate it greatly, I will wear these words going forward.
Thank you. :)
So you'll never retire or die?
A skilled replacement might just appear at some point or the parts of the executive level they're fearing the most might leave. I've never seen a company without any changes in management personell over a decade.
IMHO, too many people chase the CTO title but few really want the actual job.
So true. CTO being so far upstream, mistakes made here through disconnection between the rubber and the road have compound effects downstream. It's the sort of role where bad decisions have huge, company-ending ramifications.
"I talked to my buddy at [FAANG] and he said microservices are the way to go. His team achieved awesome velocity by switching to microservices. Let's do it guys!".
While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
A common pitfall among startups is to give the CTO title to whichever cofounder is leading the development when the team formalizes titles. Some times this person doesn't even have previous engineering manager (EM) experience at all, but as the most technically oriented person of the time they receive the CTO role by default.
Some times these people can grow into the necessary delegation, recruiting, hiring, performance review, people management, communication, and meeting skills necessary to be a CTO. Other times, they cling to what they know (coding) and turn into a micromanaging CTO who won't cede control of the things they want to do (code) while avoiding the things they have to do (managing).
This is one of many reasons why I advocate for avoiding C-level titles as long as possible at a startup. You can always promote someone up to CTO unceremoniously when the company actually needs defined C-level executives and they've been excelling at the role already, but it's much more problematic to ask someone to give up the CTO title and step aside to bring in an experienced CTO when necessary. Nobody likes being demoted, even if it's only a formality because they weren't actually doing the full management role. Any title demotion at startups is likely to lead to conflict and departures.
This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.
I've interviewed over 300+ CTOs over the last 8 years. I don't think the author is saying this literally, but i'll bite - no the CTO doesn't need to pass your coding interview. CTOs need two capabilities to excel - technical ones and human resources ones. That's it. No need to get any more specific or broad than that because different levels of companies have different needs.
For example, a CTO of a 2-person dev team is also a developer. A CTO of a 500 person engineering team very likely doesn't know that his core infra team just wrote something in Rust and that's totally fine, but they sure as hell should know that they have a core infra team and that they're productive in advancing their core infra.
Welcome to being a CTO :) I don't think a single one I interviewed ever said "nope I don't need more funds for devs, tools, <foo>"
> Is there any sort of experience/book/theory you think a CTO should have to excel at the job
Executive coaches are wonderful tools to help guide you through the soft skills required to navigate the noted frustrations you might have.
Deleted Comment
Middle management overhead is real but this isn’t really an example of it — there is always a CTO and a CPO but not always in name. Sometimes they’re technical and in the trenches, other times at small companies it’s the CEO who’s wearing multiple hats.
I haven't seen any engineer managers pass the usual litany of tests that ICs get. (1 LC hard or 2 LC mediums in <40 minutes) Usually they get a very simplistic question or are given enough hints to get through it gracefully (something not afforded to ICs).
Sorry but that is something he should know. That directly affects technology radar and roadmap, HR and a bunch of other stuff.
> CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality.
This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time.
A real head-shaker for me.
The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.
The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement.
One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established.
But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out.
The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time.
In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.
The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages...
I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
Meaning a CTO should also be good (not great) at sales, marketing, cash flow, customer service, user experience design, etc.
Being well rounded means being able to garner the respect of not only the engineers but all stakeholders, from internal people to the customers to the general public, too.
I’m certainly not arguing that a great engineer won’t make a great CTO. It should probably the area they’re strongest in.
But if I had to pick between an amazing engineer who knows nothing about the rest of the business, or a reasonably knowledgeable CTO who is also reasonably knowledgeable on all other fronts, I’d pick the latter every time. No hesitation.
There is a caveat to this, though. Being a generalist means recognizing that on any given topic, someone knows better than we do. So you have to be able to recognize that and defer to expertise, while also completing the picture by thinking about all the variables that lead to a business being successful.
I’ve met plenty of engineers (and designers and copywriters, etc etc) who think everyone else’s roles are easily understood and accomplished. That’s fine if you’re a specialist. But a leader needs to understand the big picture, and no one is an expert in all areas. It’s just not possible, by my estimation.
Dropbox is a technology company. This is famously a place where deeply technical leaders can achieve competitive advantage. The whole company exists to support the tech, so if the tech fails, bad.
Uber (and most startups really) don't do tech, they use tech to drive sales. Of course the tech is important but it's a solution not a driver. Here I agree that a "well-rounded" tech-average CTO can be advantageous.
Tech strategy is where everything converges. If products literally live or die by it, you better have a crack technologist at the top.
I think you make a great point either way. I’d elaborate on that and say a business leader needs to deeply understand the product they make/sell, so if your core product is tech, I agree and see your point. But I still think they need to be really good at all facets of the business. They still need to understand the market and how to promote and how to close sales. Those skills don’t really develop if the only thing you do is engineering.
Take HubSpot’s CTO Dharmesh for example. Brilliant engineer! But he applies his curiosity to understanding people and markets and solving unsolved problems. He understands the whole business. He also understands his own shortcomings and surrounds himself with people with complementary skills, because he knows full well that engineering alone isn’t enough.
I'm now CTO of the larger company that acquired me and the role is different in almost every way. The role is to lead a path to technology changes, but much of that is technology coming from the technology staff itself. The most valuable learning happens by listening to my team and the teams around us. There is as much business as there is technology, as much future guessing as there is past evaluation.
Through all of these changes, day 1 to today, the most important skill has been a desire to be technical. I still write code for my own projects, develop my own projects, design microprocessors, hardware, software, sensors, and everything in between. If someone asks me a question, I want to understand how to get to the answer, not just get the answer.
Of course I have to understand the fundamentals of the business, and of business. Of course I have to convince non technical people why we need to do things. None of that is easier done by being non-technical, and much of it is done wrong by being non-technical. Stay frosty.
(Funny side note.. in the beginning, I often said during a 'introduce yourself' part of a meeting "I'm Jeff, the Chief Technical Officer" by mistake. )
https://www.crunchbase.com/organization/surescripts
Jeff is the CTO version of the guy who wants and needs to "Get his hands dirty" in the cutting edge of whatever technical discipline he's engaged in, for the purpose of keeping himself mentally sharp and fully aware of the subject matter at hand. Even if he buys subaru engine parts from a specialist he puts a lot of time/research into thoroughly understanding what he's putting together. He's kind of locally well known in the pacific NW nerd community for these things.
The interesting aspect of doing microprocessor designs is the journey from the ISA concept through the implementation, discovering along the way all of the fantastic mistakes you have made.
It really makes a better software engineer out of me.
Doing deeply technical hobbies has improved my view and skill in so many areas, as well as helped me understand areas that I really suck at... which there are plenty!
Deleted Comment
> One of the key roles of your company’s engineering leadership is to balance working on new features versus maintaining quality and squashing bugs.
Even at companies with 100 engineers, if the CTO is focused on software bugs, there are larger issues at play (i.e., talent density is too low, poor prioritization by product, etc.).
Aditya[0] seems has experience here, but he's likely addressing the market of early-stage startups where he advises.
[0] https://www.linkedin.com/in/adityaagarwal3/