13 ms·

The Startup CTO's Handbook

649 points by simonebrunozzi 2y ago

gnabgib 2y ago
Popular in 2023 (452 points, 156 comments) https://news.ycombinator.com/item?id=37971795 https://news.ycombinator.com/item?id=37971795
tptacek 2y ago
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 cheaper than starting late and doing rework. This is basically the opposite of the advice I would give a startup. SOC2 attestations in particular are easy to get, and are a waste of money to obtain preemptively before there are purchase orders on the line for them. There are things you should start doing early that lay the groundwork for attestations, but you should be doing them anyways, even if you never plan to get a SOC2 (and if a big-ticket customer never demands it, you shouldn't SOC2). That's stuff like setting up single sign-on and having protected git branches; simple best practices. Anyone else want to spot check other parts of this document? I wouldn't feel qualified to challenge most of it.
- mikeocool 2y ago
  Yeah, in my experience, most companies who are going to 1) do business with early stage startups and 2) want SOC2 report, are going to be totally fine with writing “startup X will get their SOC2 type 1 in the next six months” into the contract and moving forward, so long as someone technical can get on the phone with their IT people convince them you are reasonably competent.
- femiagbabiaka 2y ago
  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 replicas for BI with a good visualization tool, you'll be good with that for a good while before you need to fork over 5/6 figures for Snowflake or anything else.
  - SOLAR_FIELDS 2y ago
    I was just commenting to a colleague recently about the significant improvements RDBMS have gotten for json support over the last decade. For instance, keys below the first level in Postgres jsonb fields were not indexable around a decade ago. Now you can do GIN index and other options that are rather sophisticated.
    - xp84 2y ago
      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.
      - SOLAR_FIELDS 2y ago
        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
        DanielHB 2y ago
        Hahaha, that is good, not justify why to use a certain tech, but rather justify why not just use postgres
        friendzis 2y ago
        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?
- gizmov21 2y ago
  Made an account just to say that I respectfully disagree solely when it comes to accounting and supply chain processes in an enterprise ERP. Unwinding un-auditable processes costs so much f’ing time and money while the business still has to run that I’ve found it to be cheaper and better to be auditable from day 1, in this one specific instance.
  - Tostino 2y ago
    I built one of the Trade Promotion Management platforms used in the NA market, and couldn't agree more. It's a nightmare trying to be auditable if you didn't think about it from the start.
    - gizmov21 2y ago
      I was at (insert infamous unicorn) and they spent a ton of money (all relative, the money meant nothing) but more importantly 18 months attempting to get SOX compliant and never made it, because running the business was too important. Of course it all came down to lack of leadership to enforce policies but even if we had it, it was objectively super fucking challenging. When I do get a chance to implement compliant processes at the beginning, it’s one of those amazing IT things where we prevent WW3 but never get the credit for it.
  - bri3d 2y ago
    There’s being auditABLE and being auditED. Honestly I think the article’s take is smarter for a less experienced or skilled founding team and tptacek’s is better for a more experienced team. Paying auditors to look at screenshots and CSVs is a giant waste of money until it’s not, but at the same time, letting bad practice ossify until it’s expensive to remove is also a mistake.
    - gizmov21 2y ago
      Yea agreed, my comment was more of a sidenote than a direct response.
- whitepoplar 2y ago
  Do you know of a good resource which describes these simple best practices?
  - tptacek 2y ago
    I wrote two: https://www.latacora.com/blog/2020/03/12/the-soc-starting/ https://www.latacora.com/blog/2020/03/12/the-soc-starting/ https://fly.io/blog/soc2-the-screenshots-will-continue-until-security-improves/ https://fly.io/blog/soc2-the-screenshots-will-continue-until...
    - whitepoplar 2y ago
      Thanks!
