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

The Startup CTO's Handbook

github.com

Post reply on HN
Print view View original

41–50 of 212 posts

Re: The Startup CTO's Handbook

#41

Post by CalRobert »

Swizec wrote: post #21
femiagbabiaka wrote: post #5

Earlier quoted context omitted.

Great approach. I ctrl-F'd for databases, good info there generally. The only thing that gave me pause: a startup doesn't need to focus on SQL vs. NoSQL in 2025 with such good json support in the most popular SQL databases. Just use PostgreSQL or MySQL -- whichever your engineers have more experience with -- use CloudSQL or RDS which will take care of the hard stuff like backups and replication for you, use read repl…

> use read replicas for BI with a good visualization tool Put up 2 or 3 read replicas, split your queries so writes happen to main and reads come from replicas (supported out of the box by many modern ORMs), and you can scale to millions in daily active users for most startup workloads. Really the hard part of BI is that folks who need the info don’t wanna learn SQL. The ones who can do SQL, will struggle to keep up…

Definitely - I've been surprised at some very complex pipelines built with pandas, etc. because someone didn't want to use SQL...

Re: The Startup CTO's Handbook

#42

Post by rukuu001 »

agnishom wrote: post #38

> 9. Build An Explainer Video Library I am not sure this is great advice. I am sure it makes sense for certain things, like UI or animation. But, generally reading text is more efficient than video watching. It's also easy to seek to the important parts of a text than a video when you are in a hurry.

Some people like videos, some like text. Both are an investment in effort and payoff. Gen AI makes it easy to do both now.

Re: The Startup CTO's Handbook

#43

Post by rukuu001 »

I like things like this not because I'm going to use it as a bible, but because it provides good coverage of responsibilities & concerns.

Unless you've got some great advisers or you worked under someone really great, no one's going to take you aside and give you a list of stuff you need to take care of once you're in this position.

For each section I'm asking - what's our answer to this? Do I agree with this? Is our process better? What have I missed? It's helpful.

Re: The Startup CTO's Handbook

#44

Post by petesergeant »

film42 wrote: post #28

I read all the time about folks who become a VP/CTO and stop coding. Management skills are not coding skills. I know it. But I can't for the life of me figure out why folks hang up their keyboards and let their first super power go to waste. You can be a technical CTO from start to finish. Treat your team and the company like a service that needs active contribution, maintenance, and on-call support; and also, get yo…

> You can be a technical CTO from start to finish

My last CTO role (team of 40) had me absolutely over capacity from day one, and I am _good_ at time management. I would rather have been programming 50% of the time, but there just was no time, and no support structure in place I could hand stuff off to; I had to painstakingly build that, which was yet another reason I had no time.

I like the idea of continuing to code, but usually that’s not what you’re being paid for, and while I consider myself a very strong developer, they can be purchased for less than the CTO’s salary, rather than the more expensive CTO doing the work. FWIW I went back to IC after a few years and plan to stay that way for the rest of my career.

Re: The Startup CTO's Handbook

#45

Post by gorgoiler »

film42 wrote: post #28

I read all the time about folks who become a VP/CTO and stop coding. Management skills are not coding skills. I know it. But I can't for the life of me figure out why folks hang up their keyboards and let their first super power go to waste. You can be a technical CTO from start to finish. Treat your team and the company like a service that needs active contribution, maintenance, and on-call support; and also, get yo…

For me, the hacker super power — the one worth carrying forward as you progress in leadership — is being able to prototype something that works and proves a concept.

Realistically, a proof of concept is also only 20% of the work an engineer needs to do in order for a change to become production worthy and I respect that my sketched ideas need a lot more care and craftsmanship than I have time to give them. Where I can help other ICs is having that initial 20% idea around which they can then build a working idea, and do so autonomously.

It feels very cringey to write — oh brave new world that has such people as me in it! — but I can easily reassure myself by remembering all the times earlier in my career where I was very grateful to be initially pointed, with quite a lot of prompting, in a particular direction and then being given the chance to deliver on it.

I’m just a lead, but I can imagine part of being a CTO takes the same form as what I’ve described.

Re: The Startup CTO's Handbook

#46

Post by whilenot-dev »

film42 wrote: post #28

I read all the time about folks who become a VP/CTO and stop coding. Management skills are not coding skills. I know it. But I can't for the life of me figure out why folks hang up their keyboards and let their first super power go to waste. You can be a technical CTO from start to finish. Treat your team and the company like a service that needs active contribution, maintenance, and on-call support; and also, get yo…

I've also had the experience where the CTO was activly coding, 80% of the code base were theirs, and the company was hiring software engineers who could and wanted to fix up their stuff - there was this true luxury problem for this start-up: bad bugs everywhere, but patient and resilient customers. They found 4 willing engineers with good chemistry at first, at least up until they were constantly vetoed by the CTO in their decisions, because the teams best practices conflicted with the CTO-way of "getting things done" - it's a rigid hierachy after all, and not a democracy.

Re: The Startup CTO's Handbook

#47

Post by borski »

m104 wrote: post #35

Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good. Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer cre…

One thing that we did to account for this was to shift the teams every or every few sprints. It allowed folks to get more experience, still get feedback, since if they built a buggy feature they'd have to fix it, etc.

People seemed much happier with that, because they also didn't get tired of 'always fixing bugs' or never getting the feedback, which you insightfully mentioned.

Re: The Startup CTO's Handbook

#48

Post by ozim »

tptacek wrote: post #3

One way I try to get my head around things like this is to skip to a section I understand deeply and see what they said. Here, the claim is made: Don't try to get a compliance certificate at the last minute. Preparing for and conducting an audit such as for PCI DSS or SOC 2 from start to finish is a lengthy process, ranging from six to twelve months for most startups. Starting early and maintaining compliance is chea…

I think that is what author meant actually.

Downside is there is a lot of startup founders that will need help getting the basics in place.

I worked in place where 2 business guys hired 4-5 freelancers and as freelancers took high salaries not even one of them had any clue about setting up infra or SDLC let alone secure SDLC. They would write the code and not give a damn about anything besides that.

Business guys thought they have great technical guys because they were expensive.

Re: The Startup CTO's Handbook

#49

Post by MichaelMoser123 »

There is a lot of talk on culture fit. Most of the talk on "culture fit" is bringing up a hidden layer of discrimination, of one sort of the other - to the detriment of the companies that are applying these rules. Cultural openness is a factor of success, discrimination is leading into the opposite direction - if you ask me.

> The best leaders track their success rate, are not afraid of admitting hiring mistakes, and will hire slow, fire fast.

in me this brings up the desire to post the picture that JWZ (Jamie Zawinski) is showing, upon detecting a referrer header that points to this site. Look up in google what Jamie Zawinski has to say on Ycombinator... (He is also credited with Netscape's decision to open-source Netscape Navigator, along with most of the work that resulted in the rendering engine for that browser; that's why we have Firefox)

Re: The Startup CTO's Handbook

#50

Post by bboreham »

m104 wrote: post #35

Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good. Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer cre…

I call them “shiny team and shitty team”.
Post reply on HN