Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

121–130 of 367 posts

Re: A CTO should be technical

#121

Earlier quoted context omitted.

> Transparency is not your job. > You're job is to keep telling your reports that everything is on track no matter what > This will 100% require lying or being non-transparent at some point. Following this advice is another way of loosing employees, at least I'd leave a company quickly if the CTO started lying about potential problems not being problems. In the end, depends on the company. Usually the company I've wo…

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

"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?

EDIT: slight revision

Re: A CTO should be technical

#122
post #94

Earlier quoted context omitted.

Curious to know where the statement "real life is not fair" is coming from / what it's referring to.

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

What part of the world are you from?

Re: A CTO should be technical

#123
post #78
post #37

Earlier quoted context omitted.

> but I fear what will replace me if I leave So you'll never retire or die?

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)

Re: A CTO should be technical

#124

Earlier quoted context omitted.

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

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

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

Re: A CTO should be technical

#125
post #82

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager. As an engineer and a manager I took my time to understand the basics of management, design, marketing, business development etc. to have educated conversations while building a product so I don't see why someone in those roles shouldn't…

i worked for a non technical manager, and it was ok. because he trusted his employees. he said this is the deliverable, and these are the constraints, what do you need, who do you need, and how much do you need. we told him, and he went to fucking bat. obviously he picked up a little here and there, but by no means could do the job of a junior.

it worked well, he shielded us from the corporate politics, got us everything we needed, didn't over commit us, and we delivered on estimated dates and to scope almost every time. because we picked times and materials and he made sure it happened and that we could focus. was good times

Re: A CTO should be technical

#126
post #25

Earlier quoted context omitted.

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.

Dropbox also completely lost the market they invented to Box, largely because of nontechnical considerations.

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.

Re: A CTO should be technical

#127
post #109

Earlier quoted context omitted.

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

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

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.

Sorry but the reality of human nature is tough.

Re: A CTO should be technical

#128

I am a CTO, and have been for 20 years. 20 years ago I was co-founding a company, so that kind of CTO was very different than the CTO I am today. Starting a company meant I was the technical part of the company. Raising money, talking to VCs, customers, hiring, and all of the other usual growth stuff. Of course I developed code, architectures, plans, deployments. I deployed, installed network switching gear, configur…

Also, learning to dodge coffee chats so you have time to actually study and keep up with the times in tech.

Re: A CTO should be technical

#129
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 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 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.

Re: A CTO should be technical

#130
post #82

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager. As an engineer and a manager I took my time to understand the basics of management, design, marketing, business development etc. to have educated conversations while building a product so I don't see why someone in those roles shouldn't…

> I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager.

I agree, but in my case I think there's also a "narrow band" for what I'd consider a technical manager to be. I want them to be able to understand if, at times, I need to get into the weeds describing a technical problem. I wouldn't do this often; I don't think it's necessary or useful to burden a manager with deep technical details most of the time. But I want it to be possible to do that when necessary, without seeing the manager's eyes glaze over.

But at the same time, I also want a manager who is primarily focused on the "people" aspects of management. Engineering managers should not be coding, or even doing code reviews. Part of it is because I don't believe managers should be in so deep on the technical details, because to do so means taking too much valuable time from people management duties. But the other bit is that I don't like the power dynamic. I don't want a manager to force -- or even have the unconscious appearance of forcing -- a report to change some code in a code review because they have the added "I'm the guy who decides if you still have a job" power. And in the reverse interaction, if the manager is writing code, I don't want their reports to have to walk any kind of "don't piss off the boss" tightrope when providing code review feedback.

The power dynamic bit is a reason why I also think that a team's technical lead (for orgs that have tech leads) shouldn't report to the team's manager, but should report up a level. I think it's valuable if the technical lead feels like they can argue against the team's manager's opinions without being afraid of (even unconscious) retaliation.

So I think it's hard. Another top-poster here (the CTO of Surescripts) seems to have it right: when he's at work, he focuses on people and the business, with the technology an important part of the job that he doesn't dive too deeply into (but can still hold his own in technical discussions). And he keeps his technical/engineer side happy through deeply technical side projects on his own time. I think that can be really hard to do, especially for an former developer who is new at the manager job. (Not to mention having deeply technical hobbies and side projects takes up a lot of spare time, spare time that many people may not have.) But I think it's essential for having a healthy team with reports who respect their manager, and understand that the manager respects their technical expertise, and doesn't try to dictate technical decisions.

Post reply on HN