- xyzzy_plugh 2y ago
  > There are things you should start doing early that lay the groundwork for attestations, but you should be doing them anyways, even if you never plan to get a SOC2 (and if a big-ticket customer never demands it, you shouldn't SOC2). That's stuff like setting up single sign-on and having protected git branches; simple best practices. This is in many ways the spirit of SOC2, no? There are a lot of startup founders, far more than I'd like, who would purposefully eschew such "simple best practices" unless they had an axe like a SOC2 audit swinging over them. I think you're both right, for what it's worth, and my take is that you are more aligned with TFA than you perceive.
  - tptacek 2y ago
    How are we both right? I think you literally should wait until the last minute to start a SOC2 process.
    - rendaw 2y ago
      GP's point is that having SSO and protected git branches _is_ starting the SOC2 process.
      - koolba 2y ago
        That and having a ticket system (e.g., Jira) to track why you touched prod and you can answer just about every question.
        tptacek 2y ago
        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.)
      - tptacek 2y ago
        I'm pretty sure that's not what the author meant. Again: those are things you should do regardless of whether you're ever going to get SOC2 (and a lot of startups shouldn't).
- morsecodist 2y ago
  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 time consuming. What am I missing? I would love to be wrong here and for this to be easy.
  - film42 2y ago
    Using something like Vanta or Drata makes life a lot easier. I've done SOC2/PCI audits in fintech where we change tools every year (meaning we reinvented the wheel every year), and I've now done it at my own startup using Drata. Auditors feel more comfortable, you'll feel more comfortable, etc. Even if you're not planning on doing it right away, just sign up and have it start tracking your progress. It's time consuming, but not all consuming. I think I spend <2 hours a week on compliance now that we're set up. The "fun" part was engineering ways to implement things like PHI scanning and WAF protection as cheaply as possible. There's almost always a nearly-free cron job/python script/slackbot alternative to every "mandatory" 5-6 figure SaaS subscription in the space.
    - tptacek 2y ago
      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.
      - film42 2y ago
        My startup has to maintain a HIPAA cert, hence PHI scanning. But, you are correct.
        mirashii 2y ago
- samstave 2y ago
  Having gone through quite a number of compliance audits... the one thing that is good in that advice, is that many items in an audit are just a checklist of questions, such as do you have a policy for XYZ? or confirm you have a process for "thing" So what ends up happeneing is if you feel stressed about an audit, just getting a list of the audit, you will realize how much you can just say "yes" to and feel less daunted by the audit. So, its a good self-check even if youre just crossing out the things you should have already have a framework for.
- edoceo 2y ago
  Exactly; lots of over engineering/pre-optimisation in this. It's less for startups and more for startups-burning-vc-money-while-team-builds-resume.
- CaffeineLD50 2y ago
  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.
  - jyounker 2y ago
    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?
- ozim 2y ago
  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 thought they have great technical guys because they were expensive.
  - normie3000 2y ago
    SDLC?
    - ozim 2y ago
      Software Development Life Cycle
  - tptacek 2y ago
    You absolutely do not need an SDLC process in order to get SOC2 attested.
    - ozim 2y ago
      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.
      - tptacek 2y ago
        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).
- erispoe 2y ago
  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 should be doing anyway.
  - silasb 2y ago
    Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?
    - kevan 2y ago
      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).
      - tptacek 2y ago
        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.
- stult 2y ago
  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.
  - tptacek 2y ago
    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.
- Eridrus 2y ago
  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.
snide 2y ago
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.
- ajmurmann 2y ago
  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.
  - ajmurmann 2y ago
    "support extension" not "super extension"
- maccard 2y ago
  > where people didn't want to naturally migrate to the "future crew". I think the book captures a solution to this with: > Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week. > Define the customer crew as a temporary team. This can mean either that the customer crew itself doesn't exist full-time (perhaps for only one week per month), or that team members are constantly rotating between the customer and feature crews. > Has anyone worked in a "two crews" system where there wasn't resentment? yes. I've worked for a few places where the teams are fully distinct and it works well. In games think Engine team vs Game team. Even on the Game team at one of my previous roles the way it worked was you'd get put on a feature which might take 6-12 weeks to ship, and then there'd be some maintenance work/updates/tech debt after that. Your primary focus was the thing you just shipped but you'd also have the time to go back to some of the previous stuff and work on that too. During that time, the other team would be on the same rota, and after 6-8 weeks you'd on-ramp to a new feature and repeat.
film42 2y ago
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 your hands dirty building by yourself and with your team.
- mikeshi42 2y ago
  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.
  - guappa 2y ago
    Can you really do any of that if you forgot how it's done?
