A CTO should be technical | Hacker News Reader

A CTO should be technical

blog.southparkcommons.com

600 pointscatapultis354 comments

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

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.

I think it may be a policy for some larger firms, even if there is little available talent in the local market. Here in Sydney there are next to no C++ experienced developers (I am hiring), yet some firms insist agencies make candidates do leetcode tests even before someone actually from the firm will even talk to them.

If they're gonna make you do Leetcode anyway, I actually would want to do it as early as possible. An initial phone screening would be good, but as much as I don't like Leetcode, it's less exhausting than multiple rounds of interviews before getting a challenge that you mess up on. Fail fast, fail early, as they say.

It should be prominently listed in the req as a hard requirement: "Must complete leetcode, no exceptions." Then we all know what's what. It's up to management to make decisions about how hard it wants to make recruiting for itself.

thats the norm for faang. fresh college graduate but any kind of IC will be expected to know how to do white boarding LC hard.

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.

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.

System design problems are much better and more realistic than leetcode style IMO. Let's be real, most developers don't need to have leetcode T9 solutions memorized because it with either never come up, or they can do some research when it does.

Knowing more about an entire system and architecting it requires a lot of variety of experience and it's just a more fun interview for everyone involved.

When I interview people, I also hope I'm assigned to conduct our architecture one because it really makes you learn a lot about an engineer.

Could someone post a good answer (outline) about how you would build out a GPS related feature for an application?

1. Agree on terms and accept your consulting offer 2. Listen to / read up on your requirements for what you're trying to accomplish 3. Build out gps related system according to requirements and future plans

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.

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.

Over a decade of experience shouldn't have to prove competence via leetcode, honestly. I fully believe it helps you become a better programmer... but its over-hyped. Shouldn't expect interviewing/preparing to interview to be a part-time job. Too busy in the day to day for that...

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.

One to three passion projects, doesn't matter what amount of stars. Some practice projects in new technologies. Some contributions to large open source projects. If you tick all three boxes there, in my opinion your GitHub account is awesome. Instead of me having to come up with questions to gauge your competence, we'll instead be talking about what's on your github, making you more at ease, and giving me a better sense of your real world interests and competences. It's a win for both of us.

At my current company I'll probably pay less than half as what you'd make at a "nice" company though, so maybe you won't interview with me anyway.

I've got multiple >1000 star projects on GitHub, and I feel like it hardly matters at all. I'm still being asked to do lots of trivial coding exercises during the interviews. A large percentage of code I've ever written is out there in the open, but somehow it's still not enough to verify that I'm able to reverse a string.

Thankfully, where I live, most companies don't really ask for hard-core algorithm questions - if they did, I would never get a job, as I really suck at these.

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

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.

Thanks, that's it exactly. I wonder if leetcode programmers are actually faster or something, surely someone at these faang companies has some sort of metrics backing up their use of those tests? Or is it just a slightly advanced version of FizzBuzz helping to sort out not just those who can't code, but also those who can't apply themselves and grind through some code challenges without complaining.

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.

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.

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.

Wouldn't any half-decent CTO put a stop to using leetcode exercises for interviewing job 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.

> the odds of you being a good programmer are pretty low

You're a good programmer if you've made something good. Most people who are good at leetcode have never made anything significant. When is the last time you saw someone who is well-known for some successful product linking to their leetcode account?

This is unconventional and in fact real wisdom.

> Everyone is playing safe and adhering to conventional wisdom.

That's not playing is safe, though, that's playing it wrong.

If the cost of interviewing candidates were zero and the was an infinite supply of actually good programmers, then it would be fine to err on the side of many false negatives for the sake of avoiding false positives, especially since the cost of false positives is high.

But that's not true. You pay a price for every interview, and pay a further price for every day without the qualified help you need. And you're probably in a competitive market -- a relatively small delta between you and your competitors' hiring efficiency might mean they get almost all the good candidates while you get almost none.

Anyway, like I said, any half-decent CTO should be able to fix such an obvious mistake. Hiring is a high-stakes move and it pays to be picky, but it really doesn't pay to be dumb about it.

Just based on my personal experience, I doubt very many people beyond junior or entry-level are going to study leetcode exercises, so you're walking away from almost everyone useful past that level.

Maybe you could give people a choice of problems only good programmers could solve, but of different types, and let them choose the one they want. Leetcode, sure. Or: here's a windows system and windbg, tell me what's wrong. You've doubled your chances. Spend some effort to come up with five or six or seven different ones and you might have something.

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.

Not only that.. a lot of developers, and “management” that wants to be involved with the tech side think they’re big tech in terms of:

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.

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.

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 just became a CTO. So, let me bear my thoughts.

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.

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 have never worked in games.

> but I fear what will replace me if I leave

So you'll never retire or die?

I’m not very old, healthy enough and if I die then there’s not much more I can do, can I?

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.

Doesn't seem extreme at all to me. I used to work at a place that would stress the importance of keeping implementations easy to understand and documentation up to date in case "[team member] gets hit by a bus tomorrow and we have to replace him." (Some people apparently thought this was too macabre so they would try to change it to "they won the lottery and quit instantly," but the engineering team thought this to be a less likely scenario than getting hit by a bus)

> I fear what will replace me if I leave.

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

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.

- Their actions and their words disagreed.

- Lost their best people within a year.

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.

This is such a good point. And doing this right can result in the technical leader feeling like they aren't providing value, especially if they are used to being great at solving technical problems themselves in the past. The manager dopamine loop is much longer and can at times not exist at all and you are still doing it right. I can see that it might be very tempting to try to get the feeling of accomplishment my stealing it from folks by disempowering them.

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.

> Maybe they'll read this.

Be proactive, send them a link.

Sounds like me 10 years ago, and I wish I took this advice.

If you love technical work, QUIT being an exec, a VP, a manager... do the work.

You WILL have a crazy time getting back into tech work, after 10 years, even if you were hands on the whole time.

Management / CTO and everything in between is best served by people who are technical, and are ready/aware/willing to move into a deeply political and financial driven domain.

I hated it, but it took me a years to really let that sink in and feel it hurting me.

If you can short circuit that wasted time. Do.

Absolutely agreed. I'm currently working my notice after 5 years of technical leadership, after which I've got a job lined up where I can get back to sitting down and writing code. The last few years have been great experience, and I have no doubt they'll make it easier to work with management types in the future through understanding the sort of decisions they're having to make, but I have no desire to play politics for the rest of my life while other people go and do the bits that motivate me to get out of bed in the morning.

I'm a sysadmin background, did CTO for 9 years and then moved to product afterwards from the knowledge I gained.

Being on the other side of the fence has really helped me move around, I still to sysadmin/DevOps type work but mostly moved into product and I've found it really helps.

Too many C level see product as only UI/UX and the teams I manage appreciate my understanding of the pain points for everyone

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.

Because bad organizations conflate leadership and dominance.

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.

Let me rephrase that.

The group is smarter, than an individual's dominant strategy.

They'll collaborate as a group to embarrass and undermine and quit that scene.

Fun fact, there are nearly no Animals who life in groups with "real" alphas, especially not Wolfs, maybe you can say Elephants where the oldest (most of the time) female is the leader (however that is because she is the most knowledgeable (location of waterholes, food etc)) and not because of her Character or "i want to be a leader" mindset.

There is one exception that comes to my mind with "real" Alphas and those are Gorillas.

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.

"Because I say so" is a terrible way to communicate why a thing is being done. In senior positions it is definitely necessary now and again to pull rank and tell people something is being done despite their protests, but I don't think I've ever found a situation where I couldn't articulate why that decision had been made. People may disagree with that decision, hell, sometimes I've disagreed with the decision I'm communicating, but you owe it to your people to communicate the reasons.

Fully agree on giving reasons. And more often than not there is room to discuss them. Also, from time to time, it doesn't matter weather or not we agree with those. And then there are those moments were there is no time to discuss.

Good leaders know to tell those appart, and professionals can accept it. Unfortunately, this combination, good leaders being in charge of professionals, is rarer then I'd prefer.

Too rare but when you get it, it's gold baby

Solid, 24 carat gold.

I had a situation recently where I had a report argue with me constantly over team agreement stuff like code standards and unit test coverage.

I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion.

It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of.

She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.

Yes but you already gave plenty of reasons before resorting to "that's the way we do things". And I think that's fine. What wouldn't have been fine would have been to skip the explanations.

Most people, given explanations, will accept them even if they don't agree with them. And quite often they will realize that there is more to the issue than they originally thought.

Adding to that list, and somewhat related to your first point: Never built anything technical of any quality.

A coach that never played can't teach.

Hard disagree. A good coach only needs to see the players on the field, notice the things that wins game, and figure out the way to motivate their players. Don't need to have played the game, though it helps. I'm thinking of one of the best coaches in the world, who played the sport at an unimpressive level as a teen...but at a young age he watched his father work as an assistant coach. That's where he learned his skills.

As well, the requirement for "must hit X bar of quality", where X is some arbitrarily high level, is nonsensical. If they're so good at building quality products...then why aren't they doing that in the first place. Necessarily, your best builders should be builders, and your best managers...should be managers.

> notice the things that wins game

> motivate their players

These are made so much easier if you have "played the game" that you pretty much end up back to the original argument of it being a requirement if being "a coach" to remain competitive. There of course will be outliers to this, like your aforementioned "coach that never played", but why deliberately base your point on an outlier?

> "must hit X bar of quality", where X is some arbitrarily high level

Quoting myself, I said "of quality", i.e. something that is reputable and, relative to some reasonable and well-known industry standard software development principles and benchmarks, of quality. I wouldn't say it's totally arbitrary.

I was a CTO once.

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.

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

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

> I'd leave a company quickly if the CTO started lying about potential problems not being problems

Absolutely. In the case of someone saying a clear problem is not a problem, we have a few cases:

The first, they're lying to me, in that case they're dishonest and I dont want to work there, they're probably just covering it up to make some money and then move on when things fall apart.

The second, they're incompetent and actually don't realize it's a problem, why would I want to work for someone who's bad at their job.

Probably others but I can't think of them

>all will be good when we release

Well I've literally been in the position where this was true to close a deal so we could stay in business. What would be the best option in your opinion? Risk a critical person leaving right then and loosing the customer and then losing everyone job? Or lying and telling them we are all ok just keep on doing your job and don't listen to rumors?

You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.

In real life, some people are human lie detectors, or at least better at detecting lies than you are a liar.

But I can acknowledge there are cases where transparency is simply not an option.

"Things are tough right now, but once we close this deal then we'll be in a much more comfortable position. Your role on this is critical to our success."

Is this not a reasonable way of approaching it? It seems to be simultaneously honest and empowering. What lie is necessary?

EDIT: slight revision

Compulsive liars cannot change their habits.

And gasp you may have to reward your worker because they truly are that valuable instead of reaping all the benefit for the cto.

Thats mostly a CEO trait. Remember CTO,CFO,COO,CIO, ect are all just jobs. You ultimately report to the CEO, whom ultimately reports to the investors,stakeholders, capital partners, b2b relationships and so on.

For the record I gave 100% of bonuses I had awarded to my staff and 0% to myself the entire tenure.

Who awards bonuses to themselves?!

I wasn't trying to write a business book but what you wrote is fine usually for the senior level employees that get how business works and probably took the job with the understanding of the weight of their position. However you will also have fickle entry/low/mid level employees that don't have the maturity to accept the realities of the business world.

