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

181–190 of 212 posts

Re: The Startup CTO's Handbook

#181

Post by tptacek »

kevan wrote: post #180
silasb wrote: post #128

Earlier quoted context omitted.

Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?

Manage identity centrally is probably referring to using an identity management system like Okta, Microsoft Identity, or hosting your own IdP and using strong hardware 2FA. You don't want people creating their own accounts manually for everything or shared accounts that everyone knows the password for (or is on a shared spreadsheet that the entire company has access to).

At this point most startups would just use Google; since they're almost certainly using Google as their email provider, and "company email" is a de facto root-of-trust even if you don't intend it to be, there isn't really a whole lot of thought that needs to go into it. It helps that they have the best 2FA stack of any mainstream cloud service.

Re: The Startup CTO's Handbook

#182

Post by jkingsbery »

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…

Mostly because of the Maker's Schedule vs. Manager's Schedule (https://www.paulgraham.com/makersschedule.html) issue. It's really hard to be in a role that deals with a lot of randomization and then sit and focus for 4 hours straight on something.

Re: The Startup CTO's Handbook

#183

Post by jpswade »

snide wrote: post #7

Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew". I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.

I've experimented with a two-crew type system before (Red Team for feature development, Blue Team for stability and bug fixes).

Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).

It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.

Re: The Startup CTO's Handbook

#184

Post by cyberax »

scarface_74 wrote: post #174
cyberax wrote: post #170

Earlier quoted context omitted.

> For even a 20-30 person company. My CTO at the last startup I was working for was constantly flying to talk to customers - B2B with long sales cycles. He was the first technical person that the CxOs at the other companies spoke to. That's really not a job for the CTO. It's a job for a sales engineer (with whatever their CxO title is), and it requires a different skill set. You need to be able to extract the product…

A CxO doesn’t want to talk to a sales engineer who is not technical. They want to speak to someone on their level. The sales engineer defines the problem space and the customer needs. But isn’t technical enough to design a solution or know the feasibility of a solution. I’m not in sales. I am the first deep technical person that a customer talks to (consulting). Even for projects at AWS ProServe, the SA’s were sales…

> 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 talks to (consulting).

This means that you're in sales :)

I think the distinction here matters. CTO is a more inwards-facing position, they are responsible for formulating and executing the technical plans and maintaining the quality of the product.

In other words:

CEO - "we need to get the city of San Francisco as our customer"

CSO - "San Francisco needs a bridge"

CTO - "we can build a cable-stayed bridge across the Golden Gate"

Tech Lead - "we can use 1 meter cross-section cable stays to construct a cable-stayed bridge across the Golden Gate"

In reality, especially in startups, there's always going to be some level of responsibility sharing.

Re: The Startup CTO's Handbook

#185

Post by scarface_74 »

cyberax wrote: post #184
scarface_74 wrote: post #174

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. The sales engineer defines the problem space and the customer needs. But isn’t technical enough to design a solution or know the feasibility of a solution. I’m not in sales. I am the first deep technical person that a customer talks to (consulting). Even for projects at AWS ProServe, the SA’s were sales…

> 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

Re: The Startup CTO's Handbook

#186

Post by charlie0 »

Aurornis wrote: post #121
fatnoah wrote: post #112

Earlier quoted context omitted.

> Then they become gatekeepers, refusing to allow anything on their platform unless it conforms to their ideal vision As the owner of a platform team, this very common attitude of platform teams kills me. Yes, we have a long-term vision that we're working towards, but our main goals are two accelerate developers AND produce more robust systems. Outside of totally egregious violations of company standards, my team is…

That’s exactly how every platform team starts. There is inherent tension between accelerating developers and building their own systems, though. In my experience, the platform teams developed an idea that their conceptualized system would accelerate everything once it was done, but working with product teams was a distraction from getting it done. They also didn’t like the idea of deploying something now and then hav…

There probably isn't any middle ground in practice then. If the product teams have control, then the tech debt just keeps building as they keep prioritizing new features over longer term maintainability. I see it already happening at my startup where product has a lot more influence than engineers in terms of what goes on the roadmap (there's practically zero time devoted to lowering tech debt.)

Re: The Startup CTO's Handbook

#187

Post by tptacek »

koolba wrote: post #18
rendaw wrote: post #17

Earlier quoted context omitted.

GP's point is that having SSO and protected git branches _is_ starting the SOC2 process.

That and having a ticket system (e.g., Jira) to track why you touched prod and you can answer just about every question.

We don't have that, and didn't need it for SOC2.

(We have other ways of tracking prod changes, but our auditors don't know anything about them.)

Re: The Startup CTO's Handbook

#188

Post by closeparen »

femiagbabiaka wrote: post #5
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…

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.

Re: The Startup CTO's Handbook

#189

Post by rhubarbtree »

jkingsbery wrote: post #182
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…

Mostly because of the Maker's Schedule vs. Manager's Schedule ( https://www.paulgraham.com/makersschedule.html ) issue. It's really hard to be in a role that deals with a lot of randomization and then sit and focus for 4 hours straight on something.

It’s hard but not impossible. First thing is to realise you’re going to work longer hours than everyone else.

Re: The Startup CTO's Handbook

#190

Post by rco8786 »

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.

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.

Post reply on HN