Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

171–180 of 367 posts

Re: A CTO should be technical

#171
post #144

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

> Should a conductor know how to play instruments? Of course not, but I was very surprised to read that someone would think this, so I thought I'd check whether it's true. Here are some recentish famous conductors selected from https://en.wikipedia.org/wiki/Conducting ; though I didn't make an effort to select very randomly, this ought to include most of the most famous conductors: - Herbert von Karajan: child prodig…

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

Re: A CTO should be technical

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

Re: A CTO should be technical

#174
post #23

I just became a CTO. So, let me bear my thoughts. Since July of this year I've been CTO for a small games company, I've worked in this industry before in a more specialised role but this is much broader scope. I've gone from being responsible for 1 person to 10 which will likely become 50 by the end of next year. I'm terrified. I'm terrified because I feel like I will let my reports down. I'm terrified because a lot…

I'm curious about why and how you've become a CTO?

Presumably, you don't have to do it if you don't want to. If that's true, be nice to yourself and remember that on a regular basis :)

What you've described is pretty much the way many CTOs would describe the job. Don't worry. Treat it like any new discipline. Seek out expertise and learn from it. Make notes and crib sheets and read them regularly (they might be about financial management, or about people management, whatever you need).

Find a mentor if you can.

Don't burn out.

Don't be a jerk (ignore the more outspoken comments in this thread, you are clearly not well suited to sociopathy, congratulations).

You will not be able to please everyone all the time. You can't be everyone's friend all the time. But you can probably be decent to everyone nearly all the time.

Lying is shitty. Really, really shitty. Think about it.

Doubt is normal, but check yourself for imposter syndrome on the reg.

Ask yourself: what do you want?

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

Good luck :)

Re: A CTO should be technical

#175
post #142

Earlier quoted context omitted.

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

> 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 the…

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?

Re: A CTO should be technical

#176
post #32

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 sp…

> 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 als…

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.

Re: A CTO should be technical

#177
post #129

Earlier quoted context omitted.

I was a CTO once. Transparency is not your job. You're job is to keep telling your reports that everything is on track no matter what everything else is just "rumors". If you don't they will start getting anxiety or looking for new jobs instead of pressing on. This could actually be the difference between what makes things fail or succeed. You're job is not to be transparent or honest. Its to make sure everyone stays…

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 thou…

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.

Re: A CTO should be technical

#178
post #34

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 prac…

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.

Re: A CTO should be technical

#179

Earlier quoted context omitted.

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

>I'm guessing you're not referring to public companies with significant revenue >Layoffs at non Fortune 500 Yeah Literally what I said in my comment.

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

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

Re: A CTO should be technical

#180
post #142

Earlier quoted context omitted.

> 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 the…

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 tel…

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.

Post reply on HN