- CaffeineLD50 2y ago
  Elon Musk, for example, appears to be wholly self taught as a coder. Do you want Elon doing your code reviews?
  - guappa 2y ago
    I want him to call me a pedo while I'm trying to save people stuck in a cave :D
    - CaffeineLD50 2y ago
Sytten 2y ago
Its interesting that the original HN discussion talked a whole lot about recorded meetings. Feels like another world just a few years later with AI transcript embedded in every video conference.
m104 2y ago
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."
- borski 2y ago
  One thing that we did to account for this was to shift the teams every or every few sprints. It allowed folks to get more experience, still get feedback, since if they built a buggy feature they'd have to fix it, etc. People seemed much happier with that, because they also didn't get tired of 'always fixing bugs' or never getting the feedback, which you insightfully mentioned.
- bboreham 2y ago
  I call them “shiny team and shitty team”.
- DanielHB 2y ago
  Related topic, but every company I worked at that had a platform team (as in a third-crew support team that manages tools/practices/common-code for a discipline) ends up being infested with over-engineering. They tend to attract that kinda of people who have disdain about delivering features and fixing bugs and like to over-abstract problems. Instead of fixing bugs they try to create increasingly complex abstractions to prevent the bugs from happening in the first place, with obvious results.
  - 2y ago
agnishom 2y ago
> 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.
- rukuu001 2y ago
  Some people like videos, some like text. Both are an investment in effort and payoff. Gen AI makes it easy to do both now.
rukuu001 2y ago
I like things like this not because I'm going to use it as a bible, but because it provides good coverage of responsibilities & concerns. Unless you've got some great advisers or you worked under someone really great, no one's going to take you aside and give you a list of stuff you need to take care of once you're in this position. For each section I'm asking - what's our answer to this? Do I agree with this? Is our process better? What have I missed? It's helpful.
MichaelMoser123 2y ago
There is a lot of talk on culture fit. Most of the talk on "culture fit" is bringing up a hidden layer of discrimination, of one sort of the other - to the detriment of the companies that are applying these rules. Cultural openness is a factor of success, discrimination is leading into the opposite direction - if you ask me. > The best leaders track their success rate, are not afraid of admitting hiring mistakes, and will hire slow, fire fast. in me this brings up the desire to post the picture that JWZ (Jamie Zawinski) is showing, upon detecting a referrer header that points to this site. Look up in google what Jamie Zawinski has to say on Ycombinator... (He is also credited with Netscape's decision to open-source Netscape Navigator, along with most of the work that resulted in the rendering engine for that browser; that's why we have Firefox)
- creativenolo 2y ago
  I accepted your side quest. The first page of results are all comments on hacker news about Jamie Zawinski and where I gave up. Do tell…
  - deleted 2y ago
    [deleted]
  - MichaelMoser123 2y ago
    This is supposed to exemplify my point: the attitudes of Mr. Zawinski may be questionable; however his contribution and his output are not questioned by anybody. We would all be worse off without these contributions.
    - drcongo 2y ago
      I'm still none the wiser. What attitudes?
- Earw0rm 2y ago
  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're every shade of the rainbow on this ship, but even our Klingon thinks Klingons are evil."
underdeserver 2y ago
I don't agree with everything, but man, reading up on all the best practices here makes me want to work at a place that implements them.
- adamors 2y ago
  Probably no place implements all of them, but with all best practices, they should be asymptotic.
  - underdeserver 2y ago
    Probably not, but if the basic mindset is one that agrees with these principles and makes at least a minimal effort to try and follow them, it feels different.
bob1029 2y ago
> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people. This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the middle of it until they figure out a way to get the entire team out of hell. Protecting the elite engineers from the consequences of their own designs is a death sentence for a technology startup. I watched this happen in real time myself. The moment you let the developers off the hook, nothing feels real anymore. The CTO should be leading by example. Getting in front of the customer on the calls. Heading up the nastiest implementations of the product. Grabbing the issues that have been rotting for weeks. Generally, throwing themselves directly in front of the bus at every possible opportunity. If you are the most highly-paid technical person, you need to be the backstop. There is no one behind you to catch anything. The CEO doesn't have time for the bullshit you were supposed to be managing. Everything else follows from putting yourself in harms way as often as possible. After being ran through the rotten issue wringer for 48 hours, how do we feel about playing with clever noSQL/graph databases or web frameworks with no discernable user base? Does AI make sense for our business or customers? Allow the technology choices and policies to be informed by your daily, real world experience with the business. The more deeply you involve yourself, the more accurate your decisions will likely be.
- guappa 2y ago
  You've ever done support calls? You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.
  - robjan 2y ago
    Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
  - hansmayer 2y ago
    I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.