> However you will also have fickle entry/low/mid level employees

You need to read that sentence again. Your comments are very revealing about you and not about CTO level work as you are imagining.

My comments are very revealing about the reality of the work world at mediocre aka most companies.

If you get a big enough group of people there are going to be some people with machiavellian tendencies or at least some that read bad advice on the internet about how to get ahead at work and try to apply it with clumsy gusto. You will look like a real fool to your boss the CEO if you are giving information to these type of people and they try to use it for their benefit.

I may be painting too dark a picture due to the focus the comments have on a single sentence. Overall I had good relationships with the vast majority of people that worked for me. I know this because I still have contact with most of them even though we have almost no chance of ever working together again. You are deluding yourself if you think there are no bad apples out there or that people having problems in their personal life may try to pull manipulation at work to get ahead or however they see may solve their problems.

> You are deluding yourself if you think there are no bad apples out ther

Please don't put words into my mouth.

> You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.

I'd rather my job disappear than still be there because someone with employment power over me lied to me. This isn't false virtue or armchair anything. No exceptions, or I don't work with you ever again. It's not hard. Learn to communicate effectively, and learn to treat your employees with the respect they deserve.

Consider that you're advertising yourself as the type of person who absolutely must be lied to in order to maintain morale.

I've been close to situations where the ICs did their absolute best and it was a total waste because of politics outside of their control. Do you tell them that so-and-so highly-respected person was shit-talking them because of an unrelated agenda and invalidated all of their work? Or do you tell them good job (it was a good job) and not get into it?

Frankly if this actually happened, I would do neither. Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you." and then address this as a grievous issue on behalf of my IC with the leadership.

If leadership doesn't fix the problem then just resign in protest.

EDIT: It's now occurring to me that there's probably different schools of thought here. Yes, I've resigned in protest on behalf of my workers before.

If my team is getting fucked, then I've either failed my team, or my purpose is meaningless. Either way, get me out.

> Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you."

And so you take your first step down the path.. "I'm not sure" is a lie here.

Why do post mortems happen for production issues, when you could just open up "git blame?"

Are you lying to the team when you say, "we're not sure how this happened" rather than just quoting the git blame?

Well, no. The problem is much more complicated than a buggy commit. It's a wider problem with the system. So you say "we don't know, we have to look more into it" and do a post mortem because that is the honest truth.

The same principle applies here. So-and-so highly respected person committed a real-life communication bug that got merged into this IC's production career. But the problem is much more complicated than that. You don't know what the actual problem is until you address it with the leadership team.

I hear you on all of that, I'm just saying that leadership gets complicated. Sometimes the lie is better for all involved, especially the IC. You recognized this with your first instinct on how to communicate it.

As far as the rewards for poorly-motivated actions, we've always got the long term.

> Or do you tell them good job (it was a good job) and not get into it?

Personally, I’m okay with not being informed about everything that’s going on. I work at a big enough company that I couldn’t possibly know what goes on all the way up the management chain, but even if I worked at a small startup, I could understand if management didn’t want to be fully transparent. I don’t need to know; it’s none of my business. But I won’t stand being lied to – even about small things, or things I don’t even care about in their own right. I see lies as a breach of trust and as a sign that I can’t trust that person, moving forward.

So it depends on what you mean by “not get into it”. If you really stick to truthful statements, and if there isn’t a high enough prior expectation of transparency to make it amount to a lie of omission, then leaving it at “good job” is perfectly fine. But if you do lie… well, if I find out, I’m probably leaving.

> Well I've literally been in the position where this was true to close a deal so we could stay in business. What would be the best option in your opinion? Risk a critical person leaving right then and loosing the customer and then losing everyone job? Or lying and telling them we are all ok just keep on doing your job and don't listen to rumors?

Well I've literally been in this position too.

Lying to people is ineffective. It literally leads to the rumors you want to avoid. And even if your lies pay off, people aren't dumb. They realize how close to the edge they were and that you are a liar. Next time it will just be worse!

It's much better to be honest. Explain the situation. Explain what it will take. Use it to motivate people and build them up. People love a challenge, they want to feel like they're the hero of a story.

You literally took a situation where your employees would have come out stronger and more motivated to work for you, and you turned it into one where they walked away with mistrust.

> You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.

It has nothing to do with virtue! Even if you don't give a damn about being a good human being, this is a terrible way to manage people.

> 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 actually wrote several responses and realized I was rambling on because of just how difficult it is to explain the reality of being in a decision making role. Rumors and politics are far far more prevalent than any acutal problems that will affect your people.

It is not your job to be responsible for other peoples personal lives, you are not the messiah. All you can do is fight to get them the pay they deserve. What they do with the money you have no control over anyway.

Layoffs at non Fortune 500 companies generally have less warning than anything can be done about anyway. Sure if its budgeted at Pfizer 6mo in advance your an ahole for not telling people. However its usually more like 2-4 weeks that the people in charge even know beforehand. ALso remenber we are talking about CTO. Its the CFO that knows the truth about the finances and may be hiding it from you as the CTO.

There seems to be quite a lot wrong in this post in my humble opinion... In brief, this reads as:

  * Allowing rumor/politics to become malignant through deceit rather than healing through truth
  * Dismissing responsibility for other people's livelihood because "hey its not my fault they didn't save money in case I throw them in the guillotine"
  * Using lack of information as a reason to lie, rather than just telling your workers that you don't know the answers.

These are definitely the antithesis of "good" leadership. "Good" from an empathetic, humane perspective, and "good" for business and profit. It's true we have to make unpopular, hard, sad decisions. Yet it is absolutely imperative that we remain mindful and diligent to our team as individual humans.

You are ignoring a hard reality. Other people probably want your job. If you look weak/uncertain/outofloop it will encourage them to come after you and give them ammo against you. Making your job at best more difficult or at worst a full blown power struggle.

Sorry but the reality of human nature is tough.

That is certainly one way to operate in the world! It is just not how my world works though.

If someone is actually better suited for a role than I am, then let them have it. I'll find another role and keep growing. Where is the problem?

If some team makes the mistake of confusing trust and openness with weakness, then good riddance, I'm better off with a different team.

If you truly think that a person can't be honest and trustworthy, while simultaneously being strong and confident, then I really don't know what to tell you. Disclosing hard truths doesn't mean being "weak and uncertain".

I know workplaces aren't democracies, but there's no question that I'd vote for the straight shooter (even if their own position in the company is weakened by that trait) over someone who plays the political game well but lies to their reports.

Hell, I would vote, with my feet, if I had to.

> All you can do is fight to get them the pay they deserve

You can also be honest with them so that they can make informed decisions for themselves. The best CTOs I've worked for have been honest people who give you the bad and the good news together.

> However its usually more like 2-4 weeks that the people in charge even know beforehand

I'm guessing you're not referring to public companies with significant revenue. There's almost always warnings well before the 2 week mark.

>I'm guessing you're not referring to public companies with significant revenue

>Layoffs at non Fortune 500

Yeah Literally what I said in my comment.

"Non Fortune 500" != "non-public companies"

There are many public companies not in the F500, and I agree with the grandparent that every executive will either know, or have a really good idea that a layoff is coming, well before 2-4 weeks prior, even if the internal finance/HR process hasn't quietly, officially started yet.

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

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.

Exactly what I thought. This is a view of employees as mindless drones whose only function is to make themselves busy. A very toxic management style. The advice that it is ok to be hated dogs the ditch further.

This is also an implicit permission to the employees to lie to the CTO. This is pretty standard narcissistic behavior, where your lies to employees are just doing business, while employees lying to the management is a grave offence that calls for job termination.

>employees as mindless drones ... very toxic management style.

I agree.

Did you just agree that you are a toxic manager?

There is only so much you can hide. Do you have BI? Well, they know numbers better than you, guess what? They talk to the rest of the company.

Do you have metrics available somewhere? Doesn't matter real-time or N days report - people can connect the dots: signs up are flat, but we keep hiring.

You can't meet requirements without marketing pushes? Well, shit, I wonder if a company spends 2 dollars to earn 1 dollar.

You can lie and bullshit all you want, but your reports and their reports will know.

I worked in a company where the analytics team suddenly decided to leave, all within days of each other. Month later - layoff. They weren't told that things are bad, they were the one who told you that things are bad.

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

That was not the reason.

I know its hard to understand if you are never in such a role. People can be very irrational and will look to blame someone in charge when bad things happen. Even if they are the cause of those bad things.

I had one guy that got obsessed with crypto and was doing crypto trading instead of his work, not showing up/logging in, not making deadlines. He went off on me for like 30 min when I fired him and never spoke to me again despite warnings and discussions about the problem before getting fired for one example. In his irrational opinion I was holding him back from getting rich by expecting him to do his job.

I've been on the reverse side, where it was obvious the CTO and CEO were hiding things. It's annoying for a while and then eventually there's some proverbial straw that breaks the camels back.

Word spread pretty quickly through various cliques in the company. Some teams had no idea what was happening, other teams lost literally all their developers and and couple managers over the course of 30 days.

During my exit interview I mentioned the dishonesty and they just doubled down that I was imagining it.

> People can be very irrational and will look to blame someone in charge when bad things happen.

Isn't that what you did?

> Even though the company eventually did go under due to bad investments the owner made.

That was a factual statement, so no. I think I get the personal attack you are trying to make at me though.

> I had one guy that got obsessed with crypto and was doing crypto trading instead of his work...

I think we are all very obviously not at all talking about the kind of situation you describe.

I left a company a little over a decade ago where the CEO and CTO (both co-founders) were lying to us about the company's situation for the better part of a year (which was longer than half the company had been employed there). I fortunately haven't had the chance to run into them since then, but I would absolutely give them the cold shoulder if I did. And that's because of what they did. I put in 80-hour weeks (including many weekends)[0] for over a year at that place, and they repaid me with a middling salary and worthless equity (after all common stock got wiped out less than a year later when the company got sold to one of the investors for peanuts and scraps).

Anyway, the one "nice" thing I can say about that CTO is that after they had a layoff (half the company), and I didn't get laid off, I went to the CTO and volunteered, and he let me go with the 4-week layoff severance package, which gave me a much-needed month off while I found another job.

(Speaking of startup equity, I'm just glad I wasn't quite out of college during the original dot-com crash, when colleagues I would meet a few years later ended up underwater on the loans they were encouraged to take out in order to exercise their company stock options. I can totally imagine wide-eyed 22-year-old me falling for a garbage scheme like that.)

> People can be very irrational and will look to blame someone in charge when bad things happen.

And sometimes blaming the person in charge is correct and rational.

[0] All stuff I will never again do for any company after that experience...

>I think we are all very obviously not at all talking about the kind of situation you describe.

Not really. My words were some people will hate you even if you do everything right. This was an example of a situation that was handled right but the person ended up hating me and slandering me for years afterwards. Just because I would not allow the company to fund their get rich quick scheme instead of their job.

I've even found people that I did not manage that got fired blamed me sometimes. Like all of mgmt was some evil cabal that conspired together to fire them cause thats what we really want instead of making the company money so we can all get out paychecks.

What people are doing is going off on a tangent of how they don't agree with how I handle the grey area stuff. There is a great deal of Silicon Valley worldview going on as well. The majority of the working world has lots of politics and pettiness going on along with power struggles and backstabbing. You cant be S.V. idealistic and keep your MGMT job in the middling business world.

> This will 100% require lying or being non-transparent at some point.

