Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

Post reply on HN
Print view View original

191–200 of 367 posts

Re: A CTO should be technical

#191

Post by [deleted] »

skipidarink wrote: post #190
warent wrote: post #180

Earlier quoted context omitted.

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

> Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you." And so you take your first step down the path.. "I'm not sure" is a lie here.

[deleted]

Re: A CTO should be technical

#192

Post by ajmurmann »

colechristensen wrote: post #88
givemeethekeys wrote: post #43

Earlier quoted context omitted.

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

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.

Re: A CTO should be technical

#193

Post by WheelsAtLarge »

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

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

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

Re: A CTO should be technical

#194

Post by baby »

citizenpaul wrote: post #90
baby wrote: post #84

Earlier quoted context omitted.

> Transparency is not your job I would argue the opposite: transparency is one of the biggest part of your job. You're not in a leadership position, and it's your choice: do you want an opaque company where politics drive individual success? Or do you want a transparent company where employees respect their leaders and where the best insight wins?

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

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

Re: A CTO should be technical

#195

Post by yshrestha »

Putt's law:

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

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

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

Re: A CTO should be technical

#196

Post by warent »

skipidarink wrote: post #190
warent wrote: post #180

Earlier quoted context omitted.

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

> Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you." And so you take your first step down the path.. "I'm not sure" is a lie here.

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

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

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

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

Re: A CTO should be technical

#197

Post by skipidarink »

warent wrote: post #196
skipidarink wrote: post #190

Earlier quoted context omitted.

> Just tell my IC "I'm not sure why your work was invalidated. Let me look into it for you." And so you take your first step down the path.. "I'm not sure" is a lie here.

Why do post mortems happen for production issues, when you could just open up "git blame?" Are you lying to the team when you say, "we're not sure how this happened" rather than just quoting the git blame? Well, no. The problem is much more complicated than a buggy commit. It's a wider problem with the system. So you say "we don't know, we have to look more into it" and do a post mortem because that is the honest tru…

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.

Re: A CTO should be technical

#198

Post by ytpete »

wpietri wrote: 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…

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.

Re: A CTO should be technical

#199

Post by random314 »

citizenpaul wrote: post #115
random314 wrote: post #71

Earlier quoted context omitted.

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

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

Did you just agree that you are a toxic manager?

Re: A CTO should be technical

#200

Post by dicriseg »

dijit wrote: 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…

Is this your first time managing people as well?
Post reply on HN