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

201–210 of 212 posts

Re: The Startup CTO's Handbook

#201

Post by petesergeant »

maayank wrote: post #120
petesergeant wrote: post #44

Earlier quoted context omitted.

> 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…

What were good time management resources for you?

Getting Things Done and Seven Habits set the foundation, and then just iterating on those principles until I found systems that worked for me. Big believer in not using the Inbox as a task list, and apps that make setting, repeating, and organising reminders very easy.

Re: The Startup CTO's Handbook

#202

Post by Earw0rm »

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…

It can go either way. A top-down company can be interested or disinterested in culture. Some would argue that for a company to affect disinterest is an active and consequential choice. Consider the "bring your whole self to work" touchy-feely open-plan Valley startup vs a trad IBM-style cube farm. The latter is arguably more accommodating of genuine oddballs, for "good fences make good neighbours" kind of reasons.

As regards pivoting, think about it like a joint having freedom of movement on more than one axis. You want to keep flexibility in as many as possible, but also straight-line speed/strength/efficiency. Somewhere there's going to be a trade-off. A genuinely diverse team (I don't mean just "ticking all the DEI boxes", but profound differences in background and life experience) takes longer to find their groove than a bunch from similar social backgrounds, but they'll have insights that a "TV sitcom cast"-looking team never will.

Re: The Startup CTO's Handbook

#203

Post by friendzis »

DanielHB wrote: post #166
SOLAR_FIELDS wrote: post #123

Earlier quoted context omitted.

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

This should be default decision-making process. If your proposition is to move the compromise scale please not only provide the benefits, but also the drawbacks and analysis on transition. This forces proposal to analyze existing status quo and reasons behind it, which is often enough for the proposal to be withdrawn.

Distant relative of 5 whys. We need NoSql document store -> so we can store json blobs -> so we can do databasing at app level -> because DBAs with their insistence on schemas are slow. Oh, so we can solve the problems by hiring one DBA and maybe training two devs instead of hiring full dev team and refactoring stuff for a year?

Re: The Startup CTO's Handbook

#204

Post by DanielHB »

friendzis wrote: post #203
DanielHB wrote: post #166

Earlier quoted context omitted.

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

This should be default decision-making process. If your proposition is to move the compromise scale please not only provide the benefits, but also the drawbacks and analysis on transition. This forces proposal to analyze existing status quo and reasons behind it, which is often enough for the proposal to be withdrawn. Distant relative of 5 whys. We need NoSql document store -> so we can store json blobs -> so we can…

As someone working with datastore/firestore in a product first created around 10 years ago I wish you could have been there at the time. Running a migration to add a boolean field to all existing documents of a certain type took ~40 hours.

Funny thing is we are now migrating stuff out of datastore (and new stuff is not in datastore to begin with) into an RDBMS, but we are doing it microservice style with each microservice having its own separate database. So relationships are now cross-services concerns...

Not that having EVERYTHING in a single DB is the best approach always, but IMO we should default to keep everything in one single DB.

Re: The Startup CTO's Handbook

#205

Post by jyounker »

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

The section on performance management is circular and vague: a good one is motivating and a bad one is demotivating. OK. Glad we got that out of the way. The whole intro reads like a puffy resume and lots of gilding. Even a section of gushing testimonials. And he puts his name on the title so you don't gotta read the author byline. Total cheese.

The section on performance management is at least five pages long, and it covers compensation, leveling, job titles, PIPs, and firing. Perhaps you mistook the introduction to the section for the entirety of the section?

Re: The Startup CTO's Handbook

#206

Post by Eridrus »

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…

Just wanted to +1 this comment and say Vanta made SOC2 way more intimidating than it was.

What made it easy was talking to a startup that wanted soc2 and had it themselves who recommended an auditor who helped us untangle what was actually required.

It took a couple of months to get type 1 from start to finish with very part time attention.

Re: The Startup CTO's Handbook

#207

Post by femiagbabiaka »

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

Well that's the thing. You don't need a NoSQL database to design a data tier that scales to accommodate distributed write-heavy workloads.

Re: The Startup CTO's Handbook

#208

Post by mocmoc »

esafak wrote: post #109
mocmoc wrote: post #102

If you code you are not a CTO. if you have to code then You don't need a CTO. And if you are 3 person startup and you are CTO , hire a DEV Team in [enter country]. code as a CTO But just for you to know , you are making a mistake, we all did.

It depends on your budget and size. A 3-person team doesn't need a CTO that doesn't code. The CTO there might well be the CEO too.

Exactly

Re: The Startup CTO's Handbook

#209

Post by mirashii »

film42 wrote: post #129
tptacek wrote: post #30

Earlier quoted context omitted.

By all means use tools like these, but be very careful, because they (and auditors that use them) will lead you into engineering changes that are not required for SOC2 and may not be what's best for your team. For instance: there is absolutely no need to set up PHI scanning or a WAF to get SOC2.

My startup has to maintain a HIPAA cert, hence PHI scanning. But, you are correct.

I'm a few years out of date, but I don't believe that any sort of PHI scanning is specifically required by HIPPA either, though I've seen plenty of consultancies happy to sell you it.
Post reply on HN