Are you ok with employees and reports reciprocating by lying to you as well.

Yes. FYI They will lie to you regardless.

My reports have lied to me very rarely, and I have never had to lie to my reports. For the reports that lied to me, I managed them out of my team irrespective of their work performance.

I have quit jobs where my manager lied to me. It is really really easy to tell when someone is lying.

You seem to live in some alternate dystopia where everyone lies to each other. How many of the companies that you have worked at have gone under?

Yeah I'm really confused about this guy. I get that the world is not black and white, and conditions aren't always ideal... but I absolutely do not put up with the kind of dishonesty he's seemingly advocating. Perhaps not everyone has the luxury to be so picky, but... damn, I really have not gotten the impression (in my experience, and in the experience of friends and acquaintances) that this sort of bullshit is that common. At least not at successful, healthy companies.

> Yes. FYI They will lie to you regardless.

If you create a culture where you lie, then people will lie to you.

If you create a culture where you are honest, people will be honest back to you.

There's nothing more powerful than going to your team and saying "Look, I fucked this up. I need your help". Honesty is disarming.

I'm in a field where I manage scientists. If people start to lie to me or even start to bend the truth a little, we will waste years chasing ghosts. The people that work for me are very savvy at figuring out what I think might be true and they can always present just the right data to make me happy. I had to learn early on that I need to be really explicit: we need to do good work, it doesn't matter if I'm right or wrong, it doesn't matter if they're right or wrong, all that matters is progress.

So no. Your employees don't need to lie to you. Mine come to me regularly and explain what went wrong. Judgement-free. And we do deep dives to prevent problems in the future.

You are causing the problems, not them.

> So no. Your employees don't need to lie to you. Mine come to me regularly and explain what went wrong. Judgement-free. And we do deep dives to prevent problems in the future.

I had a junior EE come and find me while I was on a smoke break to immediately inform me that he had mixed up two connectors and had accidentally put 48V into a piece of kit that could only handle 12V, resulting in $10k worth of blue smoke. That’s what a high trust engineering org looks like. He could have lied about it, I didn’t see it happen, “I dunno I went to reboot it and it didn’t power back on”.

That’s what I want to see. He was open and honest with me because I don’t feed him bullshit.

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

> Transparency is not your job

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?

Real life is not fair.

If the company initiative is to be transparent then sure you can be. However that is the vast minority of companies. Though people on HN may have a skew to thinking the opposite.

Curious to know where the statement "real life is not fair" is coming from / what it's referring to.

> do you want an opaque company where politics drive individual success >you want a transparent company where employees respect their leaders and where the best insight wins?

The comment I replied to has very startup company silicon valley skew to it naive of the majority of the world. Very few of us are in any position to determine or change the political/cultural/driving forces of a company we have to work at. Usually the best you can do is adapt to whatever is already there and try to make the best of it.

CTO is not a powerful position at most companies.

What part of the world are you from?

USA East coast.

Which company do you work for? I am making a list of companies to avoid.

> CTO is not a powerful position at most companies.

This I do agree with. Many CTOs don't actually have the entire engineering organization under them in the reporting chain (at a reasonably-mature company; not talking about a startup where the CTO is often one of the co-founders and runs engineering), so they have no real power to get other people to do what they think should be done.

At best they have an "Office of the CTO", or perhaps run the company's software architecture group (if the company even has one), and then they just have a tiny army of people who try their hardest to convince other teams to do things that aren't in their roadmap and would mean pissing off their bosses if they took them on. Not fun!

Yet in some companies, the CTO has the ear of the top executives. If some scheming non-technical career climber can get their way into the CTO's position, they can get to the top of the tree.

A lot can be achieved by aligning themselves with successful projects and crapping on others at the start or just at the cusp point of success or failure.

I've actually quit jobs because of this, so your employees actually don't have to put with toxic management.

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

I hope that's what the original poster who you quoted meant, because I don't see all that much wrong with the examples you mention. No, there's no need to engage people in discussions about things if it doesn't really impact them, or they can't really jump in and help the situation.

However, in the absence of some legal requirement to keep quiet, if some employee got wind of one of those situations, and came to you and asked you about it, I really do hope you'd be honest and forthcoming. Because otherwise I think that's when you'd cross the line (for me at least) into being untrustworthy.

One thing to mention though: in the case of your first example, if that huge deal really is going to fall through, no question, and the company is going to fail because of that, no question, I would lose all respect for an executive who didn't pro-actively have the hard talk with employees about that situation. Yes, some people will leave. But that's life, and your employees have entrusted their livelihood with you; you owe them that level of honesty.

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

Which is fine! Because if you truly did put out those fires, or at least put in place some mitigating strategies, then you were absolutely telling the truth that it was under control.

> I think job #1 in management is to shield the team from distractions

The difference is that some "distractions" can have a material impact on those employees' lives. An executive who hides those things and lies about them to employees is not worthy of respect. For "distractions" that truly are just distractions, sure, fine, no need to broadcast.

But I think a key question is: if a bit of news could make a reasonable employee, thinking logically about the news, decide to quit, then... you absolutely should be disclosing that news. Anything else is just a betrayal of the implicit trust an employee must have in their employer.

And yes, I know all this might seem pretty idealized, and I know there are a lot of companies and executives who won't get these things right. But that doesn't mean I want to work for those people.

Yeah for sure completely agree. Tbh I didn't think too deeply about the scenarios, they were more to put context around what I meant by "fires", and how not mentioning them (which some might consider lying) is necessary sometimes to steady the ship (though if a team member asked I'd let them know what's happening).

I do think scenario #1 is interesting to talk about though.

I.e. If I was that manager receiving that news, I wouldn't outright tell the devs and say "it could be crunch time for the next 6 months", which might cause a panic and devs will start looking for other jobs.

Instead I'd call a meeting with leadership / sales, see what was sold and if there's any flexibility on deliverables with the client. If we need more resource, is it worth finding funding to hire more staff, or maybe postpone another project to get this higher priority one done.

Once that's resolved then I can think about delivering the news. Maybe it's a non issue (e.g. a new team is spun up to handle the project and someone gets a promotion to head the team), maybe it's crunch time (in that case it's time to have a difficult conversation with the team), or maybe the client is flexible on delivery (so it's business as usual).

Again, I could see how some managers would be uncomfortable not telling their team everything (and potentially cause unnecessary panic) - but I think that's part of management, knowing what level of detail your team are happy with, knowing what you can / cannot handle, and knowing how to delivery good / bad news and sometimes having to be the bad guy.

I would add including the team once the path is clear.

What scares people is uncertainty. Not uncertainty of outcome (50% chance this will save us). It's uncertainty of what the options are, what the roadmap might be. That's the job of a good manager. Insulate the team from uncertainty and politics. Figure out the space of options, what the outcomes can be, negotiate it with leadership, and present a reasonable and clear plan to the team. That won't cause panic.

Show the team the plan, its rationale, and what needs to be done. What the upside will be. Let them take ownership of it. Let them make the lower-level decisions of how to split time, of what to prioritize, of what edges can be cut. With your feedback.

People generally don't bail when faced with a challenge. They like challenges. You just need to define the challenge clearly and set the path for overcoming it.

>I hope that's what the original poster who you quoted meant

Yes I did for the most part. I was replying to another persons wording though so many people have gotten out their pitchforks.

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

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.

Finally someone that seems to actually have some real life mgmt experience replying.

It's very convenient to believe that everyone replying to you who disagrees with you has no management experience, and the one lone voice giving uncritical agreement is the one person who does.

Wow is this straight up lying though? When shit hits the fan, what is your plan B?

> "You're job"

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.

I wouldn't judge so quickly, this kind of mistakes happen sometimes among non-native English speakers. In any case, CTOs don't do much, so the future of a company is not tied to the IQ of its CTO.

You do a solid job of feigning niceties for someone that seems to hold themselves so highly.

Good point, I agree.

I do know the difference though. I probably copy/pasted part of the comment around and missed that I changed the context. Shame on me for not proofreading my internet comment though. You should probably erase me from existence for my lack of vigilance as punishment...

Attention to detail is a big part of technical work.

I had a CTO like you once.

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 had a CTO like you once.

Then you didn't have a CTO like me. I'm still in regular contact with most of the people that used to work for me. One actually just texted me this morning to ask how I was doing. Even though our lives will almost certainly never intersect again.

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

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.

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.

This reads like a LinkedIn post.

The real CTO was the friends we made along the way.

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.

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.

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

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.

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.

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.

Ask yourself: what do you want?

If you don't like who you're becoming, move on.

Good luck :)

Apologies for not responding sooner.

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

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.

Is this your first time managing people as well?

No, but first time for so many, I’ve had 3 direct reports before and in my last company I had 1

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.

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.

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!".

You realize that is the very edict that basically started at Amazon and came straight from Jeff Bezos in 2001? I think it worked out okay there (here).

I wasn't saying microservices are bad (personally I love them, maybe too much:). Just that making technology decisions based on someone's else's anecdotes, in the absence of any technical understanding, is a bad way to go.

Not quite. Jeff’s “edict” came via a lot of analysis, trial-and-error, and information gathering throughout the entire Amazon organization over the course of many years.

Amazon had huge dependency problem, both technical and organizational. Technically, the effort to work in their monolith scaled superlinear with respect to the CL size due to coordination and review with other teams. Organizationally, teams were dependent on an ever growing set of centralized, global processes that further slowed their ability to make progress.

Jeff (and S-team) saw these issues and worked to solve them through a series of experiments. Specifically, Jeff tasked his then CIO with finding a solution. This CIO worked throughout the organization to gather on-the-ground feedback around what was and wasn’t working; built a model for how Amazon _should_ work based upon that sense making; and then tested, iterated, and refined that model into what we’ve come to know as Single-Threaded Leaders and Two-Pizza teams, etc., today.

In parallel, a couple Amazon business units were experimenting with exposing their data via textual (XML) APIs like the Amazon Associates API which went on to become the Amazon Product Listings API. These early APIs were sort of the POCs that allowed Amazon to see early validation around the concept of web services.

Synthesizing all these different streams of information, ideas, and actions lead to Jeff’s “edict” around building standalone web services (which eventually led to what we know as AWS today).

In short, Jeff is the exact antithesis of GP’s straw CTO. He speaks from data, facts, and information gathered from a myriad of internal and external sources, not merely anecdotes of success from a CEO buddy. :)

Source: Working Backwards has a lot of information on Jeff (and Amazon’s) decision making.

> I saw terrible decisions made by CTO and CIO

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.

It depends on the company size. On a small startup with 10 people and a company with 1000 people have different CTO definitions and roles.

Yes, certainly. In a tiny startup the CTO is just a lead developer with more stock options than the others.

A CTO often will be the referee for making big technical decisions. If that CTO doesn’t have a good bullshit detector then bad decisions will be made.

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

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.

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.

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

I wouldn't respect a CTO who couldn't pass a technical coding interview.

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

If the CTO isn't a technical domain expert then they are just middle management overhead.

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.

Let me guess, CFO's also don't need financial expertise?

They're not saying they don't need to have technical experience, they're saying they don't need to be a current technical domain expert. Of course they need to understand how software products are created, but they don't need to know to optimise your DB queries.

That may not be the case at a small 5 person startup, but at a larger scale with a full division underneath you shouldn't be getting involved in the nitty gritty of why the database fell over. You should be making sure the engineering teams are being given the space to have those discussions, learn from it, and improve.