hansmayer 2y ago
Honestly reads more like a "Handbook for the CEO of a startup that had hit its planned growth targets and now needs to stabilise", the suggestion about 3 types of CTOs and implying therefore that you effectively need 3 CTO-level managers to cover different requirements( Architecture, hiring, etc) is something that you only see at that stage. I was willing to give it a go and read through everything, but mentioning "Agile", with capital "A" as a development methodology finally convinced me that the author has no significant real-world experience in building technical startups. Hard pass.
moi2388 2y ago
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 needs to change? 4. Plan tech debt cleanup sprints, or incorporate some stories in every sprint. Tech debt immediately leads to slow down, and very quickly to stagnation. 5. Encourage training and knowledge sharing. Code reviews are a good place to start. 6. Write good tests. This alone will show you if your structure and code practices makes sense. 7. Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well.
- randerson 2y ago
  In my experience, trying to shield developers from customer/business/product decisions will doom the business to broken telephone syndrome. Developers are also generally more motivated when they feel some connection to the business.
  - chasd00 2y ago
    yeah i've always felt it was a good idea for new software devs out of college to spend a few years at a small eat-what-you-kill consultancy. You really get a sense of where you're paycheck comes from and why it exists. Going straight to a giant corporation distorts your view because no matter how detached and abstract you become the direct deposit still shows up. You lose all connection to why you're paid.
  - moi2388 2y ago
    Did you read the first or third sentence in point 1?
- andruby 2y ago
  > 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.
cynicalsecurity 2y ago
Someone has been bitten by Leo Tolstoy. "Release and Downtime", 700 pages.
osigurdson 2y ago
Deciding up front on the meeting frequency and type sounds more like how to run a department at a government agency.
mocmoc 2y ago
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.
- lobsterthief 2y ago
  I don’t believe this to be true at all; very early-stage startups could have a CTO who is doing much of the coding to get things off the ground. Also, Fractional CTOs are a thing ;) Some companies can benefit from a CTO who is not full-time: for example, many medium-sized publishers. The CTO role and its functions are still necessary even if the company cannot afford to hire a full-time CTO or would rather commit that budget elsewhere.
- esafak 2y ago
  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.
  - mocmoc 2y ago
    Exactly
frantzmiccoli 2y ago
Any chance someone has an epub or a PDF of this?
- croisillon 2y ago
  https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/main/published_files/Oct16thFinal.pdf https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/ma...
codingdave 2y ago
> Synchronous Chat I just want to put the idea out there that there is no such thing. If you need it to be synchronous, it should not be in a chat window. Or at least, not without agreeing "Hey, we are going to dedicate a few minutes to real-time chat on this." If remote, call them. If on-site, face each other and talk. Don't throw messages into a chat and expect immediate response.
hackburg 2y ago
[dead]
leonardovaz 2y ago
I'd like to recommend a book about same topic written by a friend of mine many years ago: https://ctofieldguide.com/ https://ctofieldguide.com/
methods21 2y ago
I tend to disagree a tad with what you have said below, I've lost count how many interviews I've done at this point, one challenge is on the intake side and how many darn applicants there are or can be and that its typically the recruiting team interacting with them at this point. The question in your example, is fine to include, but you need a non, yes or no or scale question to weed out unqualified candidates. For me, this is a very succinct question with a definitive answer. You'll be surprised at how many people will answer 'extremely comfortable' with Javascript yet not know what === means, so I'll ask something along the lines of 'what is the strictly equal operator in Javascript"... while any javascript programmer will know this, you'll be surprised that this type of Q alone knocks out 50% of the applicant pool, most of whom probably selected 'extremely comfortable' btw, and save my org. a TON of time. "For example, for a role that requires experience in JavaScript, it's not unreasonable to confirm that experience in the questionnaire with a question like, Rate your comfort level working with JavaScript on a scale from not comfortable to extremely comfortable."

