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

61–70 of 212 posts

Re: The Startup CTO's Handbook

#61

Post by thom »

SOLAR_FIELDS wrote: post #10
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…

I was just commenting to a colleague recently about the significant improvements RDBMS have gotten for json support over the last decade. For instance, keys below the first level in Postgres jsonb fields were not indexable around a decade ago. Now you can do GIN index and other options that are rather sophisticated.

Yep, this is a sneaky great feature. Where previously you’d have a sequential scan unless you put in multiple indexes or a bloom filter, you can now get great performance and easy of maintenance at the same time.

Re: The Startup CTO's Handbook

#62

Post by guappa »

mikeshi42 wrote: post #33
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 don't think there's a right answer here, but there's definitely a point where your code contributions are much lower leverage than for example trying to recruit the next set of critical engineers, working on the technical roadmap to keep ahead of the competition, or making sure the engineering org is aligned with the rest of the company. Any lines of code the VP/CTO could write, could likely be written by someone e…

Can you really do any of that if you forgot how it's done?

Re: The Startup CTO's Handbook

#63

Post by guappa »

CaffeineLD50 wrote: post #34
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…

Elon Musk, for example, appears to be wholly self taught as a coder. Do you want Elon doing your code reviews?

I want him to call me a pedo while I'm trying to save people stuck in a cave :D

Re: The Startup CTO's Handbook

#64

Post by guappa »

bob1029 wrote: post #59

> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people. This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the…

You've ever done support calls?

You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.

Re: The Startup CTO's Handbook

#65

Post by hansmayer »

Honestly reads more like a "Handbook for the CEO of a startup that had hit its planned growth targets and now needs to stabilise", the suggestion about 3 types of CTOs and implying therefore that you effectively need 3 CTO-level managers to cover different requirements( Architecture, hiring, etc) is something that you only see at that stage. I was willing to give it a go and read through everything, but mentioning "Agile", with capital "A" as a development methodology finally convinced me that the author has no significant real-world experience in building technical startups. Hard pass.

Re: The Startup CTO's Handbook

#66

Post by hansmayer »

bob1029 wrote: post #59

> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people. This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the…

Exactly - not having empathy towards customer is something our entshittified big-tech platforms can afford, at least for a while. For a nimble startup, that is the path to death. I agree that engineers absolutely should not be shielded away from their design decisions. Not that they should sit on support calls all day long, but spending half a day per quarter in such calls can be very revealing. Some of the best understanding of my customer pains, and sometimes even issues I would have not even aware of, came out of talking to customers, or just listening in to the calls.

Re: The Startup CTO's Handbook

#67

Post by yard2010 »

petesergeant wrote: post #44
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 cod…

I would love to know how and why you made that decision and how it's going for you (good I bet), can you please elaborate?

Re: The Startup CTO's Handbook

#68

Post by JohnCClarke »

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…

Well, what's the time horizon? A PE backed outfit, or a CTO looking to move on within a year or so, would be well advised to follow this guidance. Lots of success now, and the problems deferred to later.

Re: The Startup CTO's Handbook

#69

Post by hansmayer »

guappa wrote: post #64
bob1029 wrote: post #59

> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people. This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the…

You've ever done support calls? You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.

I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.

Re: The Startup CTO's Handbook

#70

Post by bravetraveler »

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…

This may put me and my peers out of work (in a good way). SRE is a consequence of this function being lost, IMO. Pattern: developers don't like it? Give it to Ops/SRE.

Take away the escape, we will all be better for it.

Post reply on HN