Live data from Hacker News

A CTO should be technical

blog.southparkcommons.com

281–290 of 367 posts

Re: A CTO should be technical

#281
Toppers in hackerrank, leetcode created any products that is used by millions? Coding test or any test in that matter can't be used to measure a person intelligence. Because we are yet to understand & define what is intelligence?. To be successful in any job, you need a passion in it, working with people & audacity to bring in change.

Re: A CTO should be technical

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

Re: A CTO should be technical

#283

This really is a one-sided view. I'm not saying it is an incorrect view, but I find that all dogmatic stances are only correct part of the time. Some small companies need a technical CTO. Large companies need a leader who can effectively delegate the technical aspects to his organization. Companies in the middle... will vary.

If the CTO isn't technical, how do they know what to delegate? Who to delegate to? How do they determine who to listen to?

Think about it via an analogy - do you know how to fix your own plumbing? If not, how do you know who to hire to repair your home? In short, you look at what they have done, listen to people who have worked with them, and react accordingly. Once you have hired someone, you have your own direct experience with them and can judge for yourself whether or not their work met your needs. If they meet your needs, then the relationship is working. If not, it isn't so you let them go and find someone else.

Technical people looking up from the bottom often expect some type of meritocracy where being good at your job earns you promotions and responsibility, but that isn't really how leadership works. When you are trusted, you get promotions. For exactly the reasons stated above - leaders delegate to people they have worked with before and trust that the needs will be met.

So as a leader, decide who you trust. As someone lower down the chain, work to build that trust.

Re: A CTO should be technical

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

My current job, during the interview, didn't ask me to write a single line of code, but instead asked me to walk through (in great detail) how I'd go about building a GPS related feature for an application that they own. The application is well known and the problem space was well defined. This was a real (low priority) problem that they did eventually plan to tackle as a team.

I also at the same time, interviewed with the fastest growing startup in the area, who had way better comp, slightly better benefits, etc. They asked me to do a take home homework assignment that would've taken like 20 hours, so they could see how I work.

I ghosted the second contact, and after another round of interviews, accepted with the first company, and I'm by far happier with my work and the respect given to my input at this job than any previous one I've had. I'm certain that wouldn't have been the case at the latter company.

I truly believe that once you are beyond the junior level, interviews really are a two way street, and you should jump with the utmost caution unless you already dislike where you are.

Re: A CTO should be technical

#285
post #282
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 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 te…

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.

Re: A CTO should be technical

#286
I feel that as a CTO a lot of the respect I earn from our developers comes from me having a deep technical understanding not only about how things can be done, but also about the pitfalls and obvious issues that can make something fail.

My experience as a software engineer definitely allows me to approach issues in a more understanding way and find alternative solutions that accommodates for them instead of finger pointing and shaming.

I think a CTO should have a good understanding of the topological structure of the systems they're effectively responding for, and they should have an understanding of the feasibility of roadmaps.

A CTO without technical knowledge cannot provide suggestions or iterative steps when some plan goes south other than generic coaching. I've been in a lot of cases where our developers were stuck because they couldn't make decisions outside of their team.

I feel my job isn't to simply respond to the CEO but to ensure that friction is removed between the teams. I would simply be unable to do this properly if I wouldn't have a deep understanding of what every team is working on, how their systems connect, how their stacks work and what budget constraints we have (also what impact an alternative course would have on the budget).

If your CTO is 10 levels removed from the developers that's a different thing, because then the job of the CTO is nothing but a glorified proxy for their direct reports to the CEO.

Re: A CTO should be technical

#287

Earlier quoted context omitted.

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

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.

Re: A CTO should be technical

#288

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

I think it depends on the size and makeup of the development team. Smaller startups / teams need a CTO with strong coding and especially architecture skills. Larger orgs probably benefit from a CTO that has a strong product background and management skillset.

Re: A CTO should be technical

#289
Dilbert moment I remember is from a few years ago I was presenting a proposal to create a web app with a bunch of front-end engineering requirements to the "CTO" of a large transportation company once. We covered topics like JSON-LD schema, HTTP/2, responsive images, asset fingerprinting, that the solution would include and provide etc.

He asked us why we can't "build the website on wix".

Re: A CTO should be technical

#290

Earlier quoted context omitted.

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

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…

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

Post reply on HN