Popular in 2023 (452 points, 156 comments) https://news.ycombinator.com/item?id=37971795 https://news.ycombinator.com/item?id=37971795

tptacek 2y ago

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 cheaper than starting late and doing rework. This is basically the opposite of the advice I would give a startup. SOC2 attestations in particular are easy to get, and are a waste of money to obtain preemptively before there are purchase orders on the line for them. There are things you should start doing early that lay the groundwork for attestations, but you should be doing them anyways, even if you never plan to get a SOC2 (and if a big-ticket customer never demands it, you shouldn't SOC2). That's stuff like setting up single sign-on and having protected git branches; simple best practices. Anyone else want to spot check other parts of this document? I wouldn't feel qualified to challenge most of it.

mikeocool 2y ago
Yeah, in my experience, most companies who are going to 1) do business with early stage startups and 2) want SOC2 report, are going to be totally fine with writing “startup X will get their SOC2 type 1 in the next six months” into the contract and moving forward, so long as someone technical can get on the phone with their IT people convince them you are reasonably competent.
femiagbabiaka 2y ago
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 replicas for BI with a good visualization tool, you'll be good with that for a good while before you need to fork over 5/6 figures for Snowflake or anything else.
- SOLAR_FIELDS 2y ago
  I was just commenting to a colleague recently about the significant improvements RDBMS have gotten for json support over the last decade. For instance, keys below the first level in Postgres jsonb fields were not indexable around a decade ago. Now you can do GIN index and other options that are rather sophisticated.
  - xp84 2y ago
    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.
    - SOLAR_FIELDS 2y ago
      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
      - DanielHB 2y ago
        Hahaha, that is good, not justify why to use a certain tech, but rather justify why not just use postgres
        friendzis 2y ago
        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?
gizmov21 2y ago
Made an account just to say that I respectfully disagree solely when it comes to accounting and supply chain processes in an enterprise ERP. Unwinding un-auditable processes costs so much f’ing time and money while the business still has to run that I’ve found it to be cheaper and better to be auditable from day 1, in this one specific instance.
- Tostino 2y ago
  I built one of the Trade Promotion Management platforms used in the NA market, and couldn't agree more. It's a nightmare trying to be auditable if you didn't think about it from the start.
  - gizmov21 2y ago
    I was at (insert infamous unicorn) and they spent a ton of money (all relative, the money meant nothing) but more importantly 18 months attempting to get SOX compliant and never made it, because running the business was too important. Of course it all came down to lack of leadership to enforce policies but even if we had it, it was objectively super fucking challenging. When I do get a chance to implement compliant processes at the beginning, it’s one of those amazing IT things where we prevent WW3 but never get the credit for it.
- bri3d 2y ago
  There’s being auditABLE and being auditED. Honestly I think the article’s take is smarter for a less experienced or skilled founding team and tptacek’s is better for a more experienced team. Paying auditors to look at screenshots and CSVs is a giant waste of money until it’s not, but at the same time, letting bad practice ossify until it’s expensive to remove is also a mistake.
  - gizmov21 2y ago
    Yea agreed, my comment was more of a sidenote than a direct response.
whitepoplar 2y ago
Do you know of a good resource which describes these simple best practices?
- tptacek 2y ago
  I wrote two: https://www.latacora.com/blog/2020/03/12/the-soc-starting/ https://www.latacora.com/blog/2020/03/12/the-soc-starting/ https://fly.io/blog/soc2-the-screenshots-will-continue-until-security-improves/ https://fly.io/blog/soc2-the-screenshots-will-continue-until...
  - whitepoplar 2y ago
    Thanks!
