There's a point when "technical enough" comes back into the picture. A gigantic company with 50k employees the CTO is barely relevant to any real tech decisions. They are tangentially related but not "in-the-weeds" technical
Contrast that to a tech startup, or any startup I suppose. Those CTO's absolutely need to be "in-the-weeds" capable.
I think it still matters because of hiring. The type of people rewarded with promotion at the top tend to promote those people and so on down the levels. A nontechnical CTO will start promoting nontechnical people managers and eventually you will have an org run by MBAs.
Yes for sure. But those non-technical, big company CTOs are going to be hiring people who need to be good at hiring people. Those are going to be your VPs of engineering types. THOSE people will be 'more technical' at that point. Those VPs of engineering are going to hire directors and so on down the chain. As you descend - it matters more and more that they are good technically. So if you're at a 50k size company, the CTO is so far from anything important that they operate at 'mba level with some technical acumen'. The smaller the company, the more important the role becomes.
Even at the company I worked at with 5000 people - the CTO was still nothing more than a glorified 'decider'. The company with 250 people - the CTO was far more necessary to be technical
I'd argue that the VPs, all the way up to the CTO need to almost as technical as the lower levels. Otherwise how are they supposed to accurately evaluate who to hire, and their performance once hired. They can go on end result metrics, but those are subject to confounding variables, and are not really accurate enough to make good decision on. It's really hard to tell the geniuses from the bullshitters if you're not able to get down into the details with them on occasion as needed.
I mean it depends on what kind of company it is. If software development is the company's core activity I think that this kind of setup is likely to fail slowly.
I'd say it's important for a CTO to be a CTO. I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones.
IMHO, too many people chase the CTO title but few really want the actual job.
I personally believe it's easier for a technical person to become reasonably competent at process, cost and other management stuff vs a management person to become reasonably competent at technical things. When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes. I definitely believe a CTO should be very strong technically and have a good bullshit detector.
100% agree. Any decent CTO will have tech in their roots, but if you're coding all day, you're missing out on what's truly important about the CTO role - building teams, assigning resources to problems and steering the company in the right technical direction.
> When I was contractor I saw terrible decisions made by CTO and CIO in several companies because they didn't have any technical taste and ran everything by numbers and processes.
So true. CTO being so far upstream, mistakes made here through disconnection between the rubber and the road have compound effects downstream. It's the sort of role where bad decisions have huge, company-ending ramifications.
"I talked to my buddy at [FAANG] and he said microservices are the way to go. His team achieved awesome velocity by switching to microservices. Let's do it guys!".
You realize that is the very edict that basically started at Amazon and came straight from Jeff Bezos in 2001? I think it worked out okay there (here).
I wasn't saying microservices are bad (personally I love them, maybe too much:). Just that making technology decisions based on someone's else's anecdotes, in the absence of any technical understanding, is a bad way to go.
Not quite. Jeff’s “edict” came via a lot of analysis, trial-and-error, and information gathering throughout the entire Amazon organization over the course of many years.
Amazon had huge dependency problem, both technical and organizational. Technically, the effort to work in their monolith scaled superlinear with respect to the CL size due to coordination and review with other teams. Organizationally, teams were dependent on an ever growing set of centralized, global processes that further slowed their ability to make progress.
Jeff (and S-team) saw these issues and worked to solve them through a series of experiments. Specifically, Jeff tasked his then CIO with finding a solution. This CIO worked throughout the organization to gather on-the-ground feedback around what was and wasn’t working; built a model for how Amazon _should_ work based upon that sense making; and then tested, iterated, and refined that model into what we’ve come to know as Single-Threaded Leaders and Two-Pizza teams, etc., today.
In parallel, a couple Amazon business units were experimenting with exposing their data via textual (XML) APIs like the Amazon Associates API which went on to become the Amazon Product Listings API. These early APIs were sort of the POCs that allowed Amazon to see early validation around the concept of web services.
Synthesizing all these different streams of information, ideas, and actions lead to Jeff’s “edict” around building standalone web services (which eventually led to what we know as AWS today).
In short, Jeff is the exact antithesis of GP’s straw CTO. He speaks from data, facts, and information gathered from a myriad of internal and external sources, not merely anecdotes of success from a CEO buddy. :)
Source: Working Backwards has a lot of information on Jeff (and Amazon’s) decision making.
While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
> I've been at too many places where the CTO only wanted to be a software developer/architect and would not focus on process, cost, employees, etc. CTO is a leadership role, and leadership means you have to take care of all the responsibilities under your authority, not just the interesting ones
A common pitfall among startups is to give the CTO title to whichever cofounder is leading the development when the team formalizes titles. Some times this person doesn't even have previous engineering manager (EM) experience at all, but as the most technically oriented person of the time they receive the CTO role by default.
Some times these people can grow into the necessary delegation, recruiting, hiring, performance review, people management, communication, and meeting skills necessary to be a CTO. Other times, they cling to what they know (coding) and turn into a micromanaging CTO who won't cede control of the things they want to do (code) while avoiding the things they have to do (managing).
This is one of many reasons why I advocate for avoiding C-level titles as long as possible at a startup. You can always promote someone up to CTO unceremoniously when the company actually needs defined C-level executives and they've been excelling at the role already, but it's much more problematic to ask someone to give up the CTO title and step aside to bring in an experienced CTO when necessary. Nobody likes being demoted, even if it's only a formality because they weren't actually doing the full management role. Any title demotion at startups is likely to lead to conflict and departures.
Having been a cto for decades I can agree; the things that are part of the job that are not technical, are the parts I find boring and don’t like. I am good at them by now, but I don’t like doing them. They are needed and indeed not many people who can do them actually like them.
Some CTOs who have seen their companies going from 10-1000 don't seem to grow up in their role. They don't learn delegation or trusting others with making decisions. They end up becoming a glorified architect instead of an actual leader. Meanwhile since no one takes the lead in setting up processes and keeping an ear to the ground on quality, velocity etc and things go bad quickly.
This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.
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.
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.
author doesn't understand management at all, nor silicon valley / tech company org structure model. ok sure, in a top down company, CTO better be uber technical.
remind me not to apply to any SPC companies, nor use their products
The author was CTO at Dropbox and was a pretty senior leader at Facebook.
(disclaimer: I know him personally and his credentials aside, think he's extremely knowledgeable about engineering leadership and company building in general)
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.
Being "technical" is a full time job. The idea that anyone "above" you should be able to do your job is not only ridiculous, it's insulting to the engineers.
The CTO should be able to have an informed and intelligent conversation about technical issues at a high level, but expecting them to be able to write code is not realistic.
I think I’d like to see CTOs have come from the frontlines and decided they had a larger interest in running the technical side of the business and then grow into it. Someone who once did the job and now is much higher level still to some degree knows how the sausage is made and can be a more effective leader imo.
Absolutely agree that a background in technology is important! I’m talking about the idea that someone who started as a dev many years ago is going to be able to write code in a current environment with the same level of skill as someone who does this everyday.
I agree. I think the author of the article would have done better if they had focused on their list of five important CTO skills rather than dragging coding skills into the narrative.
Amongst other necessary leadership skills, I do agree with the author that CTOs should be:
1. Good judges of quality.
2. Able to make good tradeoff decisions.
3. Able to earn respect.
4. Able to inspire teams to greatness.
5. Able to recruit top talent.
However, it isn't necessary for a CTO to be able to do everyone else's job to have these skills and be a great CTO.
The article doesn't say they should spend time writing code. It says they should be good enough to be employed by you to do so (if they weren't being employed as the CTO). It means that they ought to be ABLE to have an informed and intelligent conversation about technical issues at a LOW level if need be. They should't need to very often, and never to actually put code into production. But it's a vital skill for hiring and tie-breaking in case of conflict further down the hierarchy.
If your company is under 100 people and only a small percentage of them are engineers, the CTO better be able to code. (Whether they actually do or not is another matter, but they should understand the details, and with tech, that means code.)
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.
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.
Strongly disagree with the scope of this. Should a CTO be technical? Absolutely. Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming? Absolutely not.
As others have said, development is a full time job. It requires focused time and you need to remain current and have context for the state of the project. If a CTO is spending all of their time in the code, they are not doing the tasks of a CTO. If that doesn't matter and doesn't cause issues, you probably don't need a CTO.
I've worked at a company with a CTO who was an extremely talented developer but really that's all he wanted to do. He'd avoid meetings like the plague, never managed anyone despite have several senior direct reports, and would only really engage with others when technical issues came up where he could jump into the weeds in and help solve the problem. Essentially he had the title "CTO" but in reality all that meant was he was a superadmin developer who could work on whatever technical problem he wanted with nobody to report to.
Agree, also his example of the CTO was "Dropbox". Dropbox is/was basically only a "folder that syncs reliably". For that role, this is deeply technical low-level work and yeah, that CTO probably should be very technical.
The CTO (once the team is >10 or so) really only needs to be "as technical as needed to make smart decisions". This will vary a lot by company.
Imo that quote only ever made sense when you add "[compared to apple]" which was likely how he meant it. Also have you tried actually using gsuite storage?
Dropbox has about twice the revenue of Box. Box was founded a couple of years before Dropbox. However, both only have a small share of the value of consumer and commercial cloud storage at this point.
Yes. This. I agree with you and the parent comment.
I was "CTO" of my very small startup with < 10 people and 3 total engineers. I was extremely technical and hands-on in that role. I've worked at a mid-sized business that didn't even have a CTO, despite having 4 FTE software engineers and a network infrastructure team.
I now work for a globally distributed Fortune 500 company with nearly 100,000 employees working on hundreds of technical projects using all sorts of tech stacks and code from Embedded C to serverless SaaS offerings. The notion that my CTO should be able to "jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming" is absurd. It might be nice to have a CTO that's been in that role at some point, but no way should I expect them to be able to tomorrow.
> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming? Absolutely not.
The point was that a CTO should be able to do this in theory. Of course they won't ever actually do this unless there's no other way.
If your CTO can actually relate to the problems of their staff, they'll be able to make better decisions which also see more acceptance.
I’ve had two jobs where I reported directly to the CTO - the first as Dev lead with people management responsibilities and the second as the de facto “cloud architect” that was responsible for the “application modernization” initiatives.
My second CTO was very technical and up to date the first wasn’t. The only difference between the two day to day was with the second one, I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.
I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.
I'm wondering what the devs at both companies were thinking about their CTOs. My point wasn't that much about direct reports to the CTO, who might already be used to talking in management terms, but rather the developers who are directly affected by the CTO's decisions.
If the devs are reporting directly to the CTO, the CTO should be technical. If not, the CTO should delegate dev leadership to someone who is both technical and business oriented.
As my last company grew, the CTO just didn’t have the bandwidth to be technical at work and delegated different responsibilities to the people who could wear both the technical hat and had the soft skills needed. He would just dabble in things on the weekend. His entire family was technical. His wife was a lead data analyst for a telecom and his daughter got an internship as an SWE at BigTech.
> My second CTO was very technical an up to date the first wasn’t. The only difference between the two day to day was with the second one , I could use terms without defining them first. They both deferred to my technical judgement and I worked with the understanding of how to align my initiatives with the company’s.
> I work with CxOs all the time in consulting now. I have no problem getting my ideas through CxOs or architecture review boards.
Something to consider: there is probably not much difference between technical and non-technical when their reports are good.
But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.
> But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.
Very true. GP probably had good tech judgement which is why their technical CTO was following their judgement.
I had never logged into AWS when I was hired. I just had theoretical knowledge. In the land of the blind, the one eyed man is king, I’m amazed to this day that the CTO trusted me knowing that in advance. Don’t get me wrong, he didn’t blindly trust me. He pushed me harder than any other manager ever had to do things correctly and to think deeply and to write well reasoned documentation and presentations.
I told myself that there were only two positions at two companies that could have convinced me to leave. I got hired by one of those companies. He left less than a year later after the company was acquired for 10x revenue. He’s working somewhere else now. I would work for him again in a heartbeat if I were working anywhere else besides where I work now.
> whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.
I am genuinely wondering if I need some jiffy lube for flushing those fluids of mine.
It... sounds like... a thing... that people... do?
>But a technical CTO can stand up to reports that want to go down an obviously bad road, whereas a non-technical CTO would have as much defense as I would at jiffy lube when the tech asks me if I want my fluids flushed. It kind of sounds like a scam, but I really don't know.
The non-technical CTOs "defense" is having found which reports they can trust and support to make the correct tradeoffs. Then they do that. More broadly if your reports aren't competent or trusted enough to make the right decisions then find new reports.
The job of the CTO isn't to argue some stupid architectural point with people for hours. It's also not to blindly overrule them. Their job is to hire people that know more than them and can be trusted. Then it's to setup the processes within which those people can thrive.
In fact the problem with technical CTOs is that they can rely too much on their own technical knowledge versus fixing the damn organization. It's basically a bunch of band aids being put on a gushing wound.
You are right; you have to relate to the problems to value your people more I find. I used to jump into code as cto and I lost good people because of it as they felt it was lack of trust (it was I think but I did not realise that back then). When understanding how things work and giving the team the means to get it done by supporting them instead of trying to do their job is something I see go wrong in many cto’s, including my former self. I still like coding more than managing but I realise that there are other people so much better at the code part and I need to hire and guide them.
> Should they be able to jump into the code, start grabbing JIRA tickets on a moment's notice, or throw together a new feature when a deadline is looming?
In the roles they worked at immediately before becoming CTO they certainly should have had the technical capability and knowledge to do so, yes. Maybe not directly as CTO anymore but they need the grounding and experience to understand what the various tiers of engineers underneath them are grappling with.
"A manager actively avoids creating situations where their coding is necessary for the success of the project."
I agree with Aditya's article. A CTO must be technical for all the reasons stated. I would add another reason to his list: a CTO must be able to challenge the assumptions, plans, and estimates presented to him/her by the engineering team. Doing so requires technical acumen.
He probably wasn't the right person for the CTO job. But that doesn't mean that the CTO shouldn't be as much of a technical expert as that person is. It's just that that person didn't know how to switch to using his expertise at a leadership level rather than at the engineering level.
Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope.
I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year.
I'm terrified.
I'm terrified because I feel like I will let my reports down.
I'm terrified because a lot of the work I'm doing lacks transparency, how do I tell my compatriots about things that may not come to pass, especially deep political things -- and the amount of work necessary to onboard/offboard people, about "strategic partnerships" and why they're taken, or not taken or any of the hundreds of other things which are changing direction 3 times a day each.
I am technical, deeply, passionately technical.
I will not do service to people by being technical, my days are too fragmented, my worries too broad, it's impossible to dig into a small focused problem and give it the treatment it deserves - and even if I could then I'd be dooming one of my colleagues to maintain it forever because I couldn't possibly..
My being technical is good because I know the problems and I know what can make people feel valued; I can give people autonomy and direction and I can understand when help is needed and how to give it.
However, almost nothing in my work is technical, it's all presentations, discussions, breakdowns, timelines, contracts and negotiation.
The most code I write now is to do cost reporting.
My most frequently accessed cloud console pages are the billing sections.
This is not fun at all (and frankly, I didn't think it would be); but I fear what will replace me if I leave.
If you have that much chaos that you’re insulating your team from, it sounds like you need to try to set some barriers. I’m not sure how anyone could be expected to function in the environment you’re describing.
That's a bit too extreme, isn't it? The situation simply might change in one way or another.
A skilled replacement might just appear at some point or the parts of the executive level they're fearing the most might leave. I've never seen a company without any changes in management personell over a decade.
Doesn't seem extreme at all to me. I used to work at a place that would stress the importance of keeping implementations easy to understand and documentation up to date in case "[team member] gets hit by a bus tomorrow and we have to replace him." (Some people apparently thought this was too macabre so they would try to change it to "they won the lottery and quit instantly," but the engineering team thought this to be a less likely scenario than getting hit by a bus)
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.
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.
The challenge in technical leadership is letting go of the specifics and delegating them and only in very rare specific circumstances issuing orders.
There are a lot of "person who did everything" types who end up in leadership positions who try very hard to continue doing everything of any importance instead of appropriate delegation and leadership instead of control. I've had that problem, it's hard to let go.
This is such a good point. And doing this right can result in the technical leader feeling like they aren't providing value, especially if they are used to being great at solving technical problems themselves in the past. The manager dopamine loop is much longer and can at times not exist at all and you are still doing it right. I can see that it might be very tempting to try to get the feeling of accomplishment my stealing it from folks by disempowering them.
This comment may have been the tipping point into seriously considering quitting. Deep down I already felt it coming on but seeing it laid out like this hit home. The person currently in that leadership position fits every one of these bullet points and somehow remains in that position.
All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale.
Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.
Sounds like me 10 years ago, and I wish I took this advice.
If you love technical work, QUIT being an exec, a VP, a manager... do the work.
You WILL have a crazy time getting back into tech work, after 10 years, even if you were hands on the whole time.
Management / CTO and everything in between is best served by people who are technical, and are ready/aware/willing to move into a deeply political and financial driven domain.
I hated it, but it took me a years to really let that sink in and feel it hurting me.
Absolutely agreed. I'm currently working my notice after 5 years of technical leadership, after which I've got a job lined up where I can get back to sitting down and writing code. The last few years have been great experience, and I have no doubt they'll make it easier to work with management types in the future through understanding the sort of decisions they're having to make, but I have no desire to play politics for the rest of my life while other people go and do the bits that motivate me to get out of bed in the morning.
I'm a sysadmin background, did CTO for 9 years and then moved to product afterwards from the knowledge I gained.
Being on the other side of the fence has really helped me move around, I still to sysadmin/DevOps type work but mostly moved into product and I've found it really helps.
Too many C level see product as only UI/UX and the teams I manage appreciate my understanding of the pain points for everyone
Interestingly this list covers "bad manager skills". Which emphasises the point that bad managers are bad.
Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice.
Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare.
Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes.
Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it.
So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.
Fun fact, there are nearly no Animals who life in groups with "real" alphas, especially not Wolfs, maybe you can say Elephants where the oldest (most of the time) female is the leader (however that is because she is the most knowledgeable (location of waterholes, food etc)) and not because of her Character or "i want to be a leader" mindset.
There is one exception that comes to my mind with "real" Alphas and those are Gorillas.
In defence of "because I say so", it sometimes necessary. And not a big deal in my book, if the person giving the order is also owning all the outcomes, good and bad.
Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.
"Because I say so" is a terrible way to communicate why a thing is being done. In senior positions it is definitely necessary now and again to pull rank and tell people something is being done despite their protests, but I don't think I've ever found a situation where I couldn't articulate why that decision had been made. People may disagree with that decision, hell, sometimes I've disagreed with the decision I'm communicating, but you owe it to your people to communicate the reasons.
Fully agree on giving reasons. And more often than not there is room to discuss them. Also, from time to time, it doesn't matter weather or not we agree with those. And then there are those moments were there is no time to discuss.
Good leaders know to tell those appart, and professionals can accept it. Unfortunately, this combination, good leaders being in charge of professionals, is rarer then I'd prefer.
I had a situation recently where I had a report argue with me constantly over team agreement stuff like code standards and unit test coverage.
I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion.
It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of.
She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.
Yes but you already gave plenty of reasons before resorting to "that's the way we do things". And I think that's fine. What wouldn't have been fine would have been to skip the explanations.
Most people, given explanations, will accept them even if they don't agree with them. And quite often they will realize that there is more to the issue than they originally thought.
Hard disagree. A good coach only needs to see the players on the field, notice the things that wins game, and figure out the way to motivate their players. Don't need to have played the game, though it helps. I'm thinking of one of the best coaches in the world, who played the sport at an unimpressive level as a teen...but at a young age he watched his father work as an assistant coach. That's where he learned his skills.
As well, the requirement for "must hit X bar of quality", where X is some arbitrarily high level, is nonsensical. If they're so good at building quality products...then why aren't they doing that in the first place. Necessarily, your best builders should be builders, and your best managers...should be managers.
These are made so much easier if you have "played the game" that you pretty much end up back to the original argument of it being a requirement if being "a coach" to remain competitive. There of course will be outliers to this, like your aforementioned "coach that never played", but why deliberately base your point on an outlier?
> "must hit X bar of quality", where X is some arbitrarily high level
Quoting myself, I said "of quality", i.e. something that is reputable and, relative to some reasonable and well-known industry standard software development principles and benchmarks, of quality. I wouldn't say it's totally arbitrary.
Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays productive and on track. This will 100% require lying or being non-transparent at some point.
>My most frequently accessed cloud console pages are the billing sections.
Lol yep.
Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
I think I was good at the job, though of course I'm biased but even looking back there are very few things I would change. I really did try and will never feel like I was inadequate even though the company eventually did go under due to bad investments the owner made.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
Following this advice is another way of loosing employees, at least I'd leave a company quickly if the CTO started lying about potential problems not being problems.
In the end, depends on the company. Usually the company I've worked in, have valued transparency, so employees can decide themselves if they want to continue working there or not, when there are potential issues.
Not sure who it'll be good for if things are delayed in a project, you might be able to ship a good product but then the executive team is all like "Noooo, what you're hearing is just rumors, everything is fine and all will be good when we release".
> 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.
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.
"Things are tough right now, but once we close this deal then we'll be in a much more comfortable position. Your role on this is critical to our success."
Is this not a reasonable way of approaching it? It seems to be simultaneously honest and empowering. What lie is necessary?
Thats mostly a CEO trait. Remember CTO,CFO,COO,CIO, ect are all just jobs. You ultimately report to the CEO, whom ultimately reports to the investors,stakeholders, capital partners, b2b relationships and so on.
For the record I gave 100% of bonuses I had awarded to my staff and 0% to myself the entire tenure.
I wasn't trying to write a business book but what you wrote is fine usually for the senior level employees that get how business works and probably took the job with the understanding of the weight of their position. However you will also have fickle entry/low/mid level employees that don't have the maturity to accept the realities of the business world.
My comments are very revealing about the reality of the work world at mediocre aka most companies.
If you get a big enough group of people there are going to be some people with machiavellian tendencies or at least some that read bad advice on the internet about how to get ahead at work and try to apply it with clumsy gusto. You will look like a real fool to your boss the CEO if you are giving information to these type of people and they try to use it for their benefit.
I may be painting too dark a picture due to the focus the comments have on a single sentence. Overall I had good relationships with the vast majority of people that worked for me. I know this because I still have contact with most of them even though we have almost no chance of ever working together again. You are deluding yourself if you think there are no bad apples out there or that people having problems in their personal life may try to pull manipulation at work to get ahead or however they see may solve their problems.
> You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.
I'd rather my job disappear than still be there because someone with employment power over me lied to me. This isn't false virtue or armchair anything. No exceptions, or I don't work with you ever again. It's not hard. Learn to communicate effectively, and learn to treat your employees with the respect they deserve.
Consider that you're advertising yourself as the type of person who absolutely must be lied to in order to maintain morale.
I've been close to situations where the ICs did their absolute best and it was a total waste because of politics outside of their control. Do you tell them that so-and-so highly-respected person was shit-talking them because of an unrelated agenda and invalidated all of their work? Or do you tell them good job (it was a good job) and not get into it?
Frankly if this actually happened, I would do neither. Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you." and then address this as a grievous issue on behalf of my IC with the leadership.
If leadership doesn't fix the problem then just resign in protest.
EDIT: It's now occurring to me that there's probably different schools of thought here. Yes, I've resigned in protest on behalf of my workers before.
If my team is getting fucked, then I've either failed my team, or my purpose is meaningless. Either way, get me out.
Why do post mortems happen for production issues, when you could just open up "git blame?"
Are you lying to the team when you say, "we're not sure how this happened" rather than just quoting the git blame?
Well, no. The problem is much more complicated than a buggy commit. It's a wider problem with the system. So you say "we don't know, we have to look more into it" and do a post mortem because that is the honest truth.
The same principle applies here. So-and-so highly respected person committed a real-life communication bug that got merged into this IC's production career. But the problem is much more complicated than that. You don't know what the actual problem is until you address it with the leadership team.
I hear you on all of that, I'm just saying that leadership gets complicated. Sometimes the lie is better for all involved, especially the IC. You recognized this with your first instinct on how to communicate it.
As far as the rewards for poorly-motivated actions, we've always got the long term.
> Or do you tell them good job (it was a good job) and not get into it?
Personally, I’m okay with not being informed about everything that’s going on. I work at a big enough company that I couldn’t possibly know what goes on all the way up the management chain, but even if I worked at a small startup, I could understand if management didn’t want to be fully transparent. I don’t need to know; it’s none of my business. But I won’t stand being lied to – even about small things, or things I don’t even care about in their own right. I see lies as a breach of trust and as a sign that I can’t trust that person, moving forward.
So it depends on what you mean by “not get into it”. If you really stick to truthful statements, and if there isn’t a high enough prior expectation of transparency to make it amount to a lie of omission, then leaving it at “good job” is perfectly fine. But if you do lie… well, if I find out, I’m probably leaving.
> Well I've literally been in the position where this was true to close a deal so we could stay in business. What would be the best option in your opinion? Risk a critical person leaving right then and loosing the customer and then losing everyone job? Or lying and telling them we are all ok just keep on doing your job and don't listen to rumors?
Well I've literally been in this position too.
Lying to people is ineffective. It literally leads to the rumors you want to avoid. And even if your lies pay off, people aren't dumb. They realize how close to the edge they were and that you are a liar. Next time it will just be worse!
It's much better to be honest. Explain the situation. Explain what it will take. Use it to motivate people and build them up. People love a challenge, they want to feel like they're the hero of a story.
You literally took a situation where your employees would have come out stronger and more motivated to work for you, and you turned it into one where they walked away with mistrust.
> You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.
It has nothing to do with virtue! Even if you don't give a damn about being a good human being, this is a terrible way to manage people.
> You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors".
Sometimes your employees can tell things aren't going well, and you bald face lying to them like this will make them leave even faster.
This is also a great strategy to fuck people over, where if they believe in the stability of the company right until the day layoffs are announced they might have just bought a house or something else that will make the next few months for them excruciating, if not disastrous.
So please don't take this advice to the extreme imo. I'm not saying you shouldn't be positive, or give every detail. But you should be realistic. Save the rose tint for the investors and just make sure people have what they need to do their best work, within your power.
I actually wrote several responses and realized I was rambling on because of just how difficult it is to explain the reality of being in a decision making role. Rumors and politics are far far more prevalent than any acutal problems that will affect your people.
It is not your job to be responsible for other peoples personal lives, you are not the messiah. All you can do is fight to get them the pay they deserve. What they do with the money you have no control over anyway.
Layoffs at non Fortune 500 companies generally have less warning than anything can be done about anyway. Sure if its budgeted at Pfizer 6mo in advance your an ahole for not telling people. However its usually more like 2-4 weeks that the people in charge even know beforehand. ALso remenber we are talking about CTO. Its the CFO that knows the truth about the finances and may be hiding it from you as the CTO.
There seems to be quite a lot wrong in this post in my humble opinion... In brief, this reads as:
* Allowing rumor/politics to become malignant through deceit rather than healing through truth
* Dismissing responsibility for other people's livelihood because "hey its not my fault they didn't save money in case I throw them in the guillotine"
* Using lack of information as a reason to lie, rather than just telling your workers that you don't know the answers.
These are definitely the antithesis of "good" leadership. "Good" from an empathetic, humane perspective, and "good" for business and profit. It's true we have to make unpopular, hard, sad decisions. Yet it is absolutely imperative that we remain mindful and diligent to our team as individual humans.
You are ignoring a hard reality. Other people probably want your job. If you look weak/uncertain/outofloop it will encourage them to come after you and give them ammo against you. Making your job at best more difficult or at worst a full blown power struggle.
If you truly think that a person can't be honest and trustworthy, while simultaneously being strong and confident, then I really don't know what to tell you. Disclosing hard truths doesn't mean being "weak and uncertain".
I know workplaces aren't democracies, but there's no question that I'd vote for the straight shooter (even if their own position in the company is weakened by that trait) over someone who plays the political game well but lies to their reports.
> All you can do is fight to get them the pay they deserve
You can also be honest with them so that they can make informed decisions for themselves. The best CTOs I've worked for have been honest people who give you the bad and the good news together.
> However its usually more like 2-4 weeks that the people in charge even know beforehand
I'm guessing you're not referring to public companies with significant revenue. There's almost always warnings well before the 2 week mark.
There are many public companies not in the F500, and I agree with the grandparent that every executive will either know, or have a really good idea that a layoff is coming, well before 2-4 weeks prior, even if the internal finance/HR process hasn't quietly, officially started yet.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
I've only been performing roles of director / vp to small/mid size companies so far, so maybe there's some secret CTO sauce I'm still missing.
To me this advice seems toxic and destructive. Vent upwards, yes. Manage expectations, yes. But you're hiring brilliant people who will eventually know when youre lying or concealing info from lack of trust. good luck with loyalty at that point.
Exactly what I thought. This is a view of employees as mindless drones whose only function is to make themselves busy. A very toxic management style. The advice that it is ok to be hated dogs the ditch further.
This is also an implicit permission to the employees to lie to the CTO. This is pretty standard narcissistic behavior, where your lies to employees are just doing business, while employees lying to the management is a grave offence that calls for job termination.
There is only so much you can hide. Do you have BI? Well, they know numbers better than you, guess what? They talk to the rest of the company.
Do you have metrics available somewhere? Doesn't matter real-time or N days report - people can connect the dots: signs up are flat, but we keep hiring.
You can't meet requirements without marketing pushes? Well, shit, I wonder if a company spends 2 dollars to earn 1 dollar.
You can lie and bullshit all you want, but your reports and their reports will know.
I worked in a company where the analytics team suddenly decided to leave, all within days of each other. Month later - layoff. They weren't told that things are bad, they were the one who told you that things are bad.
> Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
Maybe they simply found out that you kept lying to them?
I know its hard to understand if you are never in such a role. People can be very irrational and will look to blame someone in charge when bad things happen. Even if they are the cause of those bad things.
I had one guy that got obsessed with crypto and was doing crypto trading instead of his work, not showing up/logging in, not making deadlines. He went off on me for like 30 min when I fired him and never spoke to me again despite warnings and discussions about the problem before getting fired for one example. In his irrational opinion I was holding him back from getting rich by expecting him to do his job.
I've been on the reverse side, where it was obvious the CTO and CEO were hiding things. It's annoying for a while and then eventually there's some proverbial straw that breaks the camels back.
Word spread pretty quickly through various cliques in the company. Some teams had no idea what was happening, other teams lost literally all their developers and and couple managers over the course of 30 days.
During my exit interview I mentioned the dishonesty and they just doubled down that I was imagining it.
> I had one guy that got obsessed with crypto and was doing crypto trading instead of his work...
I think we are all very obviously not at all talking
about the kind of situation you describe.
I left a company a little over a decade ago where the CEO and CTO (both co-founders) were lying to us about the company's situation for the better part of a year (which was longer than half the company had been employed there). I fortunately haven't had the chance to run into them since then, but I would absolutely give them the cold shoulder if I did. And that's because of what they did. I put in 80-hour weeks (including many weekends)[0] for over a year at that place, and they repaid me with a middling salary and worthless equity (after all common stock got wiped out less than a year later when the company got sold to one of the investors for peanuts and scraps).
Anyway, the one "nice" thing I can say about that CTO is that after they had a layoff (half the company), and I didn't get laid off, I went to the CTO and volunteered, and he let me go with the 4-week layoff severance package, which gave me a much-needed month off while I found another job.
(Speaking of startup equity, I'm just glad I wasn't quite out of college during the original dot-com crash, when colleagues I would meet a few years later ended up underwater on the loans they were encouraged to take out in order to exercise their company stock options. I can totally imagine wide-eyed 22-year-old me falling for a garbage scheme like that.)
> People can be very irrational and will look to blame someone in charge when bad things happen.
And sometimes blaming the person in charge is correct and rational.
[0] All stuff I will never again do for any company after that experience...
>I think we are all very obviously not at all talking about the kind of situation you describe.
Not really. My words were some people will hate you even if you do everything right. This was an example of a situation that was handled right but the person ended up hating me and slandering me for years afterwards. Just because I would not allow the company to fund their get rich quick scheme instead of their job.
I've even found people that I did not manage that got fired blamed me sometimes. Like all of mgmt was some evil cabal that conspired together to fire them cause thats what we really want instead of making the company money so we can all get out paychecks.
What people are doing is going off on a tangent of how they don't agree with how I handle the grey area stuff. There is a great deal of Silicon Valley worldview going on as well. The majority of the working world has lots of politics and pettiness going on along with power struggles and backstabbing. You cant be S.V. idealistic and keep your MGMT job in the middling business world.
My reports have lied to me very rarely, and I have never had to lie to my reports. For the reports that lied to me, I managed them out of my team irrespective of their work performance.
I have quit jobs where my manager lied to me. It is really really easy to tell when someone is lying.
You seem to live in some alternate dystopia where everyone lies to each other. How many of the companies that you have worked at have gone under?
Yeah I'm really confused about this guy. I get that the world is not black and white, and conditions aren't always ideal... but I absolutely do not put up with the kind of dishonesty he's seemingly advocating. Perhaps not everyone has the luxury to be so picky, but... damn, I really have not gotten the impression (in my experience, and in the experience of friends and acquaintances) that this sort of bullshit is that common. At least not at successful, healthy companies.
If you create a culture where you lie, then people will lie to you.
If you create a culture where you are honest, people will be honest back to you.
There's nothing more powerful than going to your team and saying "Look, I fucked this up. I need your help". Honesty is disarming.
I'm in a field where I manage scientists. If people start to lie to me or even start to bend the truth a little, we will waste years chasing ghosts. The people that work for me are very savvy at figuring out what I think might be true and they can always present just the right data to make me happy. I had to learn early on that I need to be really explicit: we need to do good work, it doesn't matter if I'm right or wrong, it doesn't matter if they're right or wrong, all that matters is progress.
So no. Your employees don't need to lie to you. Mine come to me regularly and explain what went wrong. Judgement-free. And we do deep dives to prevent problems in the future.
> So no. Your employees don't need to lie to you. Mine come to me regularly and explain what went wrong. Judgement-free. And we do deep dives to prevent problems in the future.
I had a junior EE come and find me while I was on a smoke break to immediately inform me that he had mixed up two connectors and had accidentally put 48V into a piece of kit that could only handle 12V, resulting in $10k worth of blue smoke. That’s what a high trust engineering org looks like. He could have lied about it, I didn’t see it happen, “I dunno I went to reboot it and it didn’t power back on”.
That’s what I want to see. He was open and honest with me because I don’t feed him bullshit.
>You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors".
When you've been lied to enough you stop believing the lies, a leader who can't be relied on to tell the truth unless it's positive might as well not say anything at all or be there in the first place. Having to doubt and read between the lines for each and every message from leadership is a waste of my time and leads directly to me A) no longer caring and B) not trusting my leadership.
This kind of manipulation only works on stupid or inexperienced people.
There is a big difference between putting a hopeful spin and always fighting for the best outcome and straight up saying everything is fine until there's nothing left but ashes.
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?
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.
> 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.
This I do agree with. Many CTOs don't actually have the entire engineering organization under them in the reporting chain (at a reasonably-mature company; not talking about a startup where the CTO is often one of the co-founders and runs engineering), so they have no real power to get other people to do what they think should be done.
At best they have an "Office of the CTO", or perhaps run the company's software architecture group (if the company even has one), and then they just have a tiny army of people who try their hardest to convince other teams to do things that aren't in their roadmap and would mean pissing off their bosses if they took them on. Not fun!
Yet in some companies, the CTO has the ear of the top executives. If some scheming non-technical career climber can get their way into the CTO's position, they can get to the top of the tree.
A lot can be achieved by aligning themselves with successful projects and crapping on others at the start or just at the cusp point of success or failure.
This is the job for 80% of corporations, the same 80% of corporations ruled by non-technical highly-political spin-based organizations, that dont really grok what they are up to.
Having technical depth in the leadership ranks, having real competency & belief & understanding in what you are doing, is, alas, not common. But wow, what a difference it makes for an org.
I see a lot of responses to this comment, especially these lines:
> Transparency is not your job.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
To add my 2 cents I kind of agree. When I first got into management, I didn't realise how many fires they were, or priorities I needed to balance. Initially I thought "there shouldn't be this many fires" but I soon realised that that was my job, to put them out, escalate when required, etc all while making sure the ship is steady and doing it with a smile on my face.
Some examples include:
- News that a sales person has sold a huge project which will save the company, but we can't deliver or build with our current backlog / resources
- One key team member has been taking a lot of doctor's appointments recently - and suspect they might be quitting / job hunting
- There's a very obscure security issue which could be fatal if discovered, but is a huge task which will disrupt a project which is already delayed and over budget
If I ran into any of these when I first started I would have freaked out - and that would have disrupt my team as they couldn't be productive with that anxiety over their heads.
Instead I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Of course if something was too big to handle I'd escalate, or if something blew up I'd take responsibility etc - but I think job #1 in management is to shield the team from distractions and let them do what they're best at doing.
I hope that's what the original poster who you quoted meant, because I don't see all that much wrong with the examples you mention. No, there's no need to engage people in discussions about things if it doesn't really impact them, or they can't really jump in and help the situation.
However, in the absence of some legal requirement to keep quiet, if some employee got wind of one of those situations, and came to you and asked you about it, I really do hope you'd be honest and forthcoming. Because otherwise I think that's when you'd cross the line (for me at least) into being untrustworthy.
One thing to mention though: in the case of your first example, if that huge deal really is going to fall through, no question, and the company is going to fail because of that, no question, I would lose all respect for an executive who didn't pro-actively have the hard talk with employees about that situation. Yes, some people will leave. But that's life, and your employees have entrusted their livelihood with you; you owe them that level of honesty.
> I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Which is fine! Because if you truly did put out those fires, or at least put in place some mitigating strategies, then you were absolutely telling the truth that it was under control.
> I think job #1 in management is to shield the team from distractions
The difference is that some "distractions" can have a material impact on those employees' lives. An executive who hides those things and lies about them to employees is not worthy of respect. For "distractions" that truly are just distractions, sure, fine, no need to broadcast.
But I think a key question is: if a bit of news could make a reasonable employee, thinking logically about the news, decide to quit, then... you absolutely should be disclosing that news. Anything else is just a betrayal of the implicit trust an employee must have in their employer.
And yes, I know all this might seem pretty idealized, and I know there are a lot of companies and executives who won't get these things right. But that doesn't mean I want to work for those people.
Yeah for sure completely agree. Tbh I didn't think too deeply about the scenarios, they were more to put context around what I meant by "fires", and how not mentioning them (which some might consider lying) is necessary sometimes to steady the ship (though if a team member asked I'd let them know what's happening).
I do think scenario #1 is interesting to talk about though.
I.e. If I was that manager receiving that news, I wouldn't outright tell the devs and say "it could be crunch time for the next 6 months", which might cause a panic and devs will start looking for other jobs.
Instead I'd call a meeting with leadership / sales, see what was sold and if there's any flexibility on deliverables with the client. If we need more resource, is it worth finding funding to hire more staff, or maybe postpone another project to get this higher priority one done.
Once that's resolved then I can think about delivering the news. Maybe it's a non issue (e.g. a new team is spun up to handle the project and someone gets a promotion to head the team), maybe it's crunch time (in that case it's time to have a difficult conversation with the team), or maybe the client is flexible on delivery (so it's business as usual).
Again, I could see how some managers would be uncomfortable not telling their team everything (and potentially cause unnecessary panic) - but I think that's part of management, knowing what level of detail your team are happy with, knowing what you can / cannot handle, and knowing how to delivery good / bad news and sometimes having to be the bad guy.
I would add including the team once the path is clear.
What scares people is uncertainty. Not uncertainty of outcome (50% chance this will save us). It's uncertainty of what the options are, what the roadmap might be. That's the job of a good manager. Insulate the team from uncertainty and politics. Figure out the space of options, what the outcomes can be, negotiate it with leadership, and present a reasonable and clear plan to the team. That won't cause panic.
Show the team the plan, its rationale, and what needs to be done. What the upside will be. Let them take ownership of it. Let them make the lower-level decisions of how to split time, of what to prioritize, of what edges can be cut. With your feedback.
People generally don't bail when faced with a challenge. They like challenges. You just need to define the challenge clearly and set the path for overcoming it.
> Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on.
Gross. I worked at at company where the CEO and CTO were hiding important things about the company from employees. When we found out, we felt lied to and betrayed, and there was a mass exodus. The company folded less than a year later.
I'm not saying leadership should be telling employees every little tiny thing. (And certainly some things just cannot be talked about in early stages of the deal, like funding rounds and being acquired.) But employees should have a pretty good handle on the health of the company and what's going on at a high level.
If employees get anxiety or start looking for new jobs because the executive team is being truthful, then either a) the company is doomed, and only an asshole executive would lie to keep employees around, or b) the company is just in a difficult spot, but leadership is not doing a good job of communicating the solid, likely-to-succeed plans in place to get things back on track.
I refuse to work for leadership teams who are not transparent. If they don't think they can trust me to act well in the face of difficult information, then I don't see why I should trust them to run the company that's responsible for my paycheck and livelihood.
At this point in my career, I think the #1 responsibility for everyone above VP is to maintain everyone's fantasy of a stable paycheck in exchange for stable work.
Once you peek behind the curtain of where your firm's cash comes from and where it goes, you have to live with a deep existential fear that you could mess up a bunch of people's lives... and you don't want others to have to live with that.
It's very convenient to believe that everyone replying to you who disagrees with you has no management experience, and the one lone voice giving uncritical agreement is the one person who does.
I could not even finish reading this comment. As a C-level leader in an organization, communication should be your strong card. It's unacceptable that you don't even know the difference between "you are" and "your".
If as an employee I get an e-mail from a "CTO" consistently getting confused with such elementary, trivial shit, I would fucking resign immediately as that makes it evident that the organization is led by illiterate people and has absolutely no future.
I wouldn't judge so quickly, this kind of mistakes happen sometimes among non-native English speakers. In any case, CTOs don't do much, so the future of a company is not tied to the IQ of its CTO.
I do know the difference though. I probably copy/pasted part of the comment around and missed that I changed the context. Shame on me for not proofreading my internet comment though. You should probably erase me from existence for my lack of vigilance as punishment...
Then you didn't have a CTO like me. I'm still in regular contact with most of the people that used to work for me. One actually just texted me this morning to ask how I was doing. Even though our lives will almost certainly never intersect again.
> This will 100% require lying or being non-transparent at some point.
I've been CTO/equity partner/division director/tech lead/IC/etc... and this is terrible advice. The one thing you need as a leader is trust - your people need to trust you and you need to trust them. Treat people like the adults they are, tell them what's happening to the best of your ability, and people will work their asses off to accomplish the goal.
Thank you for sharing how you feel. It's incredibly brave.
> I fear what will replace me if I leave
I admire the respect and dedication you have toward your reports (I assume the fear comes from what a successor may do to your reports rather than what a successor may do to the company).
However, if it falls on your to protect your reports from the company, then it may be worth considering how well the company's values align with your own. A terrible outcome would be to compromise your integrity for the sake of the company. If you leave, it's still possible to help those currently under you. Whether or not they would still want your help depends on your integrity.
If I can give an advice quite different from the other comments: don't sweat it. You're not becoming responsible for the success of your team or your company, you're just taking a different role. Things would probably work fine without you. Hell, companies can run for months and years without CEOs (one of my previous company did).
What you can do is two fold: be technically involved (this is the topic of this thread) and be a good leader. The latter means a lot of things, but IMO it also means transparency. I'm really sad to see other comments saying that your role is to not be transparent, I totally disagree.
That's why becoming a CTO shouldn't be treated as promotion or "next level". And there should be the same compensation level for individual contributors.
Maybe the question is what is (or should be) the role of the CTO. A lot of what you describe sounds more like Chief Product Officer (or Head of Product) rather than CTO.
You need to be technical enough to say no to a partnership, acquisition, or technical strategy that is bullshit. Most of the time, the Spidey sense to make that kind of a due dill judgement only comes through having been a technical employee. (Though having been a technical employee by no means guarantees that, either)
You’re leading with fear and anxiety, you’re letting that fear and anxiety trap you. There’s a great deal of value in thoughtfulness, in kindness, in using your passion to lead, but that value is often lost when the motivation for these behaviours is anxiety. A leader is as much what they signal as what they do.
There’s a variety of options available to you, options that can deliver the best outcome for the business, your reports and yourself — many of which can be fantastic outcomes for all.
Ultimately, building a business is a relay and you will at some point have to pass on the baton: if you fear that inevitability, that needs to be an immediate focus. What can you do to ensure that you can pass the baton on with confidence?
Positioning yourself as not “the CTO” but rather “the person establishing the business’ approach to technology” (which is achieved by utilising the CTO role today) can be a very powerful shift in attitude: you’re setting the technology organisation up for the baton to be handed over to the person ready to lead the next stage with confidence.
If I were in your position, I’d be talking with the other leadership in the business and clearly communicating that you don’t want this role indefinitely, I’d put a plan together for the next 12 - 18 months that involves bringing someone in to replace you, someone for you to pass the baton to.
A bad outcome for the business would be you spending the next 12 months silently stewing in your own anxiety and fear and then have a breakdown and disappear without any notice and the business is thrown into chaos.
As a leader, you don’t need to be perfect or a brilliant jack of all trades or a genius or even the smartest in the room, but you do need to operate with confidence though. If you don’t have confidence in something, focus on getting the confidence.
(For what it’s worth, the shift from where you are now to where you need to be is almost exclusively in attitude, it’s not some insurmountable challenge.)
Congratulations for becoming a CTO but also it terrifies me to think that my CTO is terrified of his/her work. Of course as IC I will never know this but I just don’t get it. I feel like CTOs has been in management jobs at some point before becoming part of the Cs. I feel like in your narration you went from IC to CTO directly. I may be wrong.
If your org is 10 moving to 50 in a few months then you have a BIG change ahead. The good news is that you are responsible for how your team operates. You've identified problems, and now you get to fix them - not by coding, but through leadership & culture. This isn't to say it's easy, it's a massive challenge, but it is yours to solve and does require technical knowledge and skill.
No first time CTO's had it figured out either - continue to show the courage to ask advice (as you've done here) and figure it out bit by bit. Nobody has made your org before - there's no playbook only prior work.
The flip side is if that is of zero interest, you're likely in the wrong role. No shame, depends what motivates you.
I'm curious about why and how you've become a CTO?
Presumably, you don't have to do it if you don't want to. If that's true, be nice to yourself and remember that on a regular basis :)
What you've described is pretty much the way many CTOs would describe the job. Don't worry. Treat it like any new discipline. Seek out expertise and learn from it. Make notes and crib sheets and read them regularly (they might be about financial management, or about people management, whatever you need).
Find a mentor if you can.
Don't burn out.
Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
Lying is shitty. Really, really shitty. Think about it.
Doubt is normal, but check yourself for imposter syndrome on the reg.
Firstly, I was recommended for the position by the managing director of a large (the largest?) Swedish games company, so I figured it was a once in a lifetime opportunity.
Secondly, I asked my old CTO if it was a good fit for me as I’d been a manager before and I felt I preferred IC, I also have an abrasive way of communicating which worried me greatly, his response was that the abrasive parts of my communication style will melt away because it is bore out of frustration.
Finally; I have worked in meritocratic cultures but only when there was significant external political pressure from the publisher. Theoretically I could replicate that culture but without the political cruft; additionally I would be in a position to set the company up with long-term technological investments and partnerships: which I was trying to do before but managers are usually focused on short term goals.
> Find a mentor if you can.
> Don't burn out.
> Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
> You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
This is good advice and I appreciate it greatly, I will wear these words going forward.
The worst CTO I ever worked for thought he was the expert because he "cut his teeth on assembly" in college. He indirectly micro-managed everyone with a "goal setting" farce. You had to submit very specific goals each quarter. He would then revise all of your goals for you, and give them back. They were a curated list of tasks that you had to accomplish. You would then be graded on those tasks and publicly shamed. He was so proud of his acronym "SPEED" and believed he was a great culture shaper. I've never worked in a more toxic environment, and never in a less productive one. We would have been 10x more productive if we didn't have a CTO at all.
Sounds like you are making the technical to leadership transition extremely quickly. I think you will find that it’s the speed of that transition, rather than the transition itself, that is giving you difficulty.
One thing that has helped me, and may be helpful to you as well, is to look at your new role as an engineering problem. Logistics and process may not feel technical but they 100% are, and if you approach them with the same problem solving mindset and intellectual curiosity as, say, a coding task, you will enjoy them a lot more, and may even find that you become very successful at them.
I really like the model Apple are using is C grade only for CEO, Operation and Finance. The others are SVPs. There is no need for a CTO.
The first job of an SVP is to stand up to the CEOs when they are pushing for impossible deadlines.
The second job of the SVP is to stand up to CFO when they want layoffs. Or fight for more resources when they are pushed to the limit.
The third job, arguably the only thing that is technical, is to stop your sub coordinate pushing for what ever that is hyped in the industry to be used within your company.
It may sound easy in a small startup, doing the above three things in a large company is easily a full time job.
The biggest problem I've seen with this in implementation is that rolling the technical part of any organization under operations is usually disastrous, because ops will generally aim to keep their footprint as small as possible, and do the absolute bare minimum to try and retain talent. It's a model that heavily encourages thinking of technology as a cost center, developers (with domain knowledge) as easily swappable or replaceable units, and vendor SaaS as a preferred solution in almost every instance.
Personally I think having a CIO makes a lot of sense, even if you ditch the CTO, CISO, CDO, CAO panel that is generally subordinate to the CIO anyways.
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.
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.
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.
Is this what passes for management advice these days?
> CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality.
This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time.
I don't see the problem. Part of a CTO's role is to set the tone for planning and direction, including priorities.
The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.
I would fire any CTO (or engineer) that took this kind of absolutist approach. I find this kind of extremism associated with mediocre engineers and engineering leaders who cannot weigh competing priorities without a black and white answer key which doesn't map onto reality.
For sure. The sad truth is that a lot of people rise through the ranks by taking dramatic action, because that gets lots of attention. Confidence is much easier to detect than competence.
If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more sensible. I've been on multiple teams that organically chose to try an approach like that when faced with growing quality debt. A CTO can globally foster a culture that is applied locally in concrete decisions.
Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake.
The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement.
One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established.
But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user.
One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.
I've worked at decacorns that used code freezes... Usually they were last minute "oh fuck we took down the whole website 3 days in a row now and this has cost millions of dollars" kinda reactions.
The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages...
I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
Indeed! Honestly, I'd expect a moderate inverse correlation between valuation and code/practice quality.
I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't.
But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.
I can't say for sure about those particular cases. I'd have to have a lot more detail. But as I mention elsewhere, one of the best ways to rise through the ranks, especially at companies excited to be unicorns, is to do dramatic things, even if they aren't particularly effective.
~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out.
The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time.
In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.
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.
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.
I’m a marketing director, not CTO, so take this with a grain of salt. But I believe leaders should be “good enough” in a wide array of disciplines. Certainly the disciplines involved in their department, but also, frankly, every aspect of the business.
Meaning a CTO should also be good (not great) at sales, marketing, cash flow, customer service, user experience design, etc.
Being well rounded means being able to garner the respect of not only the engineers but all stakeholders, from internal people to the customers to the general public, too.
I’m certainly not arguing that a great engineer won’t make a great CTO. It should probably the area they’re strongest in.
But if I had to pick between an amazing engineer who knows nothing about the rest of the business, or a reasonably knowledgeable CTO who is also reasonably knowledgeable on all other fronts, I’d pick the latter every time. No hesitation.
There is a caveat to this, though. Being a generalist means recognizing that on any given topic, someone knows better than we do. So you have to be able to recognize that and defer to expertise, while also completing the picture by thinking about all the variables that lead to a business being successful.
I’ve met plenty of engineers (and designers and copywriters, etc etc) who think everyone else’s roles are easily understood and accomplished. That’s fine if you’re a specialist. But a leader needs to understand the big picture, and no one is an expert in all areas. It’s just not possible, by my estimation.
There's a huge difference between a Dropbox and an Uber here.
Dropbox is a technology company. This is famously a place where deeply technical leaders can achieve competitive advantage. The whole company exists to support the tech, so if the tech fails, bad.
Uber (and most startups really) don't do tech, they use tech to drive sales. Of course the tech is important but it's a solution not a driver. Here I agree that a "well-rounded" tech-average CTO can be advantageous.
Tech strategy is where everything converges. If products literally live or die by it, you better have a crack technologist at the top.
For clarification: Are you suggesting Dropbox’s leaders aren’t well rounded? Or that they are and that they also need to be stellar engineers?
I think you make a great point either way. I’d elaborate on that and say a business leader needs to deeply understand the product they make/sell, so if your core product is tech, I agree and see your point. But I still think they need to be really good at all facets of the business. They still need to understand the market and how to promote and how to close sales. Those skills don’t really develop if the only thing you do is engineering.
Take HubSpot’s CTO Dharmesh for example. Brilliant engineer! But he applies his curiosity to understanding people and markets and solving unsolved problems. He understands the whole business. He also understands his own shortcomings and surrounds himself with people with complementary skills, because he knows full well that engineering alone isn’t enough.
Thanks for the kind words. I don't consider myself a "brilliant" engineer. More of an experienced engineer. I've been building software products for 30+ years.
I think the role of the CTO varies based on the scale of the company.
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.
366 comments
[ 2.9 ms ] story [ 246 ms ] threadContrast that to a tech startup, or any startup I suppose. Those CTO's absolutely need to be "in-the-weeds" capable.
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
IMHO, too many people chase the CTO title but few really want the actual job.
So true. CTO being so far upstream, mistakes made here through disconnection between the rubber and the road have compound effects downstream. It's the sort of role where bad decisions have huge, company-ending ramifications.
"I talked to my buddy at [FAANG] and he said microservices are the way to go. His team achieved awesome velocity by switching to microservices. Let's do it guys!".
Amazon had huge dependency problem, both technical and organizational. Technically, the effort to work in their monolith scaled superlinear with respect to the CL size due to coordination and review with other teams. Organizationally, teams were dependent on an ever growing set of centralized, global processes that further slowed their ability to make progress.
Jeff (and S-team) saw these issues and worked to solve them through a series of experiments. Specifically, Jeff tasked his then CIO with finding a solution. This CIO worked throughout the organization to gather on-the-ground feedback around what was and wasn’t working; built a model for how Amazon _should_ work based upon that sense making; and then tested, iterated, and refined that model into what we’ve come to know as Single-Threaded Leaders and Two-Pizza teams, etc., today.
In parallel, a couple Amazon business units were experimenting with exposing their data via textual (XML) APIs like the Amazon Associates API which went on to become the Amazon Product Listings API. These early APIs were sort of the POCs that allowed Amazon to see early validation around the concept of web services.
Synthesizing all these different streams of information, ideas, and actions lead to Jeff’s “edict” around building standalone web services (which eventually led to what we know as AWS today).
In short, Jeff is the exact antithesis of GP’s straw CTO. He speaks from data, facts, and information gathered from a myriad of internal and external sources, not merely anecdotes of success from a CEO buddy. :)
Source: Working Backwards has a lot of information on Jeff (and Amazon’s) decision making.
While a CTO needs to have grown up in the technical trenches to have credibility, a CTO should not be making any technical decisions anymore. If they are, that's a red flag for a CTO who can't let go and keeps micromanaging.
A common pitfall among startups is to give the CTO title to whichever cofounder is leading the development when the team formalizes titles. Some times this person doesn't even have previous engineering manager (EM) experience at all, but as the most technically oriented person of the time they receive the CTO role by default.
Some times these people can grow into the necessary delegation, recruiting, hiring, performance review, people management, communication, and meeting skills necessary to be a CTO. Other times, they cling to what they know (coding) and turn into a micromanaging CTO who won't cede control of the things they want to do (code) while avoiding the things they have to do (managing).
This is one of many reasons why I advocate for avoiding C-level titles as long as possible at a startup. You can always promote someone up to CTO unceremoniously when the company actually needs defined C-level executives and they've been excelling at the role already, but it's much more problematic to ask someone to give up the CTO title and step aside to bring in an experienced CTO when necessary. Nobody likes being demoted, even if it's only a formality because they weren't actually doing the full management role. Any title demotion at startups is likely to lead to conflict and departures.
This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.
I 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.
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.
remind me not to apply to any SPC companies, nor use their products
(disclaimer: I know him personally and his credentials aside, think he's extremely knowledgeable about engineering leadership and company building in general)
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.
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.
> 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/
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
Very true. GP probably had good tech judgement which is why their technical CTO was following their judgement.
I told myself that there were only two positions at two companies that could have convinced me to leave. I got hired by one of those companies. He left less than a year later after the company was acquired for 10x revenue. He’s working somewhere else now. I would work for him again in a heartbeat if I were working anywhere else besides where I work now.
I am genuinely wondering if I need some jiffy lube for flushing those fluids of mine.
It... sounds like... a thing... that people... do?
The non-technical CTOs "defense" is having found which reports they can trust and support to make the correct tradeoffs. Then they do that. More broadly if your reports aren't competent or trusted enough to make the right decisions then find new reports.
The job of the CTO isn't to argue some stupid architectural point with people for hours. It's also not to blindly overrule them. Their job is to hire people that know more than them and can be trusted. Then it's to setup the processes within which those people can thrive.
In fact the problem with technical CTOs is that they can rely too much on their own technical knowledge versus fixing the damn organization. It's basically a bunch of band aids being put on a gushing wound.
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.
"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.
Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope.
I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year.
I'm terrified.
I'm terrified because I feel like I will let my reports down.
I'm terrified because a lot of the work I'm doing lacks transparency, how do I tell my compatriots about things that may not come to pass, especially deep political things -- and the amount of work necessary to onboard/offboard people, about "strategic partnerships" and why they're taken, or not taken or any of the hundreds of other things which are changing direction 3 times a day each.
I am technical, deeply, passionately technical.
I will not do service to people by being technical, my days are too fragmented, my worries too broad, it's impossible to dig into a small focused problem and give it the treatment it deserves - and even if I could then I'd be dooming one of my colleagues to maintain it forever because I couldn't possibly..
My being technical is good because I know the problems and I know what can make people feel valued; I can give people autonomy and direction and I can understand when help is needed and how to give it.
However, almost nothing in my work is technical, it's all presentations, discussions, breakdowns, timelines, contracts and negotiation.
The most code I write now is to do cost reporting.
My most frequently accessed cloud console pages are the billing sections.
This is not fun at all (and frankly, I didn't think it would be); but I fear what will replace me if I leave.
*I have never worked in games.
So you'll never retire or die?
A skilled replacement might just appear at some point or the parts of the executive level they're fearing the most might leave. I've never seen a company without any changes in management personell over a decade.
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...
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.
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.
All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale.
Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.
Be proactive, send them a link.
If you love technical work, QUIT being an exec, a VP, a manager... do the work.
You WILL have a crazy time getting back into tech work, after 10 years, even if you were hands on the whole time.
Management / CTO and everything in between is best served by people who are technical, and are ready/aware/willing to move into a deeply political and financial driven domain.
I hated it, but it took me a years to really let that sink in and feel it hurting me.
If you can short circuit that wasted time. Do.
Being on the other side of the fence has really helped me move around, I still to sysadmin/DevOps type work but mostly moved into product and I've found it really helps.
Too many C level see product as only UI/UX and the teams I manage appreciate my understanding of the pain points for everyone
Equally a good manager with average tech skills can do everything opposite to this list with the help of technical advice.
Sure we'd all like a great tech guy who somehow is also a fantastic manager. But let's accept those are rare.
Next best is a great manager (emphasis on good, not bad) who listens well and takes advice regarding pure tech matters. Over time their tech will improve (remember, good manager) but in the meantime IT flourishes.
Only then comes a great tech guy with poor management skills. Frankly poor management will kill a team faster than good tech skills can save it.
So yeah, as the article suggests, a great all rounder would be the best option. But I feel there aren't enough of those to go around. In that case I'll take a good manager over a good techie all day long.
Raw dominance is the dynamic governing primitive social animals.
Chimps are a bit smarter, and would collaborate as a group to beat up alphas that they hate.
The group is smarter, than an individual's dominant strategy.
They'll collaborate as a group to embarrass and undermine and quit that scene.
There is one exception that comes to my mind with "real" Alphas and those are Gorillas.
Fully agree on everything else. Additional caveat, I have a supply chain and logistics ops background, so a completely different environment to design and development.
Good leaders know to tell those appart, and professionals can accept it. Unfortunately, this combination, good leaders being in charge of professionals, is rarer then I'd prefer.
I explained every piece of rationale I could come up with for why the team chose to do things the way they did. I offered to schedule team discussions for her to try and convince the team to adopt other strategies, with the understanding that if the team didn't want to do things her way that would be the end of the discussion.
It wasn't the end of the discussion for her though, she kept complaining. Eventually I just had to say "that's the way we do things here so you have to get on board". It's awfully close to "because I said so", and I hated saying it, but I exhausted every other avenue I could think of.
She wound up giving her notice, so I guess we were on the same page because I was working with my manager on letting her go. But if she had been able to keep her head down and do the work we would have kept her for sure. She was a good coder, good systems knowledge, just really didn't like writing unit tests I guess.
Most people, given explanations, will accept them even if they don't agree with them. And quite often they will realize that there is more to the issue than they originally thought.
A coach that never played can't teach.
As well, the requirement for "must hit X bar of quality", where X is some arbitrarily high level, is nonsensical. If they're so good at building quality products...then why aren't they doing that in the first place. Necessarily, your best builders should be builders, and your best managers...should be managers.
> motivate their players
These are made so much easier if you have "played the game" that you pretty much end up back to the original argument of it being a requirement if being "a coach" to remain competitive. There of course will be outliers to this, like your aforementioned "coach that never played", but why deliberately base your point on an outlier?
> "must hit X bar of quality", where X is some arbitrarily high level
Quoting myself, I said "of quality", i.e. something that is reputable and, relative to some reasonable and well-known industry standard software development principles and benchmarks, of quality. I wouldn't say it's totally arbitrary.
Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays productive and on track. This will 100% require lying or being non-transparent at some point.
>My most frequently accessed cloud console pages are the billing sections.
Lol yep.
Eventually some of those reports will hate you as well even if you do everything perfectly. Its inevitable from being in charge. You may not find out till running into them years later and they just shrug you off when you try to say hi.
I think I was good at the job, though of course I'm biased but even looking back there are very few things I would change. I really did try and will never feel like I was inadequate even though the company eventually did go under due to bad investments the owner made.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
Following this advice is another way of loosing employees, at least I'd leave a company quickly if the CTO started lying about potential problems not being problems.
In the end, depends on the company. Usually the company I've worked in, have valued transparency, so employees can decide themselves if they want to continue working there or not, when there are potential issues.
Not sure who it'll be good for if things are delayed in a project, you might be able to ship a good product but then the executive team is all like "Noooo, what you're hearing is just rumors, everything is fine and all will be good when we release".
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
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.
But I can acknowledge there are cases where transparency is simply not an option.
Is this not a reasonable way of approaching it? It seems to be simultaneously honest and empowering. What lie is necessary?
EDIT: slight revision
For the record I gave 100% of bonuses I had awarded to my staff and 0% to myself the entire tenure.
You need to read that sentence again. Your comments are very revealing about you and not about CTO level work as you are imagining.
If you get a big enough group of people there are going to be some people with machiavellian tendencies or at least some that read bad advice on the internet about how to get ahead at work and try to apply it with clumsy gusto. You will look like a real fool to your boss the CEO if you are giving information to these type of people and they try to use it for their benefit.
I may be painting too dark a picture due to the focus the comments have on a single sentence. Overall I had good relationships with the vast majority of people that worked for me. I know this because I still have contact with most of them even though we have almost no chance of ever working together again. You are deluding yourself if you think there are no bad apples out there or that people having problems in their personal life may try to pull manipulation at work to get ahead or however they see may solve their problems.
Please don't put words into my mouth.
I'd rather my job disappear than still be there because someone with employment power over me lied to me. This isn't false virtue or armchair anything. No exceptions, or I don't work with you ever again. It's not hard. Learn to communicate effectively, and learn to treat your employees with the respect they deserve.
I've been close to situations where the ICs did their absolute best and it was a total waste because of politics outside of their control. Do you tell them that so-and-so highly-respected person was shit-talking them because of an unrelated agenda and invalidated all of their work? Or do you tell them good job (it was a good job) and not get into it?
If leadership doesn't fix the problem then just resign in protest.
EDIT: It's now occurring to me that there's probably different schools of thought here. Yes, I've resigned in protest on behalf of my workers before.
If my team is getting fucked, then I've either failed my team, or my purpose is meaningless. Either way, get me out.
And so you take your first step down the path.. "I'm not sure" is a lie here.
Are you lying to the team when you say, "we're not sure how this happened" rather than just quoting the git blame?
Well, no. The problem is much more complicated than a buggy commit. It's a wider problem with the system. So you say "we don't know, we have to look more into it" and do a post mortem because that is the honest truth.
The same principle applies here. So-and-so highly respected person committed a real-life communication bug that got merged into this IC's production career. But the problem is much more complicated than that. You don't know what the actual problem is until you address it with the leadership team.
As far as the rewards for poorly-motivated actions, we've always got the long term.
Personally, I’m okay with not being informed about everything that’s going on. I work at a big enough company that I couldn’t possibly know what goes on all the way up the management chain, but even if I worked at a small startup, I could understand if management didn’t want to be fully transparent. I don’t need to know; it’s none of my business. But I won’t stand being lied to – even about small things, or things I don’t even care about in their own right. I see lies as a breach of trust and as a sign that I can’t trust that person, moving forward.
So it depends on what you mean by “not get into it”. If you really stick to truthful statements, and if there isn’t a high enough prior expectation of transparency to make it amount to a lie of omission, then leaving it at “good job” is perfectly fine. But if you do lie… well, if I find out, I’m probably leaving.
Well I've literally been in this position too.
Lying to people is ineffective. It literally leads to the rumors you want to avoid. And even if your lies pay off, people aren't dumb. They realize how close to the edge they were and that you are a liar. Next time it will just be worse!
It's much better to be honest. Explain the situation. Explain what it will take. Use it to motivate people and build them up. People love a challenge, they want to feel like they're the hero of a story.
You literally took a situation where your employees would have come out stronger and more motivated to work for you, and you turned it into one where they walked away with mistrust.
> You are espousing false virtue/armchair quarterback. Real life is complex and lying can save many people jobs.
It has nothing to do with virtue! Even if you don't give a damn about being a good human being, this is a terrible way to manage people.
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.
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.
Sorry but the reality of human nature is tough.
If someone is actually better suited for a role than I am, then let them have it. I'll find another role and keep growing. Where is the problem?
If some team makes the mistake of confusing trust and openness with weakness, then good riddance, I'm better off with a different team.
I know workplaces aren't democracies, but there's no question that I'd vote for the straight shooter (even if their own position in the company is weakened by that trait) over someone who plays the political game well but lies to their reports.
Hell, I would vote, with my feet, if I had to.
You can also be honest with them so that they can make informed decisions for themselves. The best CTOs I've worked for have been honest people who give you the bad and the good news together.
> However its usually more like 2-4 weeks that the people in charge even know beforehand
I'm guessing you're not referring to public companies with significant revenue. There's almost always warnings well before the 2 week mark.
>Layoffs at non Fortune 500
Yeah Literally what I said in my comment.
There are many public companies not in the F500, and I agree with the grandparent that every executive will either know, or have a really good idea that a layoff is coming, well before 2-4 weeks prior, even if the internal finance/HR process hasn't quietly, officially started yet.
> 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.
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.
I agree.
Do you have metrics available somewhere? Doesn't matter real-time or N days report - people can connect the dots: signs up are flat, but we keep hiring.
You can't meet requirements without marketing pushes? Well, shit, I wonder if a company spends 2 dollars to earn 1 dollar.
You can lie and bullshit all you want, but your reports and their reports will know.
I worked in a company where the analytics team suddenly decided to leave, all within days of each other. Month later - layoff. They weren't told that things are bad, they were the one who told you that things are bad.
Maybe they simply found out that you kept lying to them?
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.
Word spread pretty quickly through various cliques in the company. Some teams had no idea what was happening, other teams lost literally all their developers and and couple managers over the course of 30 days.
During my exit interview I mentioned the dishonesty and they just doubled down that I was imagining it.
Isn't that what you did?
> Even though the company eventually did go under due to bad investments the owner made.
I think we are all very obviously not at all talking about the kind of situation you describe.
I left a company a little over a decade ago where the CEO and CTO (both co-founders) were lying to us about the company's situation for the better part of a year (which was longer than half the company had been employed there). I fortunately haven't had the chance to run into them since then, but I would absolutely give them the cold shoulder if I did. And that's because of what they did. I put in 80-hour weeks (including many weekends)[0] for over a year at that place, and they repaid me with a middling salary and worthless equity (after all common stock got wiped out less than a year later when the company got sold to one of the investors for peanuts and scraps).
Anyway, the one "nice" thing I can say about that CTO is that after they had a layoff (half the company), and I didn't get laid off, I went to the CTO and volunteered, and he let me go with the 4-week layoff severance package, which gave me a much-needed month off while I found another job.
(Speaking of startup equity, I'm just glad I wasn't quite out of college during the original dot-com crash, when colleagues I would meet a few years later ended up underwater on the loans they were encouraged to take out in order to exercise their company stock options. I can totally imagine wide-eyed 22-year-old me falling for a garbage scheme like that.)
> People can be very irrational and will look to blame someone in charge when bad things happen.
And sometimes blaming the person in charge is correct and rational.
[0] All stuff I will never again do for any company after that experience...
Not really. My words were some people will hate you even if you do everything right. This was an example of a situation that was handled right but the person ended up hating me and slandering me for years afterwards. Just because I would not allow the company to fund their get rich quick scheme instead of their job.
I've even found people that I did not manage that got fired blamed me sometimes. Like all of mgmt was some evil cabal that conspired together to fire them cause thats what we really want instead of making the company money so we can all get out paychecks.
What people are doing is going off on a tangent of how they don't agree with how I handle the grey area stuff. There is a great deal of Silicon Valley worldview going on as well. The majority of the working world has lots of politics and pettiness going on along with power struggles and backstabbing. You cant be S.V. idealistic and keep your MGMT job in the middling business world.
Are you ok with employees and reports reciprocating by lying to you as well.
I have quit jobs where my manager lied to me. It is really really easy to tell when someone is lying.
You seem to live in some alternate dystopia where everyone lies to each other. How many of the companies that you have worked at have gone under?
If you create a culture where you lie, then people will lie to you.
If you create a culture where you are honest, people will be honest back to you.
There's nothing more powerful than going to your team and saying "Look, I fucked this up. I need your help". Honesty is disarming.
I'm in a field where I manage scientists. If people start to lie to me or even start to bend the truth a little, we will waste years chasing ghosts. The people that work for me are very savvy at figuring out what I think might be true and they can always present just the right data to make me happy. I had to learn early on that I need to be really explicit: we need to do good work, it doesn't matter if I'm right or wrong, it doesn't matter if they're right or wrong, all that matters is progress.
So no. Your employees don't need to lie to you. Mine come to me regularly and explain what went wrong. Judgement-free. And we do deep dives to prevent problems in the future.
You are causing the problems, not them.
I had a junior EE come and find me while I was on a smoke break to immediately inform me that he had mixed up two connectors and had accidentally put 48V into a piece of kit that could only handle 12V, resulting in $10k worth of blue smoke. That’s what a high trust engineering org looks like. He could have lied about it, I didn’t see it happen, “I dunno I went to reboot it and it didn’t power back on”.
That’s what I want to see. He was open and honest with me because I don’t feed him bullshit.
When you've been lied to enough you stop believing the lies, a leader who can't be relied on to tell the truth unless it's positive might as well not say anything at all or be there in the first place. Having to doubt and read between the lines for each and every message from leadership is a waste of my time and leads directly to me A) no longer caring and B) not trusting my leadership.
This kind of manipulation only works on stupid or inexperienced people.
There is a big difference between putting a hopeful spin and always fighting for the best outcome and straight up saying everything is fine until there's nothing left but ashes.
I would argue the opposite: transparency is one of the biggest part of your job. You're not in a leadership position, and it's your choice: do you want an opaque company where politics drive individual success? Or do you want a transparent company where employees respect their leaders and where the best insight wins?
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.
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.
This I do agree with. Many CTOs don't actually have the entire engineering organization under them in the reporting chain (at a reasonably-mature company; not talking about a startup where the CTO is often one of the co-founders and runs engineering), so they have no real power to get other people to do what they think should be done.
At best they have an "Office of the CTO", or perhaps run the company's software architecture group (if the company even has one), and then they just have a tiny army of people who try their hardest to convince other teams to do things that aren't in their roadmap and would mean pissing off their bosses if they took them on. Not fun!
A lot can be achieved by aligning themselves with successful projects and crapping on others at the start or just at the cusp point of success or failure.
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.
> Transparency is not your job.
> You're job is to keep telling your reports that everything is on track no matter what
> This will 100% require lying or being non-transparent at some point.
To add my 2 cents I kind of agree. When I first got into management, I didn't realise how many fires they were, or priorities I needed to balance. Initially I thought "there shouldn't be this many fires" but I soon realised that that was my job, to put them out, escalate when required, etc all while making sure the ship is steady and doing it with a smile on my face.
Some examples include:
- News that a sales person has sold a huge project which will save the company, but we can't deliver or build with our current backlog / resources
- One key team member has been taking a lot of doctor's appointments recently - and suspect they might be quitting / job hunting
- There's a very obscure security issue which could be fatal if discovered, but is a huge task which will disrupt a project which is already delayed and over budget
If I ran into any of these when I first started I would have freaked out - and that would have disrupt my team as they couldn't be productive with that anxiety over their heads.
Instead I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Of course if something was too big to handle I'd escalate, or if something blew up I'd take responsibility etc - but I think job #1 in management is to shield the team from distractions and let them do what they're best at doing.
However, in the absence of some legal requirement to keep quiet, if some employee got wind of one of those situations, and came to you and asked you about it, I really do hope you'd be honest and forthcoming. Because otherwise I think that's when you'd cross the line (for me at least) into being untrustworthy.
One thing to mention though: in the case of your first example, if that huge deal really is going to fall through, no question, and the company is going to fail because of that, no question, I would lose all respect for an executive who didn't pro-actively have the hard talk with employees about that situation. Yes, some people will leave. But that's life, and your employees have entrusted their livelihood with you; you owe them that level of honesty.
> I just had to be confident that I could put out those fires, or put in place strategies to mitigate them, and let the team know it's all under control.
Which is fine! Because if you truly did put out those fires, or at least put in place some mitigating strategies, then you were absolutely telling the truth that it was under control.
> I think job #1 in management is to shield the team from distractions
The difference is that some "distractions" can have a material impact on those employees' lives. An executive who hides those things and lies about them to employees is not worthy of respect. For "distractions" that truly are just distractions, sure, fine, no need to broadcast.
But I think a key question is: if a bit of news could make a reasonable employee, thinking logically about the news, decide to quit, then... you absolutely should be disclosing that news. Anything else is just a betrayal of the implicit trust an employee must have in their employer.
And yes, I know all this might seem pretty idealized, and I know there are a lot of companies and executives who won't get these things right. But that doesn't mean I want to work for those people.
I do think scenario #1 is interesting to talk about though.
I.e. If I was that manager receiving that news, I wouldn't outright tell the devs and say "it could be crunch time for the next 6 months", which might cause a panic and devs will start looking for other jobs.
Instead I'd call a meeting with leadership / sales, see what was sold and if there's any flexibility on deliverables with the client. If we need more resource, is it worth finding funding to hire more staff, or maybe postpone another project to get this higher priority one done.
Once that's resolved then I can think about delivering the news. Maybe it's a non issue (e.g. a new team is spun up to handle the project and someone gets a promotion to head the team), maybe it's crunch time (in that case it's time to have a difficult conversation with the team), or maybe the client is flexible on delivery (so it's business as usual).
Again, I could see how some managers would be uncomfortable not telling their team everything (and potentially cause unnecessary panic) - but I think that's part of management, knowing what level of detail your team are happy with, knowing what you can / cannot handle, and knowing how to delivery good / bad news and sometimes having to be the bad guy.
What scares people is uncertainty. Not uncertainty of outcome (50% chance this will save us). It's uncertainty of what the options are, what the roadmap might be. That's the job of a good manager. Insulate the team from uncertainty and politics. Figure out the space of options, what the outcomes can be, negotiate it with leadership, and present a reasonable and clear plan to the team. That won't cause panic.
Show the team the plan, its rationale, and what needs to be done. What the upside will be. Let them take ownership of it. Let them make the lower-level decisions of how to split time, of what to prioritize, of what edges can be cut. With your feedback.
People generally don't bail when faced with a challenge. They like challenges. You just need to define the challenge clearly and set the path for overcoming it.
Yes I did for the most part. I was replying to another persons wording though so many people have gotten out their pitchforks.
Gross. I worked at at company where the CEO and CTO were hiding important things about the company from employees. When we found out, we felt lied to and betrayed, and there was a mass exodus. The company folded less than a year later.
I'm not saying leadership should be telling employees every little tiny thing. (And certainly some things just cannot be talked about in early stages of the deal, like funding rounds and being acquired.) But employees should have a pretty good handle on the health of the company and what's going on at a high level.
If employees get anxiety or start looking for new jobs because the executive team is being truthful, then either a) the company is doomed, and only an asshole executive would lie to keep employees around, or b) the company is just in a difficult spot, but leadership is not doing a good job of communicating the solid, likely-to-succeed plans in place to get things back on track.
I refuse to work for leadership teams who are not transparent. If they don't think they can trust me to act well in the face of difficult information, then I don't see why I should trust them to run the company that's responsible for my paycheck and livelihood.
Once you peek behind the curtain of where your firm's cash comes from and where it goes, you have to live with a deep existential fear that you could mess up a bunch of people's lives... and you don't want others to have to live with that.
I could not even finish reading this comment. As a C-level leader in an organization, communication should be your strong card. It's unacceptable that you don't even know the difference between "you are" and "your".
If as an employee I get an e-mail from a "CTO" consistently getting confused with such elementary, trivial shit, I would fucking resign immediately as that makes it evident that the organization is led by illiterate people and has absolutely no future.
I do know the difference though. I probably copy/pasted part of the comment around and missed that I changed the context. Shame on me for not proofreading my internet comment though. You should probably erase me from existence for my lack of vigilance as punishment...
Totally destroyed morale, made the best people leave, and created a toxic work environment where there was no trust in management at all.
If that’s your goal, good work I guess.
Then you didn't have a CTO like me. I'm still in regular contact with most of the people that used to work for me. One actually just texted me this morning to ask how I was doing. Even though our lives will almost certainly never intersect again.
I've been CTO/equity partner/division director/tech lead/IC/etc... and this is terrible advice. The one thing you need as a leader is trust - your people need to trust you and you need to trust them. Treat people like the adults they are, tell them what's happening to the best of your ability, and people will work their asses off to accomplish the goal.
> 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.
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.
There’s a variety of options available to you, options that can deliver the best outcome for the business, your reports and yourself — many of which can be fantastic outcomes for all.
Ultimately, building a business is a relay and you will at some point have to pass on the baton: if you fear that inevitability, that needs to be an immediate focus. What can you do to ensure that you can pass the baton on with confidence?
Positioning yourself as not “the CTO” but rather “the person establishing the business’ approach to technology” (which is achieved by utilising the CTO role today) can be a very powerful shift in attitude: you’re setting the technology organisation up for the baton to be handed over to the person ready to lead the next stage with confidence.
If I were in your position, I’d be talking with the other leadership in the business and clearly communicating that you don’t want this role indefinitely, I’d put a plan together for the next 12 - 18 months that involves bringing someone in to replace you, someone for you to pass the baton to.
A bad outcome for the business would be you spending the next 12 months silently stewing in your own anxiety and fear and then have a breakdown and disappear without any notice and the business is thrown into chaos.
As a leader, you don’t need to be perfect or a brilliant jack of all trades or a genius or even the smartest in the room, but you do need to operate with confidence though. If you don’t have confidence in something, focus on getting the confidence.
(For what it’s worth, the shift from where you are now to where you need to be is almost exclusively in attitude, it’s not some insurmountable challenge.)
No first time CTO's had it figured out either - continue to show the courage to ask advice (as you've done here) and figure it out bit by bit. Nobody has made your org before - there's no playbook only prior work.
The flip side is if that is of zero interest, you're likely in the wrong role. No shame, depends what motivates you.
Presumably, you don't have to do it if you don't want to. If that's true, be nice to yourself and remember that on a regular basis :)
What you've described is pretty much the way many CTOs would describe the job. Don't worry. Treat it like any new discipline. Seek out expertise and learn from it. Make notes and crib sheets and read them regularly (they might be about financial management, or about people management, whatever you need).
Find a mentor if you can.
Don't burn out.
Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
Lying is shitty. Really, really shitty. Think about it.
Doubt is normal, but check yourself for imposter syndrome on the reg.
Ask yourself: what do you want?
If you don't like who you're becoming, move on.
Good luck :)
The reason I became a CTO is three-fold:
Firstly, I was recommended for the position by the managing director of a large (the largest?) Swedish games company, so I figured it was a once in a lifetime opportunity.
Secondly, I asked my old CTO if it was a good fit for me as I’d been a manager before and I felt I preferred IC, I also have an abrasive way of communicating which worried me greatly, his response was that the abrasive parts of my communication style will melt away because it is bore out of frustration.
Finally; I have worked in meritocratic cultures but only when there was significant external political pressure from the publisher. Theoretically I could replicate that culture but without the political cruft; additionally I would be in a position to set the company up with long-term technological investments and partnerships: which I was trying to do before but managers are usually focused on short term goals.
> Find a mentor if you can.
> Don't burn out.
> Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).
> You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.
This is good advice and I appreciate it greatly, I will wear these words going forward.
Thank you. :)
One thing that has helped me, and may be helpful to you as well, is to look at your new role as an engineering problem. Logistics and process may not feel technical but they 100% are, and if you approach them with the same problem solving mindset and intellectual curiosity as, say, a coding task, you will enjoy them a lot more, and may even find that you become very successful at them.
The first job of an SVP is to stand up to the CEOs when they are pushing for impossible deadlines.
The second job of the SVP is to stand up to CFO when they want layoffs. Or fight for more resources when they are pushed to the limit.
The third job, arguably the only thing that is technical, is to stop your sub coordinate pushing for what ever that is hyped in the industry to be used within your company.
It may sound easy in a small startup, doing the above three things in a large company is easily a full time job.
Personally I think having a CIO makes a lot of sense, even if you ditch the CTO, CISO, CDO, CAO panel that is generally subordinate to the CIO anyways.
> CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality.
This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time.
A real head-shaker for me.
The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.
The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement.
One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established.
But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages...
I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't.
But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.
~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out.
The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time.
In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.
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.
Meaning a CTO should also be good (not great) at sales, marketing, cash flow, customer service, user experience design, etc.
Being well rounded means being able to garner the respect of not only the engineers but all stakeholders, from internal people to the customers to the general public, too.
I’m certainly not arguing that a great engineer won’t make a great CTO. It should probably the area they’re strongest in.
But if I had to pick between an amazing engineer who knows nothing about the rest of the business, or a reasonably knowledgeable CTO who is also reasonably knowledgeable on all other fronts, I’d pick the latter every time. No hesitation.
There is a caveat to this, though. Being a generalist means recognizing that on any given topic, someone knows better than we do. So you have to be able to recognize that and defer to expertise, while also completing the picture by thinking about all the variables that lead to a business being successful.
I’ve met plenty of engineers (and designers and copywriters, etc etc) who think everyone else’s roles are easily understood and accomplished. That’s fine if you’re a specialist. But a leader needs to understand the big picture, and no one is an expert in all areas. It’s just not possible, by my estimation.
Dropbox is a technology company. This is famously a place where deeply technical leaders can achieve competitive advantage. The whole company exists to support the tech, so if the tech fails, bad.
Uber (and most startups really) don't do tech, they use tech to drive sales. Of course the tech is important but it's a solution not a driver. Here I agree that a "well-rounded" tech-average CTO can be advantageous.
Tech strategy is where everything converges. If products literally live or die by it, you better have a crack technologist at the top.
I think you make a great point either way. I’d elaborate on that and say a business leader needs to deeply understand the product they make/sell, so if your core product is tech, I agree and see your point. But I still think they need to be really good at all facets of the business. They still need to understand the market and how to promote and how to close sales. Those skills don’t really develop if the only thing you do is engineering.
Take HubSpot’s CTO Dharmesh for example. Brilliant engineer! But he applies his curiosity to understanding people and markets and solving unsolved problems. He understands the whole business. He also understands his own shortcomings and surrounds himself with people with complementary skills, because he knows full well that engineering alone isn’t enough.
I think the role of the CTO varies based on the scale of the company.
This article on the types of CTOs is useful framing: https://www.allthingsdistributed.com/2007/07/the_different_c...
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.