The CFO of a similar sized company isn't sitting down and running payroll. They're talking about strategies to re-organise budgets to enable product or territory expansion. Or they're looking at the decisions leaders of a potential acquisition have made, and whether they stack up to the top level figures.

Both roles are fundamentally business and people focused roles. They require the holder to take leadership of a specific area (technical, financial, or what have you) and run it efficiently to server the business goals. That requires you to have a good understanding of the area. The more you have the more likely you are to succeed, but you won't be writing code as a CTO. In the same way the CFO won't be running the tax calculations for payroll that month. Not once you're past 50 or so people in your division.

> They're not saying they don't need to have technical experience, they're saying they don't need to be a current technical domain expert.

No, they're arguing against a point nobody made:

> This misunderstands the role of CTO which is to be a single point of responsibility and leadership for all the deliverables in engineering.

Nobody said that.

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.

> It's hard to convince the team we are desperately underfunded when on the surface it looks like we're doing fine.

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.

> doesn't know that his core infra team just wrote something in Rust

Sorry but that is something he should know. That directly affects technology radar and roadmap, HR and a bunch of other stuff.

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.

A real head-shaker for me.

What do you mean, the way to get quality isn't to frown while you say "more quality"?

Of course not! You also have to mutter, "but hurry up" whenever people do something that might actually improve quality.

No, no, no. That gives entirely the wrong association. You have to smile while saying "more quality".

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.

I believe you don't see the problem. How can I help you see it?

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.

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.

That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user.

One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.

I can't quite imagine you not understanding this from what I wrote, but for me "making things for people" includes "making things better for people".

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

Indeed! Honestly, I'd expect a moderate inverse correlation between valuation and code/practice quality.

I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't.

But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.

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

Thanks for the kind words. I don't consider myself a "brilliant" engineer. More of an experienced engineer. I've been building software products for 30+ years.

I think the role of the CTO varies based on the scale of the company.

This article on the types of CTOs is useful framing: https://www.allthingsdistributed.com/2007/07/the_different_c...

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

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!

Nice! What approaches to microprocessor design do you think are underexplored? What surprising mistakes have you made? What design possibilities are just starting to open up? What do you think of Alan Kay's claim that modern microprocessors are unnecessarily slow at running late-bound languages like Smalltalk because they're optimized for C?

I guess I should clarify that I've been looking at weird things like Chuck Moore's Forth chip designs, the Smalltalk-80 virtual machine, the HP 9100A, the Burroughs 5500, and SeRV, but although I've implemented a virtual machine or two in C and carried some design sketches down to the gate level, I haven't run them on an FPGA or a breadboard yet.

^ for context, sponaugle is CTO of Surescripts, LLC; a 500 employee SMB.

https://www.crunchbase.com/organization/surescripts

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

Why was it a mistake to introduce yourself as such?

A play on the words.. my title was Chief Technology Officer, not Chief Technical Officer.... which in the context of this post is perhaps telling!

Sorry, I'm still confused. Is there a salient difference between Chief Technical Officer and Chief Technology Officer? I've always used and heard these as synonyms.

I think many people would consider either to be a good term to use.. but in the context of this article that we are commenting on (about CTO being technical), the slip is an indication of my predication to CTOs being technical.

Usually CTO == Chief Technology Officer, not Chief Technical Officer. But an amusing slip of the tongue that kinda works out! :)

Also, learning to dodge coffee chats so you have time to actually study and keep up with the times in tech.

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.

[0] https://www.linkedin.com/in/adityaagarwal3/

Every single person has different opinions about how technical a non-IC should be (manager, director, CTO, VPE, etc). There's really nothing to argue here - it's not one way or the other. It all depends on the maturity level and size of the company and also an individual's personal interests. Moreover, in our industry where job roles/responsibilities are not uniform or standard, it's not surprising to come up with your own versions of each role. It's no surprise why a Principal Engineer from one company may or may not stand a chance to make a lateral move to another. These kinds of articles come up every day and I strongly feel that they are an utter waste of time. Stop generalizing. Talk about what the CTO is expected to do at "your company" only.

I've been a CTO for 5+ years and have grown a company from 1 to 15+ engineers.

I agree that a CTO SHOULD be technical but it shouldn't be their only skill. The CTO's skill actually varies depending on the stage of the company and being technical, helps in making decisions in every stage. A core part of being a CTO is to set the technical direction of the company, you are a Chief Technology Officer after all. A part of a CTOs job is to know how to execute/deliver the plan of the company in the most efficient way technologically speaking. As the leader in the engineering department, if you have say a budget of 1 million USD, not only do you have to know how to allocate this efficiently, but also know the technical details of why you do so in the grander scheme of things of building the product.

As an example of my said stages, if you are with a company that has:

1-5 engineers: The CTO is mostly likely coding and also making decisions on what technology stack to use and sets basic processes for development (kanban/scrum or basic todo list).

5-15 engineers: The CTO is mostly doing process management and technical analysis of the stack to set further systems and processes for future growth. Here you will start to find the issues of the technology, you are growing the engineering team because there is a further NEED to hire. For example, you hire more frontend engineers because the plan is to build a more ambitious frontend.

15+ engineers: Here you already have established good processes and have the product moving forward with teams being mostly self sufficient. The CTOs job at this point is to work more with product to know the future roadmap and efficiently plan further hires or changes technically speaking.

My few c's from this. I've yet to experience growing a company for 50+ engineers but that is a goal that I have still going forward.

Good comment.

Thank you :)

This really is a one-sided view. I'm not saying it is an incorrect view, but I find that all dogmatic stances are only correct part of the time. Some small companies need a technical CTO. Large companies need a leader who can effectively delegate the technical aspects to his organization. Companies in the middle... will vary.

I like the way you stated this. Just as the right technical solution is contextual, so are the leadership requirements.

I will say that a CTO of a large company has to have a really good read on the technical constraints. Whether this is achieved through technical expertise, or having a warchest of talented lieutenants is an implementation detail. That said, even the lieutenants can't be in every room, and if the company faces substantial technical challenges, there is a high risk that a non-technical CTO makes commitments the team can't live up to.

In a well-functioning team, a lot of this can be papered over by the lower-level folks (managers and ICs) finding a way to do the right thing on an unofficial basis. I would go so far as to say that all successful companies depend on that unofficial network of clueful employees doing the right thing in spite of formal guidance. But at some point leadership is going to have to make some decisions, and when that time comes you better hope they have put at least as many hours into their relative domain competence as they have into schmoozing big wigs.

If the CTO isn't technical, how do they know what to delegate? Who to delegate to? How do they determine who to listen to?

Think about it via an analogy - do you know how to fix your own plumbing? If not, how do you know who to hire to repair your home? In short, you look at what they have done, listen to people who have worked with them, and react accordingly. Once you have hired someone, you have your own direct experience with them and can judge for yourself whether or not their work met your needs. If they meet your needs, then the relationship is working. If not, it isn't so you let them go and find someone else.

Technical people looking up from the bottom often expect some type of meritocracy where being good at your job earns you promotions and responsibility, but that isn't really how leadership works. When you are trusted, you get promotions. For exactly the reasons stated above - leaders delegate to people they have worked with before and trust that the needs will be met.

So as a leader, decide who you trust. As someone lower down the chain, work to build that trust.

How to decide is the question.

If you're a CTO, do you trust your person A or B? If you're not technical what do you base it on? What are you judging?

Are you judging based on their personality? The number of brownbag talks? The feedback from peers?

What you want is for someone to know how things work. And if they don't know, know what to ask. You want someone who's done it before. They have to be technical.

You want your chief of plumbing to know how to plumb. You don't want them to just be familiar with plumbing. If so, the next thing you know a good salesperson will talk them into replacing all the pipes with new wonder-pipes with space-age wonder-clamps.

I feel that as a CTO a lot of the respect I earn from our developers comes from me having a deep technical understanding not only about how things can be done, but also about the pitfalls and obvious issues that can make something fail.

My experience as a software engineer definitely allows me to approach issues in a more understanding way and find alternative solutions that accommodates for them instead of finger pointing and shaming.

I think a CTO should have a good understanding of the topological structure of the systems they're effectively responding for, and they should have an understanding of the feasibility of roadmaps.

A CTO without technical knowledge cannot provide suggestions or iterative steps when some plan goes south other than generic coaching. I've been in a lot of cases where our developers were stuck because they couldn't make decisions outside of their team.

I feel my job isn't to simply respond to the CEO but to ensure that friction is removed between the teams. I would simply be unable to do this properly if I wouldn't have a deep understanding of what every team is working on, how their systems connect, how their stacks work and what budget constraints we have (also what impact an alternative course would have on the budget).

If your CTO is 10 levels removed from the developers that's a different thing, because then the job of the CTO is nothing but a glorified proxy for their direct reports to the CEO.

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager.

As an engineer and a manager I took my time to understand the basics of management, design, marketing, business development etc. to have educated conversations while building a product so I don't see why someone in those roles shouldn't do the same.

I would also feel the need to catch up with whoever the best engineer seems to be on my team because I'd just assume they wouldn't respect me if they perceived me to be vastly less competent (a degree of technical incompetence can be offset by good soft skills of course).

Either there's a misconception about how complex "technical" stuff is, that prevents those (smart) people from touching it with a 10 foot pole, or (conventionally) technical stuff is indeed more complex than (conventionally) non technical stuff.

I lean more towards the latter (after all market demand and compensation are a good indicator of that) but I'd be very happy to be shown that's not the case. I know plenty of engineers that are successful "solopreneurs", I don't know anyone who isn't technical and managed to do the same without a technical cofounder.

Not claiming "engineering is easier than marketing", just that, on average, technical people can do 80% of what's required to build and launch a product, non technical people can do around 20% (although the ratio might change once these no code tools become more popular / powerful).

> I have a really hard time working for someone who isn't technical, regardless of their role.

In both cases — technical manager and non-technical manager — the engineering culture at the organisation ultimately determines whether the arrangement is successful.

In the past I’ve experienced friction working for a manager who had different ideas about how particular technical problems should be addressed.

If you're someone who has pride in their work, you should want to learn. Technical curiosity is invaluable in this field and it seems odd that there are people who insist on sticking around despite lacking it.

I don't think a lack of technical curiosity/professional pride is exclusive to managerial types, but there is a surprising number of people who hate the technical side but still want to be bossman.

i worked for a non technical manager, and it was ok. because he trusted his employees. he said this is the deliverable, and these are the constraints, what do you need, who do you need, and how much do you need. we told him, and he went to fucking bat. obviously he picked up a little here and there, but by no means could do the job of a junior.

it worked well, he shielded us from the corporate politics, got us everything we needed, didn't over commit us, and we delivered on estimated dates and to scope almost every time. because we picked times and materials and he made sure it happened and that we could focus. was good times

Totally agree there's no hard and fast rules here. That said, this person probably lucked out with a dependable team, and no doubt relied on intra-leadership (from yourself or peers I would assume!) to manage - and deliver - effectively. This kind of dependability doesn't usually appear out of thin air. It's also a bit of a catch 22 to replicate.

I've worked with similar people and there is definitely a place for them (tho probably not at the peak of the structure). But it's also nice to have someone that can critically discuss a solution and sign off on decisions that they fully understand. IMO.

> I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager.

