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

31–40 of 212 posts

Re: The Startup CTO's Handbook

#31

Post by tptacek »

morsecodist wrote: post #20
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 am new to compliance but this seems super strange to me. Based on my cursory read of SOC2 you need a ton of evidence gathering for months leading up to your audit. How wold you know what to retroactively have if you didn't spend time on it? SOC2 attestations being easy to get also runs counter to what I have heard from every single other person on this topic. Generally what I hear is that it is extremely hard and t…

I posted two guides downthread. It's hard because people make it hard, or let people make it hard on them.

Re: The Startup CTO's Handbook

#32

Post by CaffeineLD50 »

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.

Re: The Startup CTO's Handbook

#33

Post by mikeshi42 »

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 else on their team (and their team's quality could be even better) - but all the other items I listed is likely only something the VP/CTO could do the best at in the company. It's quite a rational decision to largely give up hands-on technical work for what's more important for your team and company.

Re: The Startup CTO's Handbook

#34

Post by CaffeineLD50 »

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?

Re: The Startup CTO's Handbook

#35

Post by m104 »

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 crew can't get enough resources to fully fix anything.

Worse, your feature crews aren't learning anything beyond how to get those lines out the door, which will somehow get slower and more expensive as time goes on. Why? Because you removed the one fitness function on good software development which is to fully re-incorporate the negative feedback back into the source of development.

A real CTO leadership handbook would say clearly "it's your responsibility to help your developers improve, especially while shipping, and they're not always going to be happy about it."

Re: The Startup CTO's Handbook

#36

Post by ajmurmann »

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…

In my own experience it's a matter of only having that much time in the day. For 7 years I had somewhere between 20-25 people I was directly or indirectly responsible for. There was just not enough time to get anything useful done in the code and my time was much better spent solving problems that others couldn't. A few times I was able to pick up some really simple change just to get the experience first hand to go through all our processes and see where we can do better.

I always kept coding nights and weekends but it's just not the same and over time you are gonna get a little rusty. That said I greatly enjoyed getting my hand dirty all day during a sabbatical I'm taking.

Re: The Startup CTO's Handbook

#37

Post by jayd16 »

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…

When you're not just an IC, you have other priorities. That means your IC work can be derailed at any moment. _That_ means you can't take on work anywhere near the critical path or you're just blocking others or handing things off.

Reviews? Sure. Design meetings? Sure. But taking critical work will end up causing issues.

Re: The Startup CTO's Handbook

#38

Post by agnishom »

> 9. Build An Explainer Video Library

I am not sure this is great advice. I am sure it makes sense for certain things, like UI or animation. But, generally reading text is more efficient than video watching. It's also easy to seek to the important parts of a text than a video when you are in a hurry.

Re: The Startup CTO's Handbook

#39

Post by ajmurmann »

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.

At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in their spare time on what they wanted as long as they saw value for the company in it. It was a good bargain. Everyone else was grateful the small team was doing the dirty work and the maintenance team was delighted they could use the remaining time working on things that had always bugged them, do research, etc. This was a few years ago and I forgot details but I vaguely remember that we got some really cool improvements and research from them. The people on that team also were really excellent and self-motivating which helped make this a success but also more expensive.

Re: The Startup CTO's Handbook

#40

Post by whitepoplar »

tptacek wrote: post #12
whitepoplar wrote: post #9

Earlier quoted context omitted.

Do you know of a good resource which describes these simple best practices?

I wrote two: https://www.latacora.com/blog/2020/03/12/the-soc-starting/ https://fly.io/blog/soc2-the-screenshots-will-continue-until...

Thanks!
Post reply on HN