[HN Gopher] CTO Should Be Technical
___________________________________________________________________
CTO Should Be Technical
Author : catapultis
Score : 166 points
Date : 2022-09-26 19:19 UTC (3 hours ago)
(HTM) web link (blog.southparkcommons.com)
(TXT) w3m dump (blog.southparkcommons.com)
| dijit wrote:
| 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.
| vasco wrote:
| > but I fear what will replace me if I leave
|
| So you'll never retire or die?
| pvorb wrote:
| 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.
| dijit wrote:
| I'm not very old, healthy enough and if I die then there's
| not much more I can do, can I?
| wpietri wrote:
| > 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...
| baby wrote:
| 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.
| CallMeJim wrote:
| This reads like a LinkedIn post.
| spit2wind wrote:
| 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.
| givemeethekeys wrote:
| 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.
| colechristensen wrote:
| 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.
| citizenpaul wrote:
| 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.
| capableweb wrote:
| > 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".
| citizenpaul wrote:
| >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.
| Nuzzerino wrote:
| In real life, some people are human lie detectors, or at
| least better at detecting lies than you are a liar.
| NegativeLatency wrote:
| > 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
| stormbrew wrote:
| > 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.
| citizenpaul wrote:
| 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.
| warent wrote:
| 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.
| warent wrote:
| > 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.
| random314 wrote:
| 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.
| citizenpaul wrote:
| >employees as mindless drones ... very toxic management
| style.
|
| I agree.
| baby wrote:
| > 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?
| citizenpaul wrote:
| 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.
| warent wrote:
| Curious to know where the statement "real life is not
| fair" is coming from / what it's referring to.
| citizenpaul wrote:
| > 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.
| rektide wrote:
| 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.
| pvorb wrote:
| > 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?
| citizenpaul wrote:
| 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.
| squeaky-clean wrote:
| 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.
| random314 wrote:
| > 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.
| citizenpaul wrote:
| Yes. FYI They will lie to you regardless.
| colechristensen wrote:
| >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.
| brightball wrote:
| 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.
| zerr wrote:
| 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.
| baby wrote:
| I would argue for the same for a CSO (chief security officer).
| fsckboy wrote:
| 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)
| RajT88 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| k__ wrote:
| 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 wrote:
| 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.
| robertlagrant wrote:
| The way I've heard it phrased is the CTO should be able to code,
| but the CTO shouldn't code.
| nautilus12 wrote:
| This is idiotic. Practically nonsense
| bbojan wrote:
| 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.
| [deleted]
| xfychconduct wrote:
| SkipperCat wrote:
| 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 wrote:
| 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 wrote:
| 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.
| abraae wrote:
| > 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 wrote:
| 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).
| abraae wrote:
| 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.
| PragmaticPulp wrote:
| > 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.
| jiveturkey wrote:
| 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 wrote:
| 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 wrote:
| 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.
| FpUser wrote:
| 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.
| syncerr wrote:
| 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/
| incomplete wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Dropbox also completely lost the market they invented to Box,
| largely because of nontechnical considerations.
| scarface74 wrote:
| 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.
| daveslash wrote:
| 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.
| roughfalls wrote:
| 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.
| pvorb wrote:
| > 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.
| scarface74 wrote:
| 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.
| pvorb wrote:
| 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.
| scarface74 wrote:
| 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.
| nordsieck wrote:
| > 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.
| walrus01 wrote:
| > 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.
| savrajsingh wrote:
| 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.
| cgrealy wrote:
| 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.
| innocentoldguy wrote:
| 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.
| icedchai wrote:
| 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.)
| nicoburns wrote:
| 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.
| ianbutler wrote:
| 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.
| valenterry wrote:
| 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.
| whalesalad wrote:
| What does the T in CTO stand for?
| tagyro wrote:
| 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)
| exabrial wrote:
| 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 wrote:
| 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.
| indymike wrote:
| "I'm not a tech person." are five words you never want to hear
| from someone with "technical" in their title.
| notacop31337 wrote:
| 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.
| Keyframe wrote:
| 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.
| scarface74 wrote:
| 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.
| yowlingcat wrote:
| 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."
| MikeYasnev007 wrote:
| sponaugle wrote:
| 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. )
| metadat wrote:
| ^ for context, sponaugle is CTO of Surescripts, LLC; a 500
| employee SMB.
|
| https://www.crunchbase.com/organization/surescripts
| walrus01 wrote:
| ^ 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.
| sponaugle wrote:
| 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.
| personjerry wrote:
| Why was it a mistake to introduce yourself as such?
| sponaugle wrote:
| 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!
| lisper wrote:
| 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.
| sponaugle wrote:
| 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.
| [deleted]
| sankumsek wrote:
| Usually CTO == Chief Technology Officer, not Chief Technical
| Officer. But an amusing slip of the tongue that kinda works
| out! :)
| kragen wrote:
| 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 wrote:
| 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!
| walrus01 wrote:
| 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.
| jillesvangurp wrote:
| 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.
| MikeYasnev007 wrote:
| Let's build abcd)))) in la
| wpietri wrote:
| 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.
| PragmaticPulp wrote:
| 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 wrote:
| I believe you don't see the problem. How can I help you see
| it?
| yowlingcat wrote:
| 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.
| vasco wrote:
| What do you mean, the way to get quality isn't to frown while
| you say "more quality"?
| wpietri wrote:
| Of course not! You also have to mutter, "but hurry up"
| whenever people do something that might actually improve
| quality.
| thfuran wrote:
| No, no, no. That gives entirely the wrong association. You
| have to _smile_ while saying "more quality".
| dovholuknf wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Joel_Mckay wrote:
| 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
| nso95 wrote:
| 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.
| nickelcitymario wrote:
| 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.
| nautilus12 wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-26 23:00 UTC)