I agree, but in my case I think there's also a "narrow band" for what I'd consider a technical manager to be. I want them to be able to understand if, at times, I need to get into the weeds describing a technical problem. I wouldn't do this often; I don't think it's necessary or useful to burden a manager with deep technical details most of the time. But I want it to be possible to do that when necessary, without seeing the manager's eyes glaze over.

But at the same time, I also want a manager who is primarily focused on the "people" aspects of management. Engineering managers should not be coding, or even doing code reviews. Part of it is because I don't believe managers should be in so deep on the technical details, because to do so means taking too much valuable time from people management duties. But the other bit is that I don't like the power dynamic. I don't want a manager to force -- or even have the unconscious appearance of forcing -- a report to change some code in a code review because they have the added "I'm the guy who decides if you still have a job" power. And in the reverse interaction, if the manager is writing code, I don't want their reports to have to walk any kind of "don't piss off the boss" tightrope when providing code review feedback.

The power dynamic bit is a reason why I also think that a team's technical lead (for orgs that have tech leads) shouldn't report to the team's manager, but should report up a level. I think it's valuable if the technical lead feels like they can argue against the team's manager's opinions without being afraid of (even unconscious) retaliation.

So I think it's hard. Another top-poster here (the CTO of Surescripts) seems to have it right: when he's at work, he focuses on people and the business, with the technology an important part of the job that he doesn't dive too deeply into (but can still hold his own in technical discussions). And he keeps his technical/engineer side happy through deeply technical side projects on his own time. I think that can be really hard to do, especially for an former developer who is new at the manager job. (Not to mention having deeply technical hobbies and side projects takes up a lot of spare time, spare time that many people may not have.) But I think it's essential for having a healthy team with reports who respect their manager, and understand that the manager respects their technical expertise, and doesn't try to dictate technical decisions.

Strongly disagree with the scope of this. Should a CTO be technical? Absolutely. Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming? Absolutely not.

As others have said, development is a full time job. It requires focused time and you need to remain current and have context for the state of the project. If a CTO is spending all of their time in the code, they are not doing the tasks of a CTO. If that doesn't matter and doesn't cause issues, you probably don't need a CTO.

I've worked at a company with a CTO who was an extremely talented developer but really that's all he wanted to do. He'd avoid meetings like the plague, never managed anyone despite have several senior direct reports, and would only really engage with others when technical issues came up where he could jump into the weeds in and help solve the problem. Essentially he had the title "CTO" but in reality all that meant was he was a superadmin developer who could work on whatever technical problem he wanted with nobody to report to.

Agree, also his example of the CTO was "Dropbox". Dropbox is/was basically only a "folder that syncs reliably". For that role, this is deeply technical low-level work and yeah, that CTO probably should be very technical.

The CTO (once the team is >10 or so) really only needs to be "as technical as needed to make smart decisions". This will vary a lot by company.

Dropbox also completely lost the market they invented to Box, largely because of nontechnical considerations.

As Steve Jobs said, DropBox was always going to end up being a feature not a product.

For the same price you pay for DropBox, you can get the complete Office 365 with 5 TB of storage for five people or GSuite with storage.

Imo that quote only ever made sense when you add "[compared to apple]" which was likely how he meant it. Also have you tried actually using gsuite storage?

I think it makes more sense when it comes to Microsoft Office365. I wouldn’t use Google anything for something I depend on.

Dropbox has about twice the revenue of Box. Box was founded a couple of years before Dropbox. However, both only have a small share of the value of consumer and commercial cloud storage at this point.

When i talked to dropbox folks like 5 years ago they scoffed at box only being a third of their revenue. Sounds like they’re closing the gap

Yes. This. I agree with you and the parent comment.

I was "CTO" of my very small startup with < 10 people and 3 total engineers. I was extremely technical and hands-on in that role. I've worked at a mid-sized business that didn't even have a CTO, despite having 4 FTE software engineers and a network infrastructure team.

I now work for a globally distributed Fortune 500 company with nearly 100,000 employees working on hundreds of technical projects using all sorts of tech stacks and code from Embedded C to serverless SaaS offerings. The notion that my CTO should be able to "jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming" is absurd. It might be nice to have a CTO that's been in that role at some point, but no way should I expect them to be able to tomorrow.

> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming? Absolutely not.

The point was that a CTO should be able to do this in theory. Of course they won't ever actually do this unless there's no other way.

If your CTO can actually relate to the problems of their staff, they'll be able to make better decisions which also see more acceptance.

I’ve had two jobs where I reported directly to the CTO - the first as Dev lead with people management responsibilities and the second as the de facto “cloud architect” that was responsible for the “application modernization” initiatives.

My second CTO was very technical and up to date the first wasn’t. The only difference between the two day to day was with the second one, I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.

I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.

Thanks for the insight.

I'm wondering what the devs at both companies were thinking about their CTOs. My point wasn't that much about direct reports to the CTO, who might already be used to talking in management terms, but rather the developers who are directly affected by the CTO's decisions.

If the devs are reporting directly to the CTO, the CTO should be technical. If not, the CTO should delegate dev leadership to someone who is both technical and business oriented.

As my last company grew, the CTO just didn’t have the bandwidth to be technical at work and delegated different responsibilities to the people who could wear both the technical hat and had the soft skills needed. He would just dabble in things on the weekend. His entire family was technical. His wife was a lead data analyst for a telecom and his daughter got an internship as an SWE at BigTech.

> My second CTO was very technical an up to date the first wasn’t. The only difference between the two day to day was with the second one , I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.

> I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.

Something to consider: there is probably not much difference between technical and non-technical when their reports are good.

But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

> But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

Very true. GP probably had good tech judgement which is why their technical CTO was following their judgement.

I had never logged into AWS when I was hired. I just had theoretical knowledge. In the land of the blind, the one eyed man is king, I’m amazed to this day that the CTO trusted me knowing that in advance. Don’t get me wrong, he didn’t blindly trust me. He pushed me harder than any other manager ever had to do things correctly and to think deeply and to write well reasoned documentation and presentations.

I told myself that there were only two positions at two companies that could have convinced me to leave. I got hired by one of those companies. He left less than a year later after the company was acquired for 10x revenue. He’s working somewhere else now. I would work for him again in a heartbeat if I were working anywhere else besides where I work now.

> whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

I am genuinely wondering if I need some jiffy lube for flushing those fluids of mine.

It... sounds like... a thing... that people... do?

>But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.

The non-technical CTOs "defense" is having found which reports they can trust and support to make the correct tradeoffs. Then they do that. More broadly if your reports aren't competent or trusted enough to make the right decisions then find new reports.

The job of the CTO isn't to argue some stupid architectural point with people for hours. It's also not to blindly overrule them. Their job is to hire people that know more than them and can be trusted. Then it's to setup the processes within which those people can thrive.

In fact the problem with technical CTOs is that they can rely too much on their own technical knowledge versus fixing the damn organization. It's basically a bunch of band aids being put on a gushing wound.

You are right; you have to relate to the problems to value your people more I find. I used to jump into code as cto and I lost good people because of it as they felt it was lack of trust (it was I think but I did not realise that back then). When understanding how things work and giving the team the means to get it done by supporting them instead of trying to do their job is something I see go wrong in many cto’s, including my former self. I still like coding more than managing but I realise that there are other people so much better at the code part and I need to hire and guide them.

> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming?

In the roles they worked at immediately before becoming CTO they certainly should have had the technical capability and knowledge to do so, yes. Maybe not directly as CTO anymore but they need the grounding and experience to understand what the various tiers of engineers underneath them are grappling with.

I'm reminded of a blog post (https://rc3.org/2015/12/29/answering-the-question-should-man... , focused on software engineering managers rather than CTOs), which posited this guideline:

"A manager actively avoids creating situations where their coding is necessary for the success of the project."

I agree with Aditya's article. A CTO must be technical for all the reasons stated. I would add another reason to his list: a CTO must be able to challenge the assumptions, plans, and estimates presented to him/her by the engineering team. Doing so requires technical acumen.

He probably wasn't the right person for the CTO job. But that doesn't mean that the CTO shouldn't be as much of a technical expert as that person is. It's just that that person didn't know how to switch to using his expertise at a leadership level rather than at the engineering level.

Counterpoint example: Evan Wallace

The only competent CTOs I have seen in the telecom and network engineering business are ones who came up through the ranks either from field technician, or junior NOC desk person, to network engineer and onwards through 10, 15, 20 years of career progression. Everyone who did not take this path was missing critical information that should be used in network architecture decision making.

There's a point when "technical enough" comes back into the picture. A gigantic company with 50k employees the CTO is barely relevant to any real tech decisions. They are tangentially related but not "in-the-weeds" technical

Contrast that to a tech startup, or any startup I suppose. Those CTO's absolutely need to be "in-the-weeds" capable.

I think it still matters because of hiring. The type of people rewarded with promotion at the top tend to promote those people and so on down the levels. A nontechnical CTO will start promoting nontechnical people managers and eventually you will have an org run by MBAs.

Yes for sure. But those non-technical, big company CTOs are going to be hiring people who need to be good at hiring people. Those are going to be your VPs of engineering types. THOSE people will be 'more technical' at that point. Those VPs of engineering are going to hire directors and so on down the chain. As you descend - it matters more and more that they are good technically. So if you're at a 50k size company, the CTO is so far from anything important that they operate at 'mba level with some technical acumen'. The smaller the company, the more important the role becomes.

Even at the company I worked at with 5000 people - the CTO was still nothing more than a glorified 'decider'. The company with 250 people - the CTO was far more necessary to be technical

I'd argue that the VPs, all the way up to the CTO need to almost as technical as the lower levels. Otherwise how are they supposed to accurately evaluate who to hire, and their performance once hired. They can go on end result metrics, but those are subject to confounding variables, and are not really accurate enough to make good decision on. It's really hard to tell the geniuses from the bullshitters if you're not able to get down into the details with them on occasion as needed.

I mean it depends on what kind of company it is. If software development is the company's core activity I think that this kind of setup is likely to fail slowly.

What's incredible (and frankly horrifying) in this blog post is the complete lack of anything pertaining to what /kind/ of company the CTO works at. Surely, that must be important; a large company that sells a non technical product may need a very different CTO from an enterprise software company, who may need a very different one from a quantitative trading find.

Along those lines, I find the lack of connection to anything pertaining to product market fit equally horrifying. Sure, you might say, that's the job of the head of product.

But if you're the CTO, you are going to struggle to prioritize your engineering roadmap without very strong product chops, and moreover, you will struggle to "skate ahead of the puck" and ruthlessly cut out infrastructural nice-to-haves versus necessities. You may also blunder into architectural traps that come about from insufficient awareness of product risks.

It is a real cop out, and a vague one, in my opinion, to say that a CTO "should be technical." The big question is "what kind of technical."

In contrast to this blog post (which I find a little empty, sadly), I'd recommend one of my perennials favorites: Werner Vogels post about the 4 different kinds of CTO:

https://www.allthingsdistributed.com/2007/07/the_different_c...

What I like about the quadrant is that it maps the four kinds into rate of business change on one axis, and information as percentage of products/services on another axis. This is really useful because it lets you stratify what kind of CTO you'll probably be looking for based on what kind of business you're looking at, which is very important because the world of business needs for CTOs are /vast/ and heterogenous. CTO could mean many different things at many different companies.

A good framework for whether a CTO should be at X should also account for "at Y kind of company."

> Surely, that must be important

