Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

261–270 of 367 posts

Re: A CTO should be technical

#261

NEVER work for someone who is incapable of doing your job. To do so is to construct an extremely dangerous, brittle situation. This doesn't mean they SHOULD do your job, or HAVE to - just that, they could - and are therefore qualified to manage you - while you do it. The Peter Principle is real, and legitimately a source of massive waste and inefficiency in the world. Simply refuse to work for someone that cannot do…

The Peter Principle is explicitly about the risks of someone being promoted into a role they can’t do because they were good at a role they could do.

People should be made people leads because they are good people leads, not because they are good ICs.

Re: A CTO should be technical

#263
post #40

Earlier quoted context omitted.

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

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

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.

Re: A CTO should be technical

#264

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…

Because bad organizations conflate leadership and dominance. 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.

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.

Re: A CTO should be technical

#265

> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel. People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on. I agree with the premise of the article, CTO shoul…

It has to be a function of company size here. If your company employs 100s of engineers the value-add of any CTO/VPE shifts from hands on technical to a more strategic view. If your company is in that 20-50 engineer range, having a CTO who is deeply and personally vested helps the entire team ship features to those critical first few customers.

Re: A CTO should be technical

#266

> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel. People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on. I agree with the premise of the article, CTO shoul…

The director of marketing in my firm has a PhD in Physics. Every technical talk with him is a breeze. He gets data, complexity, the fact that sometimes easy problems are hard and that tech needs proper support. Point being: management skills are not technical skills, but technical skills or affinity sure help. Perhaps smaller firms the CTO should be a good programmer, but in any firm the CTO should be the one standing for tech and building bridges between tech and non-tech.

Re: A CTO should be technical

#267

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…

> "You're job" 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 organiz…

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.

Re: A CTO should be technical

#268
post #252

> So let me put it plainly: the CTO/VPE/Engineering Director candidate should pass your coding interview. In fact, they should excel. People who work full-time as developers spend hundreds of hours practicing leetcode and hackerrank so that they can pass the interview, but a CTO who's 5 levels above and hasn't logged to Github for 3 years should excel at it? Come on. I agree with the premise of the article, CTO shoul…

Developers spend hundreds of hours practicing leetcode and hackerrank? Are they actually good coders? And that's required to pass an interview? I feel so out of touch. I haven't interviewed very many candidates, just a couple dozen maybe, but I've never heard anyone mentioning leetcode or hackerrank. If they'd admitted they'd admitted they spent that much time on there, I'd be seriously questioning why they didn't sp…

thats the norm for faang. fresh college graduate but any kind of IC will be expected to know how to do white boarding LC hard.

Re: A CTO should be technical

#269
post #252

Earlier quoted context omitted.

Developers spend hundreds of hours practicing leetcode and hackerrank? Are they actually good coders? And that's required to pass an interview? I feel so out of touch. I haven't interviewed very many candidates, just a couple dozen maybe, but I've never heard anyone mentioning leetcode or hackerrank. If they'd admitted they'd admitted they spent that much time on there, I'd be seriously questioning why they didn't sp…

Leetcode and Hackerrank I think, if they're used anywhere, are very much a Silicon Valley kind of thing. I've certainly never been asked to go near them when interviewing for startup jobs in the UK, and never used them when hiring myself. They feel very much like the sort of thing you use in an environment where you've got way more qualified candidates than you have open positions, so you're optimising for screening…

I think it may be a policy for some larger firms, even if there is little available talent in the local market. Here in Sydney there are next to no C++ experienced developers (I am hiring), yet some firms insist agencies make candidates do leetcode tests even before someone actually from the firm will even talk to them.

Re: A CTO should be technical

#270

NEVER work for someone who is incapable of doing your job. To do so is to construct an extremely dangerous, brittle situation. This doesn't mean they SHOULD do your job, or HAVE to - just that, they could - and are therefore qualified to manage you - while you do it. The Peter Principle is real, and legitimately a source of massive waste and inefficiency in the world. Simply refuse to work for someone that cannot do…

The Peter Principle is explicitly about the risks of someone being promoted into a role they can’t do because they were good at a role they could do. People should be made people leads because they are good people leads, not because they are good ICs.

The Peter Principle equally applies to those who have to serve under others who were promoted out of their competence zone. It works in multiple ways: don't allow yourself to be promoted outside of your competence zone, don't work for those who have been.

>People should be made people leads because they are good people leads, not because they are good ICs.

Good people leads don't lead people whose jobs they can't do. That's the point: if your boss can't do what you do, he's not leading - he's letting you lead, while following along on an elevated, speciously constructed platform.

Don't fall for it - always demand competence from your own leadership.

Post reply on HN