xyzzy_plugh 2y ago
> There are things you should start doing early that lay the groundwork for attestations, but you should be doing them anyways, even if you never plan to get a SOC2 (and if a big-ticket customer never demands it, you shouldn't SOC2). That's stuff like setting up single sign-on and having protected git branches; simple best practices. This is in many ways the spirit of SOC2, no? There are a lot of startup founders, far more than I'd like, who would purposefully eschew such "simple best practices" unless they had an axe like a SOC2 audit swinging over them. I think you're both right, for what it's worth, and my take is that you are more aligned with TFA than you perceive.
- tptacek 2y ago
  How are we both right? I think you literally should wait until the last minute to start a SOC2 process.
  - rendaw 2y ago
    GP's point is that having SSO and protected git branches _is_ starting the SOC2 process.
    - koolba 2y ago
      That and having a ticket system (e.g., Jira) to track why you touched prod and you can answer just about every question.
      - tptacek 2y ago
        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.)
    - tptacek 2y ago
      I'm pretty sure that's not what the author meant. Again: those are things you should do regardless of whether you're ever going to get SOC2 (and a lot of startups shouldn't).
morsecodist 2y ago
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 time consuming. What am I missing? I would love to be wrong here and for this to be easy.
- film42 2y ago
  Using something like Vanta or Drata makes life a lot easier. I've done SOC2/PCI audits in fintech where we change tools every year (meaning we reinvented the wheel every year), and I've now done it at my own startup using Drata. Auditors feel more comfortable, you'll feel more comfortable, etc. Even if you're not planning on doing it right away, just sign up and have it start tracking your progress. It's time consuming, but not all consuming. I think I spend <2 hours a week on compliance now that we're set up. The "fun" part was engineering ways to implement things like PHI scanning and WAF protection as cheaply as possible. There's almost always a nearly-free cron job/python script/slackbot alternative to every "mandatory" 5-6 figure SaaS subscription in the space.
  - tptacek 2y ago
    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.
    - film42 2y ago
      My startup has to maintain a HIPAA cert, hence PHI scanning. But, you are correct.
      - mirashii 2y ago
samstave 2y ago
Having gone through quite a number of compliance audits... the one thing that is good in that advice, is that many items in an audit are just a checklist of questions, such as do you have a policy for XYZ? or confirm you have a process for "thing" So what ends up happeneing is if you feel stressed about an audit, just getting a list of the audit, you will realize how much you can just say "yes" to and feel less daunted by the audit. So, its a good self-check even if youre just crossing out the things you should have already have a framework for.
edoceo 2y ago
Exactly; lots of over engineering/pre-optimisation in this. It's less for startups and more for startups-burning-vc-money-while-team-builds-resume.
CaffeineLD50 2y ago
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.
- jyounker 2y ago
  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?
ozim 2y ago
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 thought they have great technical guys because they were expensive.
- normie3000 2y ago
  SDLC?
  - ozim 2y ago
    Software Development Life Cycle
- tptacek 2y ago
  You absolutely do not need an SDLC process in order to get SOC2 attested.
  - ozim 2y ago
    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.
    - tptacek 2y ago
      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).
erispoe 2y ago
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 should be doing anyway.
- silasb 2y ago
  Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?
  - kevan 2y ago
    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).
    - tptacek 2y ago
      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.
stult 2y ago
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.
- tptacek 2y ago
  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.
Eridrus 2y ago
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.

snide 2y ago

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.

ajmurmann 2y ago
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.
- ajmurmann 2y ago
  "support extension" not "super extension"
maccard 2y ago
> where people didn't want to naturally migrate to the "future crew". I think the book captures a solution to this with: > Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week. > Define the customer crew as a temporary team. This can mean either that the customer crew itself doesn't exist full-time (perhaps for only one week per month), or that team members are constantly rotating between the customer and feature crews. > Has anyone worked in a "two crews" system where there wasn't resentment? yes. I've worked for a few places where the teams are fully distinct and it works well. In games think Engine team vs Game team. Even on the Game team at one of my previous roles the way it worked was you'd get put on a feature which might take 6-12 weeks to ship, and then there'd be some maintenance work/updates/tech debt after that. Your primary focus was the thing you just shipped but you'd also have the time to go back to some of the previous stuff and work on that too. During that time, the other team would be on the same rota, and after 6-8 weeks you'd on-ramp to a new feature and repeat.

film42 2y ago

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 your hands dirty building by yourself and with your team.

mikeshi42 2y ago
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.
- guappa 2y ago
  Can you really do any of that if you forgot how it's done?
