23 ms·

A CTO should be technical

• daemon_9009 4y ago
  That's why he is chief technical officer. why is there debate on it?
• dovholuknf 4y ago
  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.
  • spoonjim 4y ago
    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.
    • dovholuknf 4y ago
      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
      • nicoburns 4y ago
        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.
      • spoonjim 4y ago
        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.
• SkipperCat 4y ago
  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.
  • spaetzleesser 4y ago
    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.
    • SkipperCat 4y ago
      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.
    • beachy 4y ago
      > 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!".
      • scarface74 4y ago
• k__ 4y ago
  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.
  • JohnBooty 4y ago
    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.
• jiveturkey 4y ago
  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
  • Ozzie_osman 4y ago
    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)
• zitterbewegung 4y ago
  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.
• cgrealy 4y ago
  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.
  • ianbutler 4y ago
    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.
    • cgrealy 4y ago
      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.
  • valenterry 4y ago
    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.
  • innocentoldguy 4y ago
    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.
  • nicoburns 4y ago
• indymike 4y ago
  "I'm not a tech person." are five words you never want to hear from someone with "technical" in their title.
• nso95 4y ago
  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.
• syncerr 4y ago
  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/ https://www.linkedin.com/in/adityaagarwal3/
• incomplete 4y ago
  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. :)
• system16 4y ago
  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.
  • mchusma 4y ago
    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.
    • ForHackernews 4y ago
      Dropbox also completely lost the market they invented to Box, largely because of nontechnical considerations.
      • scarface74 4y ago
        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.
• dijit 4y ago
  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.
  • brightball 4y ago
    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.
  • vasco 4y ago
    > but I fear what will replace me if I leave So you'll never retire or die?
    • dijit 4y ago
      I’m not very old, healthy enough and if I die then there’s not much more I can do, can I?
• robertlagrant 4y ago
  The way I've heard it phrased is the CTO should be able to code, but the CTO shouldn't code.
  • nautilus12 4y ago
    This is idiotic. Practically nonsense
    • robertlagrant 4y ago
      Care to explain yourself? Or just having a bad day? : - )
• whalesalad 4y ago
  What does the T in CTO stand for?
  • jtaft 4y ago
    Terminator…or technical.
    • 0x457 4y ago
      technology
• exabrial 4y ago
  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.
• posharma 4y ago
  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.
• walrus01 4y ago
  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.
• wpietri 4y ago
  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.
  • vasco 4y ago
    What do you mean, the way to get quality isn't to frown while you say "more quality"?
    • wpietri 4y ago
      Of course not! You also have to mutter, "but hurry up" whenever people do something that might actually improve quality.
    • thfuran 4y ago
      No, no, no. That gives entirely the wrong association. You have to smile while saying "more quality".
  • PragmaticPulp 4y ago
    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.
    • wpietri 4y ago
      I believe you don't see the problem. How can I help you see it?
  • 4y ago
• savrajsingh 4y ago
  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.
• scarface74 4y ago
  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.
• MikeYasnev007 4y ago
• MikeYasnev007 4y ago
  Let's build abcd)))) in la
• nickelcitymario 4y ago
  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.
  • spopejoy 4y ago
    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.
    • nickelcitymario 4y ago
      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.
• deleted 4y ago
  [deleted]
  • xfychconduct 4y ago
• FpUser 4y ago
  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.
• yowlingcat 4y ago
  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_cto_roles.html 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."
  • topspin 4y ago
    > 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.
• sponaugle 4y ago
  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. )
  • kragen 4y ago
    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?
    • sponaugle 4y ago
      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!
• nautilus12 4y ago
  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.
• baby 4y ago
  I would argue for the same for a CSO (chief security officer).
• RajT88 4y ago
  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.
• chpmrc 4y ago
  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).
  • muglug 4y ago
    > 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.
  • IntFee588 4y ago
    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.
• Keyframe 4y ago
  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.
  • kragen 4y ago
    > 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 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 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-Freeman-Bio.pdf 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-freeman 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-furtwangler-the-man-and-myth 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 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 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/music-history-composers-and-performers-biographies/otto-klemperer https://www.encyclopedia.com/people/literature-and-arts/musi... and the more-reliable-appearing https://www.bach-cantatas.com/Bio/Klemperer-Otto.htm 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.klemperer.org/EarlyYears.htm 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.)
