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

161–170 of 212 posts

Re: The Startup CTO's Handbook

#161

Post by tptacek »

ozim wrote: post #48
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 tho…

You absolutely do not need an SDLC process in order to get SOC2 attested.

Re: The Startup CTO's Handbook

#162

Post by scarface_74 »

cyberax wrote: post #157
scarface_74 wrote: post #56

Earlier quoted context omitted.

The job of a CTO is strategy . The last thing you want is a manager that codes. They always end up either being shitty managers who don’t do the things that I need from a manager - making sure the team gets the resources we need, prioritization, big picture, etc - or they end up being shitty developers because they can’t keep their commitments because of management responsibilities. Development is not a “super power”…

> The job of a CTO is strategy. The last thing you want is a manager that codes. For a large company the size of Google? Yes. For a startup? No.

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.

I find it quite funny when startups reach out to me about a “CTO” position that is really just a glorified team lead where I would be doing more hands on work and less strategy (with lower pay) than I was doing as a mid level (L5) employee when I was working at AWS (Professional Services).

I’ve interviewed former “CTOs” at startups that never did handle the scope of work, budgets and strategy that we expect from our “staff” level employees (my level now) at the medium size company I work at.

Re: The Startup CTO's Handbook

#163

Post by marcinzm »

MichaelMoser123 wrote: post #118
Earw0rm wrote: post #75

Earlier quoted context omitted.

All employment processes discriminate, the question is for and against what traits, and to the exclusion of what else? "Culture fit" is pretty much trading off communication efficiency and high trust against diversity of thought. You don't have to set so many guidelines as people already know how to behave, and what's expected of one another, but you're more vulnerable to groupthink and related cognitive biases. "We'…

> "Culture fit" is pretty much trading off communication efficiency and high trust against diversity of thought. I think I understand now: if the structure of your company is strictly top down, then you will have to value "communication efficiency" and "high trust" criteria higher than "diversity of thought". However, you might not be able to pivot efficiently, if your core assumptions are disproved. That's the situa…

I'd say it's the opposite. Diversity of thought is what requires a top-down structure to force everyone to eventually go down the same path despite believing it's not the right path.

If require everyone to just organically align based on whatever argument is made that the group sees as the best then, congratulations, you have a mono-culture around that. That's not how most people act or react.

Re: The Startup CTO's Handbook

#164

Post by DanielHB »

bluefirebrand wrote: post #136
DanielHB wrote: post #131

Earlier quoted context omitted.

That is actually usually not that bad (if there is, you know, revenue). What is really bad is when those teams start to roll out a lot of custom code that other teams need to use. If they are just configuring standard tools for everyone else it is usually fine (as long as they are not going to crazy with it).

The "platform" team at my company has rolled out a completely custom query language that we have had to learn and write so they don't have to make new endpoints to access different combinations of data And they haven't documented anything "There are integration tests, those are documentation go read those" Good times

Yes, this is exactly what I mean.

Re: The Startup CTO's Handbook

#165

Post by DanielHB »

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…

> use read replicas for BI

Yes this is good advice, until you get really large scale you don't need anything more fancy than some SQL in a read replica.

Re: The Startup CTO's Handbook

#166

Post by DanielHB »

SOLAR_FIELDS wrote: post #123
xp84 wrote: post #22

Earlier quoted context omitted.

Agreed. I can't think of anything that would convince me today to use a document store over Postgres as the primary (or likely only) database. Most of the time JSON fields augmenting the RDBMS seems like the way to go.

My default position nowadays is “Postgres” and engineering should have to justify why it is insufficient if engineering wants to use something else. It’s worked pretty well

Hahaha, that is good, not justify why to use a certain tech, but rather justify why not just use postgres

Re: The Startup CTO's Handbook

#167

Post by hnthrow90348765 »

marcinzm wrote: post #159
hnthrow90348765 wrote: post #122

Earlier quoted context omitted.

I'm okay with that knowing those developers are doing two jobs for the pay of one. And most products turn into that once the original developers leave. It's not like you can't learn the product through the PM either.

Unless you're working 80 hours a week you're not doing two jobs. You're doing one job.

Giving away flexibility for free is a collectively dumb move on our part. If someone knows you can take on coding tasks and customer interviewing vs. just coding, you are more valuable to them and they should pay more for it.

They've already gotten away with adding infrastructure and architecture (aka system design) rolled into one developer position. And putting it behind long and stressful interview processes. I'm not doing PM stuff on top of all that and not getting the pay and prestige for it.

Re: The Startup CTO's Handbook

#169

Post by citrin_ru »

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 would not want to migrate to the "future crew" given that "customer crew" getting enough resources (and adequately compensated). But even without separation it's typical that maintenance is starved while new features getting all attention and resources. I would guess separation on two teams would make it only worse.

Re: The Startup CTO's Handbook

#170

Post by cyberax »

scarface_74 wrote: post #162
cyberax wrote: post #157

Earlier quoted context omitted.

> The job of a CTO is strategy. The last thing you want is a manager that codes. For a large company the size of Google? Yes. For a startup? No.

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. I find it quite funny when startups reach out to me about a “CTO” position that is really just a glorified team lead where I would be doing more hands on work and less strategy (with lower…

> 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 requirements from the customer, and to distill them for other teams. You don't necessarily need to be able to guide their implementation.

> I find it quite funny when startups reach out to me about a “CTO” position that is really just a glorified team lead

But that's exactly what a CTO position is! Their job is to lead the technical teams, on the company level.

And a good CTO will know how to scale up. When you're working at a 10-people startup, you'll need to get into the details of the code on the actual "team lead" scale. Once you grow into a larger company, the job becomes a bit more abstract.

I worked at L6/L7 positions in AWS, and it indeed is a much more relaxed place if you want it to be. Being a CTO in a startup is way more stressful.

Post reply on HN