CaffeineLD50 2y ago
Elon Musk, for example, appears to be wholly self taught as a coder. Do you want Elon doing your code reviews?
- guappa 2y ago
  I want him to call me a pedo while I'm trying to save people stuck in a cave :D
  - CaffeineLD50 2y ago

Sytten 2y ago

Its interesting that the original HN discussion talked a whole lot about recorded meetings. Feels like another world just a few years later with AI transcript embedded in every video conference.

m104 2y ago

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

borski 2y ago
One thing that we did to account for this was to shift the teams every or every few sprints. It allowed folks to get more experience, still get feedback, since if they built a buggy feature they'd have to fix it, etc. People seemed much happier with that, because they also didn't get tired of 'always fixing bugs' or never getting the feedback, which you insightfully mentioned.
bboreham 2y ago
I call them “shiny team and shitty team”.
DanielHB 2y ago
Related topic, but every company I worked at that had a platform team (as in a third-crew support team that manages tools/practices/common-code for a discipline) ends up being infested with over-engineering. They tend to attract that kinda of people who have disdain about delivering features and fixing bugs and like to over-abstract problems. Instead of fixing bugs they try to create increasingly complex abstractions to prevent the bugs from happening in the first place, with obvious results.
- 2y ago

agnishom 2y ago

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

rukuu001 2y ago
Some people like videos, some like text. Both are an investment in effort and payoff. Gen AI makes it easy to do both now.

rukuu001 2y ago

I like things like this not because I'm going to use it as a bible, but because it provides good coverage of responsibilities & concerns. Unless you've got some great advisers or you worked under someone really great, no one's going to take you aside and give you a list of stuff you need to take care of once you're in this position. For each section I'm asking - what's our answer to this? Do I agree with this? Is our process better? What have I missed? It's helpful.

MichaelMoser123 2y ago

There is a lot of talk on culture fit. Most of the talk on "culture fit" is bringing up a hidden layer of discrimination, of one sort of the other - to the detriment of the companies that are applying these rules. Cultural openness is a factor of success, discrimination is leading into the opposite direction - if you ask me. > The best leaders track their success rate, are not afraid of admitting hiring mistakes, and will hire slow, fire fast. in me this brings up the desire to post the picture that JWZ (Jamie Zawinski) is showing, upon detecting a referrer header that points to this site. Look up in google what Jamie Zawinski has to say on Ycombinator... (He is also credited with Netscape's decision to open-source Netscape Navigator, along with most of the work that resulted in the rendering engine for that browser; that's why we have Firefox)

creativenolo 2y ago
I accepted your side quest. The first page of results are all comments on hacker news about Jamie Zawinski and where I gave up. Do tell…
- deleted 2y ago
  [deleted]
- MichaelMoser123 2y ago
  This is supposed to exemplify my point: the attitudes of Mr. Zawinski may be questionable; however his contribution and his output are not questioned by anybody. We would all be worse off without these contributions.
  - drcongo 2y ago
    I'm still none the wiser. What attitudes?
Earw0rm 2y ago
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're every shade of the rainbow on this ship, but even our Klingon thinks Klingons are evil."

underdeserver 2y ago

I don't agree with everything, but man, reading up on all the best practices here makes me want to work at a place that implements them.

adamors 2y ago
Probably no place implements all of them, but with all best practices, they should be asymptotic.
- underdeserver 2y ago
  Probably not, but if the basic mindset is one that agrees with these principles and makes at least a minimal effort to try and follow them, it feels different.

bob1029 2y ago

> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people. This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the middle of it until they figure out a way to get the entire team out of hell. Protecting the elite engineers from the consequences of their own designs is a death sentence for a technology startup. I watched this happen in real time myself. The moment you let the developers off the hook, nothing feels real anymore. The CTO should be leading by example. Getting in front of the customer on the calls. Heading up the nastiest implementations of the product. Grabbing the issues that have been rotting for weeks. Generally, throwing themselves directly in front of the bus at every possible opportunity. If you are the most highly-paid technical person, you need to be the backstop. There is no one behind you to catch anything. The CEO doesn't have time for the bullshit you were supposed to be managing. Everything else follows from putting yourself in harms way as often as possible. After being ran through the rotten issue wringer for 48 hours, how do we feel about playing with clever noSQL/graph databases or web frameworks with no discernable user base? Does AI make sense for our business or customers? Allow the technology choices and policies to be informed by your daily, real world experience with the business. The more deeply you involve yourself, the more accurate your decisions will likely be.