• bbojan 4y ago
  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.
• tagyro 4y ago
  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)
  • 0x457 4y ago
    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?"
• notacop31337 4y ago
  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.
• jillesvangurp 4y ago
  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.
• Joel_Mckay 4y ago
  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 https://www.youtube.com/watch?v=0D7hFHfLEyk
  • dqpb 4y ago
    That would be a Chief Liaise Officer.
    • Joel_Mckay 4y ago
      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. ;)
      • dqpb 4y ago
        I try not to do anything obliviously.
        • Joel_Mckay 4y ago
          I'd probably hire you, as being lazy means you have likely automated most tasks already. ;)
• fsckboy 4y ago
  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)
• insane_dreamer 4y ago
  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.
  • tremon 4y ago
    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.
• deleted 4y ago
  [deleted]
• fzliu 4y ago
  I'm going to put this out on a limb - CEOs should also be technical.
  • ceocoder 4y ago
    I agree with that
• codingdave 4y ago
  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.
  • dasil003 4y ago
    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.
  • mruniverse 4y ago
    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?
    • codingdave 4y ago
      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.
• hizxy 4y ago
  Different problems at different altitudes.
• lisperforlife 4y ago
  I had written about it a few months back. https://blog.tarkalabs.com/what-does-a-cto-do-67c26d34ae7a 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.
• muxneo 4y ago
  You cannot have your cake and eat it too. To remain exceptionally technical, you need to remain an Engineer. My2c
• bergenty 4y ago
  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.
• tootie 4y ago
  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.
• WheelsAtLarge 4y ago
  "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.
• yshrestha 4y ago
  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 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.
• mbesto 4y ago
  > 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.
  • koffiezet 4y ago
    > 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.
  • dqpb 4y ago
    I wouldn't respect a CTO who couldn't pass a technical coding interview.
    • bradlys 4y ago
      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).
  • dqpb 4y ago
    If the CTO isn't a technical domain expert then they are just middle management overhead.
    • 4y ago
• westoque 4y ago
  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.
  • jschveibinz 4y ago
    Good comment.
    • westoque 4y ago
      Thank you :)
• rektide 4y ago
  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-jobs-get-rid-of-the-crappy-stuff/ https://www.forbes.com/sites/carminegallo/2011/05/16/steve-j... https://news.ycombinator.com/item?id=32985952 https://news.ycombinator.com/item?id=32985952 (2 points, 9 hr ago, 4 comments)
• wiradikusuma 4y ago
  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.
• saos 4y ago
  Product managers at software companies should be technical too. Fight me
• ArcMex 4y ago
  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.
  • dagw 4y ago
    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.
• amir734jj 4y ago
  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.
• deleted 4y ago
  [deleted]
• firechickenbird 4y ago
  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)
• dagw 4y ago
  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.
• arnvald 4y ago
  > 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.
  • tinco 4y ago
    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?
    • jon-wood 4y ago
      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.
      • mianos 4y ago
        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.
• jwr 4y ago
  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.
• simonebrunozzi 4y ago
  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).
• boffinAudio 4y ago
  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.
  • cgrealy 4y ago
    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.
    • boffinAudio 4y ago
      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.
      • cgrealy 4y ago
        > 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.
• Tepix 4y ago
  Is there anyone who disagrees with the headline "A CTO should be technical"? I don't think so.
• helsinkiandrew 4y ago
  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.
  • ravenstine 4y ago
    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"
• LASR 4y ago
  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.
• myspeed 4y ago
  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.
• 19h 4y ago
  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.
• fareesh 4y ago
  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".
  • ttymck 4y ago
    > 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.
• quattrofan 4y ago
• devopsexpert 4y ago
  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.
• jrm4 4y ago
  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.
• jongjong 4y ago
  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.
• sudhirj 4y ago
  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.
• web99 4y ago
  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.
• dublin 4y ago
  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.
• pnemonic 4y ago
  What a novel fucking concept
• rsrsrs86 4y ago
  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.
• meotimdihia 4y ago
  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.