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

Why I code as a CTO

assembled.com

Post reply on HN
Print view View original

201–210 of 304 posts

Re: Why I code as a CTO

#201

Post by ghaff »

eitally wrote: post #169
sa-code wrote: post #115

Earlier quoted context omitted.

> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie. This bit got me. It's a direct quote from the linked post for those who haven't read it

This can work, imho, IFF the organization has both a CTO and CIO (or someone else tasked with managing the org). I've seen lots of places where the CTO is purely the technical visionary/advisor/final decision maker, and doesn't directly manage the technical organization. This scenario is far more common outside of the tech industry, where you usually have a CIO running the IT cost center, and a CTO making decisions a…

CTO, CIO, and the head of engineering (the latter of which can often be split among different groups) are often very distinct things, especially at larger companies. And, yes, while the CTO probably has a seat at the table for technology direction is often primarily a public technology face of the company as opposed to someone involved in a lot of hands-on day to day technology implementation.

Re: Why I code as a CTO

#202

Post by paulryanrogers »

fooster wrote: post #163
prerok wrote: post #96

Earlier quoted context omitted.

You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so. I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.

Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.

> If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok.

If the CTO has rank then why not work to solve the unresponsiveness or undesirable things?

If someone--even a founder--can act as a loose cannon then there is a risk that they'll introduce problems like instability, security vulnerabilities, or unnecessary conflict or resentment. Compliance programs like SOC and PCI don't look fondly on staff bypassing SDLC processes because of those risks.

Re: Why I code as a CTO

#203

Post by rzzzt »

raw_anon_1111 wrote: post #155
ChrisMarshallNY wrote: post #119

Earlier quoted context omitted.

That’s not a role that I’d normally associate with “Chief” anything (which, by definition, means direct reports). More like Principal Engineer, or Architect. In smaller companies, this is probably fairly normal, but you can’t maintain this, as the company grows. I had a similar path, in my career. I originally started as a regular engineer, in a two-person team, and eventually ended up managing a small team of up to…

The happy medium that the CTO did at the company where I worked where I was the architect guiding the technical direction, he would do non production level experimental coding as research - integrations with third party APIs, see if an AWS service was suitable - to take some of the load off of me hand the code over to me and I cleaned it up and made it production ready and championed it to the rest of the teams. He s…

Isn't this the fun part?

Re: Why I code as a CTO

#204

Post by solodev222 »

I respectfully agree with many of the comments here, but I can also recognize the value and effort of someone sharing their experience. It shows character, boldness and opens up dialogue. People are central to any effort in accomplishing a certain goal, even if it is a single individual. Organization is meant to facilitate the joint effort in accomplishing the common goals in a structured and systematic way. Having had the experience of taking technical leadership without the title or stake on the company, I still value people who actually care. And that is precisely what I can extract from reading this post. Keep the genuine love for the craft going, don't let yourself down by people who don't get it.

Re: Why I code as a CTO

#207

Post by paholg »

dangoodmanUT wrote: post #185
CobrastanJorji wrote: post #67

Man, if I'm trying to decide which company to work for, and I see a blog post from its CTO crowing about regularly checking in code on Saturdays and Sundays, I'd start backing slowly away. And when I got to the bit that said "AI has made me three times as productive," I'd turn and run. Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not…

It seems like you're confusing technical founder CTO at a startup with professional CTO at a large org. For the later, what you said makes some sense, and it definitely seems like you're more familiar with this archetype. For the former, the article appears correct. If you've not worked at an early stage startup before, the culture is _very_ different. As a side note: This article is doing it's job. People that are a…

At an early stage startup, shipping a feature should not require "many meetings across product, legal, and engineering". Especially not one that can be mostly built in a day.

Re: Why I code as a CTO

#208

Post by cantor_S_drug »

dbbk wrote: post #129
sa-code wrote: post #115

Earlier quoted context omitted.

> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie. This bit got me. It's a direct quote from the linked post for those who haven't read it

Then why are you the CTO!! Dude just wants to be a staff engineer

How big is assembled in terms of headcount? That should resolve most of the questions we are raising.

Re: Why I code as a CTO

#209

Post by BoxFour »

submeta wrote: post #200
BoxFour wrote: post #149

Earlier quoted context omitted.

I don't think this is a really convincing argument: There are plenty of leaders who haven't "done the job" in decades, and we don't question that. It's incredibly common in professional sports, for example. Mike McCarthy hasn't played a down of American football in 40 years, and never played at a very high level. But we don't question his ability to get others to perform complex motions.

This is not really a good analogy. Tech is different. I am not saying you should sit down and write code. But in IT you know the difference between a tech lead who knows technology, who knows what works, for what reason. And the one that just demands results but knows nothing about the details of the technology. Has never gotten his hands on it.

> This is not really a good analogy. Tech is different.

Why? Seriously: Give me a convincing reason why tech is different from every other field, where this happens regularly.

> I am not saying you should sit down and write code.

But that's the whole premise of this conversation. It's entirely possible to understand something deeply without doing the thing yourself.

It's entirely possible for a CTO to deeply understand technology without writing any code themselves, opening up a terminal, tinkering with anything, or even what individual contributors are doing day-to-day. I would actually say that's the hallmark of a good CTO.

Re: Why I code as a CTO

#210

Post by BoxFour »

icedchai wrote: post #171
BoxFour wrote: post #141

Earlier quoted context omitted.

> it’s not what you do day to day. I don't know about that. I was a "CTO" for a small (10-person) and a slightly larger (around 100-person) VC-backed startup. Hiring was always top of mind at both places. Not even "people management", just hiring alone. I'm not saying this universal, but when a company is expected to scale rapidly (as is often the case with venture-backed firms), managing people can easily consume yo…

As a former "CTO" at a small company and an early stage employee at several others, hiring was a ton of work for everyone. It was honestly the hardest thing I had to do. However, it was by no means a constant, day-to-day thing.

More power to you - I easily spent weeks at a times sifting through resumes and interviewing, and even once someone was hired making sure they were onboarding well and feeling well-supported and etc.

By the time everything was humming along we were either raising a new round (and thus hiring more), or someone was leaving and we had to refill that role.

Post reply on HN