guappa 2y ago
You've ever done support calls? You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.
- robjan 2y ago
  Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
- hansmayer 2y ago
  I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.

hansmayer 2y ago

Honestly reads more like a "Handbook for the CEO of a startup that had hit its planned growth targets and now needs to stabilise", the suggestion about 3 types of CTOs and implying therefore that you effectively need 3 CTO-level managers to cover different requirements( Architecture, hiring, etc) is something that you only see at that stage. I was willing to give it a go and read through everything, but mentioning "Agile", with capital "A" as a development methodology finally convinced me that the author has no significant real-world experience in building technical startups. Hard pass.

moi2388 2y ago

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 needs to change? 4. Plan tech debt cleanup sprints, or incorporate some stories in every sprint. Tech debt immediately leads to slow down, and very quickly to stagnation. 5. Encourage training and knowledge sharing. Code reviews are a good place to start. 6. Write good tests. This alone will show you if your structure and code practices makes sense. 7. Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well.

randerson 2y ago
In my experience, trying to shield developers from customer/business/product decisions will doom the business to broken telephone syndrome. Developers are also generally more motivated when they feel some connection to the business.
- chasd00 2y ago
  yeah i've always felt it was a good idea for new software devs out of college to spend a few years at a small eat-what-you-kill consultancy. You really get a sense of where you're paycheck comes from and why it exists. Going straight to a giant corporation distorts your view because no matter how detached and abstract you become the direct deposit still shows up. You lose all connection to why you're paid.
- moi2388 2y ago
  Did you read the first or third sentence in point 1?
andruby 2y ago
> 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.

cynicalsecurity 2y ago

Someone has been bitten by Leo Tolstoy. "Release and Downtime", 700 pages.

osigurdson 2y ago

Deciding up front on the meeting frequency and type sounds more like how to run a department at a government agency.

mocmoc 2y ago

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.

lobsterthief 2y ago
I don’t believe this to be true at all; very early-stage startups could have a CTO who is doing much of the coding to get things off the ground. Also, Fractional CTOs are a thing ;) Some companies can benefit from a CTO who is not full-time: for example, many medium-sized publishers. The CTO role and its functions are still necessary even if the company cannot afford to hire a full-time CTO or would rather commit that budget elsewhere.
esafak 2y ago
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.
- mocmoc 2y ago
  Exactly

frantzmiccoli 2y ago

Any chance someone has an epub or a PDF of this?

croisillon 2y ago
https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/main/published_files/Oct16thFinal.pdf https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/ma...

codingdave 2y ago

> Synchronous Chat I just want to put the idea out there that there is no such thing. If you need it to be synchronous, it should not be in a chat window. Or at least, not without agreeing "Hey, we are going to dedicate a few minutes to real-time chat on this." If remote, call them. If on-site, face each other and talk. Don't throw messages into a chat and expect immediate response.

hackburg 2y ago

[dead]

leonardovaz 2y ago

I'd like to recommend a book about same topic written by a friend of mine many years ago: https://ctofieldguide.com/ https://ctofieldguide.com/

methods21 2y ago

I tend to disagree a tad with what you have said below, I've lost count how many interviews I've done at this point, one challenge is on the intake side and how many darn applicants there are or can be and that its typically the recruiting team interacting with them at this point. The question in your example, is fine to include, but you need a non, yes or no or scale question to weed out unqualified candidates. For me, this is a very succinct question with a definitive answer. You'll be surprised at how many people will answer 'extremely comfortable' with Javascript yet not know what === means, so I'll ask something along the lines of 'what is the strictly equal operator in Javascript"... while any javascript programmer will know this, you'll be surprised that this type of Q alone knocks out 50% of the applicant pool, most of whom probably selected 'extremely comfortable' btw, and save my org. a TON of time. "For example, for a role that requires experience in JavaScript, it's not unreasonable to confirm that experience in the questionnaire with a question like, Rate your comfort level working with JavaScript on a scale from not comfortable to extremely comfortable."