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

191–200 of 212 posts

Re: The Startup CTO's Handbook

#191

Post by cyberax »

scarface_74 wrote: post #185
cyberax wrote: post #184

Earlier quoted context omitted.

> A CxO doesn’t want to talk to a sales engineer who is not technical. They want to speak to someone on their level Well, yes. That's why you invent a CxO position (Chief Sales Officer?) or maybe "VP of Engineering" for it. Or you can do the reverse, "CTO" can be a de-facto CSO, and you can have a separate CxO position for the technical stuff. > I’m not in sales. I am the first deep technical person that a customer t…

> This means that you're in sales :) You didn’t have to be mean :) But the other half of my job is leading the project once the contract is signed

There's nothing wrong with working in sales! No kink shaming here.

Startups usually require people to wear several hats at once. That's normal. But suppose that your company grows to be 20 times larger. Would you still be working with customers or directing the projects to implement their requirements?

You probably won't have bandwidth for both roles.

Re: The Startup CTO's Handbook

#192

Post by solid_fuel »

closeparen wrote: post #188
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…

>with such good json support in the most popular SQL databases Wait, was that the reason people were doing NoSQL? JSON support? I thought it was about sharding, write scalability, etc.

Sharding, write scalability, and similar are the technical advantages that can matter at scale (and mattered a lot more before SSDs became so common), but I think for most users the only tangible ?benefit? was the schema less nature.

Re: The Startup CTO's Handbook

#193

Post by scarface_74 »

cyberax wrote: post #191
scarface_74 wrote: post #185

Earlier quoted context omitted.

> This means that you're in sales :) You didn’t have to be mean :) But the other half of my job is leading the project once the contract is signed

There's nothing wrong with working in sales! No kink shaming here. Startups usually require people to wear several hats at once. That's normal. But suppose that your company grows to be 20 times larger. Would you still be working with customers or directing the projects to implement their requirements? You probably won't have bandwidth for both roles.

I’m far from the only staff level consultant at the company. Doing requirement analysis is considered “leading a project”. It’s a billable project assigned to a staff level consultant once sales brings in a customer and usually last 3-5 weeks.

While I’m considered a specialist for “cloud native applications”, I can pinch hit for almost any of our specialties at this level except for migrations.

https://www.linkedin.com/advice/3/how-do-you-conduct-consult...

Once the customer accepts the proposal, then leading the implementation is considered another project that is assigned to a staff level consultant. The “architects” (non staff) are the specialists that lead their “work stream” and are hands on and leading their sub team depending on the size of the work.

An implementation is made up of multiple work streams (epics).

Re: The Startup CTO's Handbook

#194

Post by CaffeineLD50 »

guappa wrote: post #63
CaffeineLD50 wrote: post #34

Earlier quoted context omitted.

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

Lol. Nice one.

Re: The Startup CTO's Handbook

#195

Post by [deleted] »

closeparen wrote: post #188
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…

>with such good json support in the most popular SQL databases Wait, was that the reason people were doing NoSQL? JSON support? I thought it was about sharding, write scalability, etc.

[deleted]

Re: The Startup CTO's Handbook

#196

Post by femiagbabiaka »

cyberax wrote: post #156
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 Ugh. That sounds good on paper, but in practice it can become a problem. You're making your _database_ schema a part of the public API. It's an example Hyrum's Law, people will, sooner rather than later, start depending on internal details of the data representation. And your development velocity will crater, as you'll now need to update all the reports (that…

It can definitely become a problem. But if you’re at that point, you don’t need a guide that explains SQL databases to you. :p

Realistically this guide should be bifurcated in terms of scale.

Re: The Startup CTO's Handbook

#197

Post by reducesuffering »

rco8786 wrote: post #190
closeparen wrote: post #188

Earlier quoted context omitted.

>with such good json support in the most popular SQL databases Wait, was that the reason people were doing NoSQL? JSON support? I thought it was about sharding, write scalability, etc.

Ah yea the old “web scale” phase. I think everyone’s more or less accepted that very, very few startup-level (or even SMB-level) workloads need more scalability then Postgres/mysql gives. My favorite example is that Twitter used mysql for all tweets, writing ~5k/s 24/7/365, until about 2016ish. Well into being a public company with billions in revenue and 300mm+ MAUs.

Has everyone accepted that?

3/4 companies in the Bay Area senior software engineer interviews require a System Design interview where they will tell you "what if you had 10m users" and expect a distributed write-heavy sharding answer

Re: The Startup CTO's Handbook

#198

Post by rco8786 »

reducesuffering wrote: post #197
rco8786 wrote: post #190

Earlier quoted context omitted.

Ah yea the old “web scale” phase. I think everyone’s more or less accepted that very, very few startup-level (or even SMB-level) workloads need more scalability then Postgres/mysql gives. My favorite example is that Twitter used mysql for all tweets, writing ~5k/s 24/7/365, until about 2016ish. Well into being a public company with billions in revenue and 300mm+ MAUs.

Has everyone accepted that? 3/4 companies in the Bay Area senior software engineer interviews require a System Design interview where they will tell you "what if you had 10m users" and expect a distributed write-heavy sharding answer

You’re not wrong in the literal sense. But the “inside baseball” of that question is just that it’s a prompt to talk about how you would horizontally scale a system should the need arise. It’s not a prompt to start questioning whether 10mm or 200mm is the specific limit.

Re: The Startup CTO's Handbook

#199

Post by moi2388 »

andruby wrote: post #173
moi2388 wrote: post #76

My rules: 1. Keep nonsense away from your developers. They don’t need to be in meetings. If they do, they’ll ask for it. 2. Have coding standards. What is your definition of done? How far do we go with clean code? Hacky solutions are tech debt and will come back to bite you. Standardisation is much more important than the actual rule. 3. Have retrospectives. Why did something not work out as you think it would? What…

> Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well. Oh my. I much more prefer it when team are cross-functional, when the Product Manager, Product Designer and Engineers form a team. Those are the people they interact with the most (not the PMs or PDs from other teams). Marty Cagan has a couple of great books on that kind of development, a…

I agree. Product owners should be part of the team.

The separation is because I often saw Product owners saying “how” something should be made in the stories. Or invite all the developers to meetings.

If your developers need a meeting for more details, they’ll ask for it. And let them decide how to make something; as a PO your job is to keep a lot of nonsense away from your team and talk about “what” to make with the client. Perhaps the tech lead joins some of these conversations, especially in the beginning.

Re: The Startup CTO's Handbook

#200

Post by guappa »

pphysch wrote: post #154
guappa wrote: post #64

Earlier quoted context omitted.

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.

If you have to constantly tell customers to RTFM, you have a poor product. Or at least poor documentation. But no amount of documentation can paper over fundamentally poor product design, because docs are also technical debt. Even if devs aren't taking calls directly, there should be a product manager communicating this feedback to developers.

Not all products can be a box with a single red button on top.

And the best documentation is useless if someone doesn't bother to use it.

Also, it's normally a few annoying customers that want to be hand held, rather than all customers having the same problem with the same issue.

Post reply on HN