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

171–180 of 212 posts

Re: The Startup CTO's Handbook

#171

Post by swat535 »

regularjack wrote: post #149
marcinzm wrote: post #99

Earlier quoted context omitted.

What you're describing is exactly the opposite of every actually successful team I've seen, and describes every mediocre team I've seen. Silos are death and not just in a code base. Good developers understand the product. Mediocre ones churn out tickets mindlessly.

In my experience, both are needed. Product owners and developers who understand the product. It's possible to have both, they're not mutually exclusive.

Yes, but it's the Product Owner's responsibility to clearly understand the requirements from both customers and the business and communicate them clearly to engineering.

Having engineers handle "support calls" doesn't make much sense, they are not equipped to manage product feedback or understand the business implications.

Re: The Startup CTO's Handbook

#172

Post by SkyPuncher »

quacksilver wrote: post #107
SkyPuncher wrote: post #95

Earlier quoted context omitted.

Further, I'm not sure what efficiency it provides overall. Is dedicating 20% of your team to support _that_ much different than the entire team spending 20% of their time on support? We've actually found our quality goes up massively when we force our engineers to deal with the problems in the features they ship, directly with customers. We still have dedicated front line support (that rotates weekly), but they run o…

Would putting some percentage of the team on 'support' for a week or two help with reducing task switching and help to allow deep work? Maybe everyone in the team would spend 2 weeks per quarter or something like that doing support. I (n=1) would prefer to be answering support tickets for 2 week blocks, and know when the blocks are in my calendar, so that I can plan work around them, rather than trying to debug somet…

It's pretty hard to be fully hands off of customers. That being said, we don't expect immediate replies unless (1) you're the front line support for the week (2) something is on fire. We also don't expect immediate replies. Generally, within 24 hours is acceptable.

It's a bit of a drag, but most people just deal with their occasional support needs at natural context switches. First thing in the morning, before they head out, in-between meetings, etc, etc

Re: The Startup CTO's Handbook

#173

Post by andruby »

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, and I much prefer it over teams where engineers are further away from the product people. I've been an engineering IC and in engineering and product leadership roles.

Integrating the Why (Vision/Strategy) is more tricky, but we want to do it much more openly then is traditionally done.

Re: The Startup CTO's Handbook

#174

Post by scarface_74 »

cyberax wrote: post #170
scarface_74 wrote: post #162

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

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 and unless they were a “specialist SA” weren’t technical. But they came to the consultants (full time employees) in ProServe to do the technical deep dives and lead the implementations.

Re: The Startup CTO's Handbook

#175

Post by ozim »

tptacek wrote: post #161
ozim wrote: post #48

Earlier quoted context omitted.

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.

Of course not, that was just part of the story to draw the picture. Where it might be required to pay for some consultant that will help with initial setup.

But maybe not go full attestation mode right away - but also tricky to find one.

Re: The Startup CTO's Handbook

#176

Post by stult »

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 this advice may vary in applicability across industries. If you're selling a B2B product that touches PII, you're definitely going to need SOC2 if you don't want to be laughed out the door during pitch meetings. And depending on your funding level, using an automatic SOC2 compliance checklist service like Secureframe may only be a few thousand dollars but will ensure not only that you are following those best practices but also in an idiosyncratically SOC2 manner that will make for an easy audit. Not a huge investment relative to the dev and project management time it takes to get onto SOC2 track with an organization that already has deeply engrained non-compliant processes in place.

Re: The Startup CTO's Handbook

#177

Post by tptacek »

stult wrote: post #176
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 this advice may vary in applicability across industries. If you're selling a B2B product that touches PII, you're definitely going to need SOC2 if you don't want to be laughed out the door during pitch meetings. And depending on your funding level, using an automatic SOC2 compliance checklist service like Secureframe may only be a few thousand dollars but will ensure not only that you are following those best…

Well, we run a public cloud, and before I joined up I spent the preceding 5 years at a consulting firm that ran the security teams of B2B companies that touched PII, including some in ludicrously sensitive problem domains (retail mortgage financing!) and I stand by what I wrote.

Further: while checklisting tools may only cost a couple thousand dollars, the actual process of getting a SOC2 attestation isn't the real expense. I could get OWASP WebGoat a SOC2 attestation if I wanted to (a ham sandwich would be even easier). The actual expense in SOC2 is the engineering work you do in support of it. Those checklist tools are fine if you know exactly what you're doing and don't let them add any engineering work, but what I've seen happen repeatedly is a SOC2 checklist from a tool leading a team into building a pasteurized process cheese food security practice, with IDS and WAF and server agents and code scanners and Nessus scans, at great expense.

Re: The Startup CTO's Handbook

#178

Post by marcinzm »

hnthrow90348765 wrote: post #167
marcinzm wrote: post #159

Earlier quoted context omitted.

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…

Why do you assume it's for free? The compensation of a software engineer varies widely. The same experience can get you anywhere from $100k to $1+m.

Perpetually doing less in fear of not getting paid enough for doing more is how you get paid a pittance while complaining about it constantly. Doing more and then finding a way to get paid more is how you get paid more and be happy.

Re: The Startup CTO's Handbook

#179

Post by tptacek »

ozim wrote: post #175
tptacek wrote: post #161

Earlier quoted context omitted.

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

Of course not, that was just part of the story to draw the picture. Where it might be required to pay for some consultant that will help with initial setup. But maybe not go full attestation mode right away - but also tricky to find one.

I think this stuff is highly folkloric and that any startup that picked a reasonable high-touch auditor and talked to some friends about their experiences could get through a Type 1 with virtually no effort (outside of their bizops team, who the auditors will definitely harass).

Re: The Startup CTO's Handbook

#180

Post by kevan »

silasb wrote: post #128
erispoe wrote: post #119

Earlier quoted context omitted.

It's a good idea to just not do stupid shit that would make it very painful to actually get compliant. Get vendors who have certs, keep infra minimal (which means not infra team). The more you do in house the more painful compliance will be. Buy, and buy from certified providers, simple. Manage identity centrally, keep all your secrets in a secret manager, use git and do code reviews. You're right all things you shou…

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).
Post reply on HN