Certainly. That you noticed this aspect is deliberately omitted is very insightful; it's not really possible to discuss the matter intelligently without this information. CTO of a grocery chain is far different than CTO of an aerospace company. You can try to believe otherwise all you want, but you'll always come up wrong; the real world is complex and can't be abstracted away by titles.

Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers.

The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.

I think I’d like to see CTOs have come from the frontlines and decided they had a larger interest in running the technical side of the business and then grow into it. Someone who once did the job and now is much higher level still to some degree knows how the sausage is made and can be a more effective leader imo.

Absolutely agree that a background in technology is important! I’m talking about the idea that someone who started as a dev many years ago is going to be able to write code in a current environment with the same level of skill as someone who does this everyday.

Doesn't have to be. But if software plays a major role in the company, then it is certainly an advantage if the CTO knows how to code.

I agree. I think the author of the article would have done better if they had focused on their list of five important CTO skills rather than dragging coding skills into the narrative.

Amongst other necessary leadership skills, I do agree with the author that CTOs should be:

1. Good judges of quality.

2. Able to make good tradeoff decisions.

3. Able to earn respect.

4. Able to inspire teams to greatness.

5. Able to recruit top talent.

However, it isn't necessary for a CTO to be able to do everyone else's job to have these skills and be a great CTO.

The article doesn't say they should spend time writing code. It says they should be good enough to be employed by you to do so (if they weren't being employed as the CTO). It means that they ought to be ABLE to have an informed and intelligent conversation about technical issues at a LOW level if need be. They should't need to very often, and never to actually put code into production. But it's a vital skill for hiring and tie-breaking in case of conflict further down the hierarchy.

If your company is under 100 people and only a small percentage of them are engineers, the CTO better be able to code. (Whether they actually do or not is another matter, but they should understand the details, and with tech, that means code.)

I always envisioned a CTO should be something like a Chief Pilot in the airline world. In an airline, Chief Pilot is the highest-ranking member of management that can (and does) still fly passengers around. This gives them unique insight into flight operations.

So a CTO should be someone that can still (and from time to time does) write code. Doesn't mean they do it every day, but still enough to give them insight into the development process.

I'm not sure if this is feasible in really large companies, but I think definitely should be the case in small and medium ones.

Having been a CTO (and not wanting to be one ever again): it is incredibly difficult to stay connected to technical details when being a CTO. To really feel and understand technical issues you need to write code. Not all code, but at least some, on a regular basis, encountering issues yourself. Fitting that into the schedule of a CTO is very difficult, as you will be expected to be on "management time", e.g. available at any time for any kind of meeting, chat, road trip, or phone/conference call. You can't set time aside for concentrated work.

And believe me, to be a good CTO, you do need to be connected to technical details and understand the tradeoffs. Just talking to other people who code is no substitute.

In my case, I decided I will never again want to be in a management position where I cannot spend a significant amount of time coding.

I was CTO long time ago. Rose to position from being a programmer in small company. As the company grew bigger I kept moving up. Was still pretty technical though. I still coded a little in order not to loose sanity but most of my time was spent doing high level design, architecture, getting into some strategic technical partnerships and so on for some giant projects in telecom and other enterprise software areas and making sure it was correctly interpreted down the line.

Then one day new owners came and after talking to them a little I said fuck it and went on my own. Consequence of being close to burnout. Now 20+ years later even though I did not become rich I have my own one company where I design and create products. Some I own, some are done for numerous clients. I mostly work alone but hire subcontractors on on need basis and am happy like a clam.

Dilbert moment I remember is from a few years ago I was presenting a proposal to create a web app with a bunch of front-end engineering requirements to the "CTO" of a large transportation company once. We covered topics like JSON-LD schema, HTTP/2, responsive images, asset fingerprinting, that the solution would include and provide etc.

He asked us why we can't "build the website on wix".

> He asked us why we can't "build the website on wix".

This strikes me as a very effective question.

Even if the answer is "because wix can't do asset fingerprinting, etc", then the CTO now knows the limitations of wix.

And, it also leads to the question: "why are responsive images, asset fingerprinting, etc _absolutely essential_ to solving the business use case", i.e. Could we build a valuable product even without those technical details.

The question is: what tech?

I worked at software companies, where the CTO was equivalent to the CIO, and I worked at classical engineering companies where they had both, because their tech had nothing to to with IT.

This is an excellent point/question.

As a software engineer, I've worked at companies where the both the CTO and one of the VPs were what I would call CIOs -- they were networking/infrastructure people.

Writing software in an org like that is often an exercise in insanity. To many infrastructure people, the software itself (and related topics like developer experience/productivity) are barely even things they can wrap their heads around much less care about.

I am sure that the inverse is true. Trying to do infrastructure work in an org run by software-brained people is probably equally difficult.

"I'm not a tech person." are five words you never want to hear from someone with "technical" in their title.

There's "can write decent C++" technical and "being able to choose between Sybase and mongodb" technical - the latter is probably more appropriate for a CTO. It depends a lot on the product, the size of the company and the technology being used.

If a person who isn't coding all the time can pass your coding interview its too easy. A CTO should have been able to pass it in the past and possibly pass it with a little revision and practice, but for most CTOs coding ability isn't that relevant.

The good CTO: "Sybase is more expensive than MongoDB but provides better replication. Any thoughts?"

The pointy-haired CTO: "I read that most sites are using the PHP these days. Why aren't we using that? We should get started adding the PHP to our project. MongoDB go burrrr"

Microsoft employee here. I really appreciate CTOs who are technical. They understand certain challenges of delivering products and they are often more sympathetic of last-minute issues. But Microsoft is a different company than maybe startups or smaller companies. So, I am not really sure.

I'm going to put this out on a limb - CEOs should also be technical.

I agree with that

How is this even a question? It's because demand for engineering leadership is so high that non-engineers with political skill and sway with investors land in engineering leadership roles.

back when the word CTO was invented it had a different meaning than it does now. It used to mean the person in charge of the technology for a non-technology company. So for instance, a Wall Street firm would have a CTO in charge of their computer systems, critical infrastructure for their business, key technology trends to anticipate, etc., needed visibility in the C suite, but it's not their main business, it's not a profit center.

A technology company would have a VP of Engineering, because that's what the company does as a core business. A company like Boeing could have a VP of Engineering wrt the airplanes they build, and a CTO wrt their CAD systems. (I just made that up to try to give some flavor, not saying that's literally true)

I believe it’s better if they are.

I once reported to a CTO whose bible was How To Influence People and Make Friends.

He ordered a migration of 4 million records to be done in a weekend because he had promised the CEO “everything would be fine by Monday” but I had told him that that plan would require 5 days to put everything in place, even a rollback.

The fact that he refused to hear me out when I pointed out the infrastructure capacity and the SQL scripts tested beforehand to arrive at my estimate made me wary of management that doesn’t understand even the basics of the technology we use.

So I think it goes a long way when CTOs are technical. They can give more realistic deadlines to reports while being able to be reasonably honest to their colleagues about estimates and progress.

I once reported to a CTO whose bible was How To Influence People and Make Friends.

On the flip side, I once worked with a CTO who was technical, but couldn't make friends or influence people. End result was that he couldn't get senior managers behind his ideas or plans and nothing he tried to do went anywhere.

The way I've heard it phrased is the CTO should be able to code, but the CTO shouldn't code.

This is idiotic. Practically nonsense

Care to explain yourself? Or just having a bad day? : - )

Of the top-tier best CTOs and Product Visionaries I've worked with, exactly NONE of them are competent coders. They know enough about coding to discuss implementation architecture, but actually writing code is not something they do, nor should they, since that requires keeping up with a zillion fiddly things they left behind to be able to see and properly guide the "big picture" product vision.

Someone who ties themselves to that level of detail thinking and keeps their expertise current (nearly a full time job in itself, these days!) can never develop truly great chops at product vision/conception, design, and the ability to build and inspire those teams to think in a way that leads to "insanely great" products. They are very different skillsets - there's a difference between a coder and a developer, and a developer and a product visionary and tech team inspirer.

BTW, as a 6-12 time (depending on how you count) CTO myself (including two venture backed with acquisition exits), coding interviews are a complete WOMBAT: Waste Of Money, Brains, And Time. I care about HOW you think about the problem and its relationship to the real world, since THAT is what makes simple, fast, "just works" software that people love to use.

My last CTO of a 70 person company was in his 50s and while he did everything that I would expect a CTO to do - manage vendor relationships, deal with pre-sales when trying to get new customers (B2B), and define a vision, there were a number of times he would throw together a quick non production ready piece of code in Python or C# to prove out a concept and share it with me in Dropbox to make it production ready. I greatly appreciated it. That was part of his role with strategy. He understood technology well, played with Docker on the weekend and analyzed data using Athena (serverless AWS Apache Presto).

But I knew when I spoke to him about a proposal, I needed to start off speaking non technical and talk about business value and business impact (when I got to technical he would say he “doesn’t have time to listen that shit” - we had a very good working relationship and we didn’t waste time with niceties when we were trying to get a point across to each other. When he had time though, we would need out.

On the other hand, the CTO I had before that hadn’t been hands on technical at all for over a decade. When I spoke to him, I spoke only in terms of the business value and the holy Trinity (on time, on budget, meets requirements).

In both cases, they hired me so they wouldn’t have to deal with those details and it was my responsibility to explain trade offs.

a couple of weeks back, i had the pleasure of meeting and giving a presentation to mark russinovich, the current cto of azure.

let me tell you, he's the CTO's CTO. all the C level skills, and his technical chops are legitimate and well documented. i was very impressed. :)

There is also a lot of nuance to 'technical'. I've seen people with over a dozen years of technical experience in field A become CTOs of a company in field B and just kind assume that things work basically the same since tech is tech. This rarely works out well. So beyond just being 'technical' in some generic sense it is important to understand domain and culture you are asked to be 'technical' in.

This post has good points, but it confuses the roles of CTO and VP Engineering. These are two different things, at least in some large organizations.

As an example, I was CTO at VMware (for their public cloud group, vCloud Air). My tech background and experience was very generalist, and I only managed small groups of developers for just a few years. I wouldn't call myself very technical, compared to someone with deep knowledge and experience in developing a product and managing a large group of developers.

As a CTO, I was mostly a bridge between clients and product. I needed my technical skills, but I also needed to understand how to nurture that relationship.

The various VP of Engineering at VMware were amazingly technical. They knew how to navigate the "politics" of the company (which was a bit over-organized and a bit dysfunctional, because of acquisitions, change of strategy, etc), but they mostly knew how to run a large team.

Interestingly enough, even some GM (General Managers) or specific business units could be highly technical, and it gave them a huge advantage in managing their CTO and the rest of their team (e.g. Martin Casado, brought in after the Nicira acquistion).

IMO CTOs must have a broad knowledge of how things are done in all the fields, eg. web, mobile, backend, devops, nowadays ML etc. That way they can take more sane high-level and long term technological decisions. Otherwise you end up with a cto asking you to move everything on microservices for your 1k users app because he/she heard of a friend's company using them (based on a true story)

The way I think about this that there’s three meta levels in organizations:

The team that builds the product (devs, senior devs, lead devs). Build here usually means code, design, ops.

The team that builds the team that builds the products (engineering managers, principals, staff, directors of X, maybe VP of X). Build here usually means building up people (hiring, firing and training) and making technical decisions with an intent to educate and influence.

Then there’s the team that builds the team that builds that builds the product. These are the CxOs, including CTO. The requisite skill here is engineering the organisation itself, not necessarily a fleet of services or APIs. This skill can benefit greatly from an engineering background (or just playing Factorio), but it’s broad enough that you also need to get into people management, psychology, marketing, selling (internally), consensus building etc. But it not directly related to code.

Being a CTO means you are constantly switching hats. At the core you are defining the technical direction and strategy of a company. This obviously needs to be business aligned; so a lot of CTOs are all over that as well. And it touches on product as well. So a lot of CTOs are also head of product. And in smaller startups, anything vaguely technical is the CTOs job; as well as anything else that needs doing. I currently do this.

In some companies the CTO role is more important than others. If you are a tech startup, the CTO is likely a founder if not the main founder. However, there are also a lot of non-technical companies where the strategy is simply to build tech stuff as cheap and efficiently as possible while not getting in the way of the founders who tend to be non technical types running a company where tech is just a means to an end rather than core to what they do. Just because you have an app or a website does not mean you need a CTO. You might just outsource that to an agency even.

I've seen this a lot in the Berlin scene where a non technical founder team starts looking for a non founding CTO to build their thing and they end up with some engineer getting the label slapped on them. My advice to companies like that is that they should be looking for a VP of engineering instead and not slap CTO role on the relatively inexperienced early engineers they'll manage to attract to their company. More often than not this ends in tears; especially when equity is involved.

Often the roles of VP of Engineering and CTO are confused. They can be separate roles. Not all CTOs are good at managing large teams. And some engineering managers know a thing or two about tech. However, a VP of Engineering can be very hands off when it comes to tech. Building stuff is not their function. Managing the people that do is.

Lots of scale ups need one and the role is about nurturing and growing the tech team, not necessarily about having a lot of opinions on what the tech should be (other than be boring, low risk, predictable type stuff). Another difference is that a VP of engineering is not a C level executive and also not a founder. They are there to grow the business and make sure the tech team delivers whatever product needs delivering and that the right people are in place to make that happen. IMHO VP of Engineering is closer to and HR role than a tech role actually. You wouldn't expect them to write a single line of code. Lots of companies end up having both roles. Especially those with founding CTOs that turn out to not be ideal at managing their tech team.

Good luck fixing that bug you don't have as much context on as an engineer who is familiar with that part of the code, while mentally preparing for the investor presentation on the same day.

Having seen dozens of code bases, products, and failed startups, the number one trait a good VPE or CTO should have is to vehemently prevent over engineering and accidental complexity - via coaching the tech leads, doing design reviews as needed, and making decisions and tradeoffs.

She should have strong opinions on how code should be organized for simplicity, but she should not code. If she can enforce good naming conventions and APIs, she is gold.

The CTO should be able to liaise with employees, customers, and upper core management.

While some technical understanding is needed to contextualize operational costs, it is hardly a primary skill requirement.

Some may find it convenient to overburden employees with 6 roles in a small firm, it is often not a wise decision. Ignoring burnout factors, a company could end up with a very cool looking toy infrastructure, that essentially misses the subtle long-term stakeholder requirements.

Also, who hires an external employee for a CTO role… that sounds insanely risky. =)

https://www.youtube.com/watch?v=0D7hFHfLEyk

That would be a Chief Liaise Officer.

You obliviously haven't met a CTO at an 8000 user facility.

Damage control is the primary Role... whether you want the task or not.

Most lack the discipline to tolerate that level of verbal abuse. ;)

I try not to do anything obliviously.

I'd probably hire you, as being lazy means you have likely automated most tasks already. ;)

My company has opted not to have a CTO and instead have a CPO (Chief Product Officer) and the VP of Software is one of their reports. Honestly, I think it kinda makes sense. You're products are your products, not your tech stack.

Fundamentally believe every technical person should read "The Idea Factory" on the origins of Bell Labs, and what technical leadership looked like in an organisation that had an outsized effect on our world.

I approach my CTO role just how I approach writing code: How to make myself redundant. Initially this is a lot of work and handholding, but it's worth the effort when you have a mature team.

Product managers at software companies should be technical too. Fight me

I knew a guy who was a sales executive. He managed to bluff is way into getting hired as CTO, even though he was not technical. Figured he could just bone up on stuff as he went along.

I checked in on him maybe 6-9 months later. CTO no longer mentioned anywhere on his LinkedIn.

A CTO shouldn't necessarily be super technical, but they should understand technology in ways that maybe a regional sales director wouldn't. And don't get me wrong, he was a smart guy in his own way, but just not as smart as he was dead sure that he was.

Forgive me, but almost always "X should be Y" is not ideal.

X should be great at X. All other things matter less. Now if you figured out what X needs to do, that's only half of it. You also have to excel at it.

I don't buy some of the specific examples in the post. Passing/excelling at coding interviews? Come on. That's not what CTOs are for. I wouldn't want my CTO to waste time on these things, because if they did, they're not pulling their weight at the things they should do.

CTOs should absolutely be technical, be able to solve problems, be able to code, and participate as necessary. In addition, CTOs need to do "C suite stuff", which is nearly all non-technical skills: planning, budgeting, communicating, continuous re-estimating, conducting personal meetings to develop relationships, reviews, resolving conflict between employees, selling the mission of the company, selling the mission of the department, and a whole host of other leadership skills.

Should a CTO at a software company know HOW to code? Probably. Should they be writing code on a regular basis? Probably not, unless it's a small startup.

Exactly what I had in mind. This is an attitude that sees workers as mindless automatons whose sole purpose is to keep themselves busy. a terrible management approach. The advice that it is acceptable to be despised only deepens the ditch. When things aren't going well, your staff members may be able to tell, and bald-faced lies like this will hasten their departure.

Putt's law:

Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.

https://github.com/dwmkerr/hacker-laws#putts-law

The underlying reason for Putt's law is the finite space of the human cranium and finite hours in the day.

That makes sense. Coding is an excellent way to train problem solving skills.

Even if you consider intellectually demanding fields such as mathematics and physics; although they do train your critical thinking skills, they don't teach you how to be pragmatic. Software engineering can help you to develop a pragmatic 'most efficient path to meet the goal' mindset.

Toppers in hackerrank, leetcode created any products that is used by millions? Coding test or any test in that matter can't be used to measure a person intelligence. Because we are yet to understand & define what is intelligence?. To be successful in any job, you need a passion in it, working with people & audacity to bring in change.

As others have mentioned and I agree as a company becomes bigger the job of a CTO goes from very technical (owning the project, making architectural decisions ) at startups to a really large company where the CTO has the large product(s) owner(s) reporting to them with their own cost and benefits analysis and from that justifying the capital expenses to the CEO.

"Chief"(C) of any company deals with people and planning not the direct expertise for that area of the company. A Chief Marketing Officer does not have to be a master in advertisement but the person needs to be a master at dealing with people, get the information needed to make a decision and make a decision. The person also needs to develop a strategy to execute on the CEO's vision. You can say the same thing about the CTO. The last thing you want is an expert Techie in that role. The Chief needs to put the right people in place and trust them to do their job. If the team is not working then the Chief needs to figure out why. The Chief needs to have a director and senior managers that will have expertise to do the work.

A small company needs an expert tech but that role is really a director or senior manager that gets the title as CTO as an ego boost when in reality it is the role of a senior manager or a director.

If your company is small a CTO title is a misnomer. It's important to point out that a CTO's role will change depending on the company's size.

Should a conductor know how to play instruments? Of course not, but it's imperative they know physical realities of playing each one. That's a key component of understanding where the orchestra is at and where you can take it. Is that technical? I'd argue it is.

> Should a conductor know how to play instruments? Of course not, but

I was very surprised to read that someone would think this, so I thought I'd check whether it's true. Here are some recentish famous conductors selected from https://en.wikipedia.org/wiki/Conducting; though I didn't make an effort to select very randomly, this ought to include most of the most famous conductors:

- Herbert von Karajan: child prodigy at the piano, continued studying piano into his 20s, no notes on whether he continued playing in later life or took up more instruments

- Marin Alsop: studied violin at Juillard, played violin in the New York Philharmonic and the New York City Ballet, no word on whether she still plays today

- Simone Young: studied piano at the Sydney Conservatorium, played piano as a répétiteuse at Opera Australia, no word on whether she still plays today

- Alondra de la Parra: began studying piano at 7 and the cello at 13, studied piano (and conducting) at the Manhattan School of Music, received BM in piano, no word on whether she still plays today

- Seiji Ozawa: began studying piano at 9, studied piano at the Toho Gakuen School of Music under Saito until he broke his fingers and couldn't play anymore, consequently switching to conducting, no word on whether he's taken up other instruments today

- Myung-whun Chung: won "joint second-prize in the 1974 International Tchaikovsky Competition" as a pianist, still famous as a pianist today as well as a conductor

- Henry Jay Lewis: child prodigy on various instruments starting at 5, famous as a double-bassist as well as a conductor, "first African-American instrumentalist in a major symphony orchestra" as a double-bassist

- Charles Dean Dixon: no information about whether he knew how to play any instruments. However, the New York Public Library summary of the Dean Dixon papers https://archives.nypl.org/scm/21001 says, "Dixon began studying violin at the age of 1 or 2, and played most of the instruments that comprise an orchestra."

- James DePreist: played percussion in a jazz quintet, was sponsored by the State Department at age 36 to tour "the Near and the Far East with DePreist lecturing and performing jazz," when he got his first chance to conduct an orchestra, in Bangkok. Contracted polio on the tour. Published two books of poetry. No word on whether he continued to play instruments for the rest of his life.

- Paul Douglas Freeman: no word in Wikipedia on his instrument-playing abilities, but https://www.chicagosinfonietta.org/wp-content/uploads/Paul-F... says, 'Music lessons were also a required routine when the Freeman siblings grew old enough to

handle them; Freeman started piano lessons at age five, and he soon took up the clarinet as

well. He took clarinet lessons at Richmond's Armstrong High School while still in elementary

school and took lessons at Virginia State College in Petersburg while in high school. His

conducting debut came at age 14 or 15, when his clarinet teacher fell ill and was unable to

conduct the Armstrong school band for its scheduled performance at a PTA meeting. Freeman

stepped in as a substitute. "Although the ministry was an earlier career interest, a maestro was

born that evening," Freeman wrote in a letter quoted in the book Black Conductors.

Freeman soon added the cello to his instrumental arsenal, and his teachers started urging him

to consider a career in music.' And https://www.thehistorymakers.org/biography/paul-douglas-free... says, 'Freeman attended the Eastman School of Music, where he earned his B.A., M.A. and Ph.D. degrees, with his principal instruments being the clarinet and the cello,' explaining that his conducting career began after that.

- Michael DeVard Morgan: began playing piano at age 8, was conducting two orchestras by age 12; performed chamber music on piano in the "Chamber Music Alive" series in Sacramento, California.

- Arthur Nikisch, "one of the founders of modern conducting": studied at the Vienna Conservatory, winning prizes for "composition and performance on violin and piano". Worked as a violinist in the Vienna Philharmonic.

- Fritz Reiner: studied piano under Bela Bartok, no word on whether he continued playing in later life or took up other instruments.

- Arturo Toscanini: studied the cello on a scholarship at the local conservatory, toured South America in the orchestra of an opera company and had his first conducting experience when the players went on strike against the previous conductor; continued playing cello, including in the world premiere of a Verdi opera, until "Toscanini's reputation as an operatic conductor of unusual authority and skill supplanted his cello career".

- Wilhelm Furtwängler: no word in the Wikipedia article about his talents as an instrumentalist, but https://www.gramophone.co.uk/features/article/wilhelm-furtwa... says he was "also a very capable pianist", http://patangel.free.fr/furt/bio_en.htm says he started studying piano at 7 and played piano in the Lübeck orchestra and the Vienna Philharmonic (in which case he was also conducting). http://www.scena.org/lsm/sm3-5/sm3-5furtwangler.htm says his piano studies began at 4.

- Leopold Stokowski: sang in the choir, elected to membership in the Royal College of Organists at age 16, "appointed the organist and choir director of St. James's Church" at age 20, then "began work in New York City as the organist and choir director of St. Bartholomew's Church", and did not begin conducting until age 27. No word on whether he played instruments in later life (presumably he did not have his own pipe organ.)

- Otto Klemperer: no word in the Wikipedia article on playing instruments, but https://www.encyclopedia.com/people/literature-and-arts/musi... and the more-reliable-appearing https://www.bach-cantatas.com/Bio/Klemperer-Otto.htm say he studied piano at the Hochschule fuer Musik in Frankfurt and in Berlin. http://web.archive.org/web/20090502025309/http://www.klemper... says, "The teen-aged Klemperer soon established himself as a pianist of note, performing Beethoven's Sonata in D major in a conservatory concert and serving as accompanist to the celebrated baritone Julius Stockhausen," and explains the move to Berlin by explaining that he was following his piano teacher James Kwast, who had moved to the Klindworth-Scharwenka Conservatory and then the Stern Conservatory, and that Mahler recommended him as an "outstanding musician" on the strength of his piano performances as well as his conducting. No word on whether he continued playing piano in later life.

- Leonard Bernstein: taught himself piano at age 10, played piano at the New England Conservatory and the Boston Public School Orchestra, accompanist for the Harvard Glee Club, studied piano at the Curtis Institute of Music, played jazz piano at the Village Vanguard, noted as an adult as a pianist, surprised Aaron Copland by playing Copland's Piano Variations at his birthday party, "often conducted piano concertos from the keyboard".

So, after looking long and hard, reading through the biographies of 18 different famous conductors, I was unable to find even one great conductor who didn't know how to play instruments. Most of them were in fact very talented instrumentalists; a few were world-famous as instrumentalists. Most of them dedicated many years of their lives to learning to play instruments. The only one I could find that didn't have a paid music career playing instruments, as well as conducting, was Seiji Ozawa, and that was because his piano career was cut short by a crippling hand injury. (And I wouldn't be surprised to learn that Ozawa played horn or something in his spare time, even if he didn't perform publicly.)

Maybe I worded wrongly, or you've misread or probably both. Conductor knowing how to play instruments (plural and all of them in the orchestra), and well at that, is not happening. An instrument - yes, as often is the case with music, at least to a certain level. What's more important, which was the point, is to understand realities of playing each one in order to understand what, how, and where to take the orchestra. Not ever playing even a single one would probably render the effort impossible at the highest level.

Apparently in every single case they played at least one instrument at a world-class level, and in at least one case they were said to play "most of the instruments that comprise an orchestra", though presumably not at a world-class level. Hanging out with musicians leads me to believe that probably nearly all these conductors could play most of the instruments in the orchestra at a basic level, because it's totally normal for musicians to play around on instruments they don't specialize in, and there's a lot of skill transfer.

Evidently conductors who founded orchestras without having world-class skill in playing at least one instrument did not achieve the level of excellence of the ones in my list above, and the folks who select conductors to conduct existing orchestras evidently consistently select conductors with world-class skill in playing at least one instrument. Perhaps, as you seem to be saying, they are wrong to do so, and a basic level of skill in one along with understanding the realities of playing each one would be sufficient. Conceivably it's an outdated or simply incorrect prejudice, similar to how almost no women were selected as conductors or even orchestra instrumentalists. But that doesn't seem like the way to bet.

That does make me think now is it an actual pre-requisite to be a conductor at a high level or just the way things have been. We seem not have much/any counter examples?

It's hard to know, but surely some rich or politically powerful music fans have attempted founding an orchestra with themselves as the conductor. None of them seem to have become famous — but that could "just" be a matter of the musicians' prejudices.

Agreed.

It's a little like an orchestra conductor. They don't (usually) play an instrument on stage, but they certainly can, and they have a deep understanding of each instrument in the orchestra, its function, potential and how it is operated (so te speak), and of the score itself.

Actually, the way I see it, the orchestra conductor would be the COO (if it were a C-level job at all).

The CTO would not be involved at all in the daily performance of concerts; the CTO would be the one setting standards for the instruments and their maintenance, auditing and overseeing the acoustic treatment of the concert hall, and advising the CEO on new upcoming instruments that might make a great addition to the orchestra.

I’ve seen hundreds of millions in funding go down the drain in companies with daring requirements versus lack of technical creativity. In all cases the CTO, if there was one, was not technical and commanded no respect from the engineers.

Keep blowing this horn. At the end of the day your manager and theirs all the way up to the CTO will still have no clue about the engineering side and you are going to have to make up the difference. It's the sad world we live in.

Eh, much like CEO, this is strongly dependent on what kind of org you are. It's roughly the Jobs/Cook paradigm, and "Cooks" don't really need to be technical at all.

It’s a leadership role, leave the technical details to the principal/staff engineer. Concentrate on purely people related items. You’re a leader, time to put away the code and grow up.

I'll say it depends on the company's business and objectives.

A CTO of a tech company needs to be super technical.

For example in Vercel, even CEO is a technical person.

NEVER work for someone who is incapable of doing your job. To do so is to construct an extremely dangerous, brittle situation.

This doesn't mean they SHOULD do your job, or HAVE to - just that, they could - and are therefore qualified to manage you - while you do it.

The Peter Principle is real, and legitimately a source of massive waste and inefficiency in the world. Simply refuse to work for someone that cannot do what you are expected to do - and you will be building a better organizational framework.

The corollary is interesting: don't try to manage someone if you can't actually do their job, either.

The Peter Principle is explicitly about the risks of someone being promoted into a role they can’t do because they were good at a role they could do.

People should be made people leads because they are good people leads, not because they are good ICs.

The Peter Principle equally applies to those who have to serve under others who were promoted out of their competence zone. It works in multiple ways: don't allow yourself to be promoted outside of your competence zone, don't work for those who have been.

>People should be made people leads because they are good people leads, not because they are good ICs.

Good people leads don't lead people whose jobs they can't do. That's the point: if your boss can't do what you do, he's not leading - he's letting you lead, while following along on an elevated, speciously constructed platform.

Don't fall for it - always demand competence from your own leadership.

> Good people leads don't lead people whose jobs they can't do.

That just doesn't work. I don't need to know how you achieved something to know I want it done. Unless you expect every people lead to have all the skills of all their reports, so each level becomes exponentially more impossible to achieve.

That's why he is chief technical officer. why is there debate on it?

Is there anyone who disagrees with the headline "A CTO should be technical"? I don't think so.

You cannot have your cake and eat it too. To remain exceptionally technical, you need to remain an Engineer. My2c

I had written about it a few months back. https://blog.tarkalabs.com/what-does-a-cto-do-67c26d34ae7a

As I see it, CTOs are responsible for

- Making Build/Buy decisions

- Hiring

- Setting up a culture of learning

- Balancing tech and product priorities

- Setting up delivery processes that work for the team

- And finally for architecture and system design

I feel in that order of priority.

I would argue for the same for a CSO (chief security officer).

Different problems at different altitudes.

What a novel fucking concept

The CTO doesnt have to be technical. But they have to have a technical council that folks can go to to hash things out with.

Ideally the CTO or council shouldnt even have to make the decisions most of the time. But every company should have intensive hard debates, struggles, long and hard, about what technically to build and how. Most companies take a hands off approach, and leave folks to hash it out among themselves & figure out in structureless ways what to do. This rarely results in real feedback, in better options being picked; the tyranny of structureless happens, grows amid the absence of there being considered seasoned wise people about who can ask sharp insightful pointed questions at everyone, who can make plainer what the tradeoffs & real costs really will be.

Without sharp technical competency high up in the chain, discussions turn into a formulaic sad debate: the people who dont tech argue for lower estimates (or when they dont like hearing about hard work they force a change in direction), the knowledge workers get sadder and sadder that no one can see what the problems & situation really is or that there is no one around to fave & tackle the obvious/real challenges.

A technical executive team can argue with team the opposite: your plans arent comprehensive enough. You arent accounting for enough cases, seeing enough of the problems. Your scope isnt ambitous enough. The tools & libraries you are picking will have issues here & there that you havent seen.

Very few corps seem able to understand their own hierarchical ignorance & stupidity. They trust in their chain of command as people leaders, with ultimately teams in charge of making good decisions. I tell you: this is not enough. Teams want buy in in a real sense from above. They want senior staff who understand in a real way & can provide some real guidance & advice. Few companies have this at all.

Earlier today there was a 2011 piece on Jobs (a man I'm mixed on, but) his advice on saying no, on cutting out cruft[1], is something that is at least as much technical as it is product. And few orgs know how to keep & retain technical talent, technical council, that isnt people managers, but tech managers. Those companies that can actually take ownership of their product from the top, that know what they are really doing, have a much greater potential to cut the cruft, to steer toward better. Few do.

Technical know-how doesnt have to be the CTO's role, but it really should be a function high up in the org that is visible, respected, & active. Too many orgs are technical only at the bottom, and there need to be more active chains of understanding & respect within an org than that for real positive growth to happen. This is, for sure, one of the hardest least addressed issues in tech, & a key to doing better. But tech is often left out of the room, & closing the gap is hard.

[1] https://www.forbes.com/sites/carminegallo/2011/05/16/steve-j... https://news.ycombinator.com/item?id=32985952 (2 points, 9 hr ago, 4 comments)

Let's build abcd)))) in la

What does the T in CTO stand for?

Terminator…or technical.

technology

author doesn't understand management at all, nor silicon valley / tech company org structure model. ok sure, in a top down company, CTO better be uber technical.

remind me not to apply to any SPC companies, nor use their products

The author was CTO at Dropbox and was a pretty senior leader at Facebook.

(disclaimer: I know him personally and his credentials aside, think he's extremely knowledgeable about engineering leadership and company building in general)

No. Or at least, not always.

IMO,a CTO is a combo between tech and product. They have a (fairly) good understanding of tech but they understand that tech is there to support the product. I'm ok with a tech CTO and I'm also ok with a people-CTO, even a product-CTO or even (ok, hardly) a business-CTO, but let's not gate-keep the CTO role (and it's just a role!).

ps. yes, I know CTO means Chief Technical Officer - but if you really think about it, tech is there to support the product, so it's really un-productive to focus on the tech when it would be better to focus on the product.

ps2. let's stop with the very <b>confident</b> titles, IMO most of the time they're simply wrong (I'll dig in my history for more examples)

The issue is that if you're not technical CTO in a tech company, that is you can replace a senior engineer[1], then absolutely no one will respect you.

The CTO absolutely must be technical, not just because of respect, but also because other C-level execs need someone to explain simple things to them. If not, then you end up like Intel.

[1]: not as in be CTO and do a workload of senior engineer, but rather "if you weren't a CTO, would you be hired as a senior?"

Reply on news.ycombinator.com