[HN Gopher] The Startup CTO's Handbook
___________________________________________________________________
The Startup CTO's Handbook
Author : simonebrunozzi
Score : 541 points
Date : 2025-03-11 22:18 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gnabgib wrote:
| Popular in 2023 (452 points, 156 comments)
| https://news.ycombinator.com/item?id=37971795
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Hahaha, that is good, not justify why to use a certain
| tech, but rather justify why not just use postgres
| thom wrote:
| Yep, this is a sneaky great feature. Where previously you'd
| have a sequential scan unless you put in multiple indexes
| or a bloom filter, you can now get great performance and
| easy of maintenance at the same time.
| Swizec wrote:
| > use read replicas for BI with a good visualization tool
|
| Put up 2 or 3 read replicas, split your queries so writes
| happen to main and reads come from replicas (supported out of
| the box by many modern ORMs), and you can scale to millions
| in daily active users for most startup workloads.
|
| Really the hard part of BI is that folks who need the info
| don't wanna learn SQL. The ones who can do SQL, will struggle
| to keep up with your changing schema.
| edoceo wrote:
| I give them Metabase. Metabase pointed to read-replica-3;
| and via Metabase API one can add lots of meta-data about
| tables and fields so the BI folk can point & click to build
| reports (and keep up with schema changes (which I mostly
| resolve with views anyway))
| CalRobert wrote:
| Definitely - I've been surprised at some very complex
| pipelines built with pandas, etc. because someone didn't
| want to use SQL...
| melvinroest wrote:
| > Really the hard part of BI is that folks who need the
| info don't wanna learn SQL.
|
| Data analysts are fine with SQL though. Every "get into
| data analysis as a career" course will teach you SQL (about
| 70% of what the querynomicon teaches [1]).
|
| [1] https://github.com/gvwilson/sql-tutorial
| Swizec wrote:
| > Data analysts are fine with SQL though.
|
| Yes! I haven't seen startups hiring these though. Somehow
| I always end up doing this as a side-gig on my
| engineering job.
| datadrivenangel wrote:
| The hard part of BI is application developers not wanting
| to support a stable data model and changing the schema all
| the time, often made harder by BI people not knowing what
| they want and being stuck with a brittle integration.
|
| Add analytics reporting views in your app database as the
| 'API' is the way.
| cyberax wrote:
| > use read replicas for BI with a good visualization tool
|
| Ugh. That sounds good on paper, but in practice it can become
| a problem. You're making your _database_ schema a part of the
| public API. It's an example Hyrum's Law, people will, sooner
| rather than later, start depending on internal details of the
| data representation.
|
| And your development velocity will crater, as you'll now need
| to update all the reports (that are not necessarily even
| tracked in version control!).
|
| Investing some time early to add code to pull out the data
| relevant for analytics can be worthwhile.
|
| There's also a question of the personal information.
| DanielHB wrote:
| > use read replicas for BI
|
| Yes this is good advice, until you get really large scale you
| don't need anything more fancy than some SQL in a read
| replica.
| closeparen wrote:
| >with such good json support in the most popular SQL
| databases
|
| Wait, was that the reason people were doing NoSQL? JSON
| support? I thought it was about sharding, write scalability,
| etc.
| rco8786 wrote:
| 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.
| gizmov21 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yea agreed, my comment was more of a sidenote than a direct
| response.
| whitepoplar wrote:
| Do you know of a good resource which describes these simple
| best practices?
| tptacek wrote:
| I wrote two:
|
| https://www.latacora.com/blog/2020/03/12/the-soc-starting/
|
| https://fly.io/blog/soc2-the-screenshots-will-continue-
| until...
| whitepoplar wrote:
| Thanks!
| xyzzy_plugh wrote:
| > 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 wrote:
| How are we both right? I think you literally should wait
| until the last minute to start a SOC2 process.
| rendaw wrote:
| GP's point is that having SSO and protected git branches
| _is_ starting the SOC2 process.
| koolba wrote:
| That and having a ticket system (e.g., Jira) to track why
| you touched prod and you can answer just about every
| question.
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My startup has to maintain a HIPAA cert, hence PHI
| scanning. But, you are correct.
| tptacek wrote:
| I posted two guides downthread. It's hard because people make
| it hard, or let people make it hard on them.
| samstave wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ozim wrote:
| 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 wrote:
| SDLC?
| ozim wrote:
| Software Development Life Cycle
| tptacek wrote:
| You absolutely do not need an SDLC process in order to get
| SOC2 attested.
| ozim wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Doesn't "Buy, and buy from certified providers, simple.
| Manage identity centrally...." contradict each other?
| kevan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| snide wrote:
| 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 wrote:
| 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 wrote:
| "support extension" not "super extension"
| maccard wrote:
| > 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.
| plomme wrote:
| Sort of. I've worked with having a rota where engineers would
| spend a week handling support and bug reports which avoids many
| of the pitfalls with the entirely separate "two crews". I wrote
| a bit more about it in
| https://news.ycombinator.com/item?id=43337703#43339972 .
| citrin_ru wrote:
| I would not want to migrate to the "future crew" given that
| "customer crew" getting enough resources (and adequately
| compensated). But even without separation it's typical that
| maintenance is starved while new features getting all attention
| and resources. I would guess separation on two teams would make
| it only worse.
| jpswade wrote:
| I've experimented with a two-crew type system before (Red Team
| for feature development, Blue Team for stability and bug
| fixes).
|
| Rather than treating these as fixed teams, we treated them as
| workstreams that people rotated between every sprint (every two
| weeks).
|
| It worked for about 3 months, until it didn't - by then we had
| grown enough to organising the teams around the business
| capabilities or domains instead.
| film42 wrote:
| 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 wrote:
| 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 wrote:
| Can you really do any of that if you forgot how it's done?
| CaffeineLD50 wrote:
| Elon Musk, for example, appears to be wholly self taught as a
| coder. Do you want Elon doing your code reviews?
| guappa wrote:
| I want him to call me a pedo while I'm trying to save people
| stuck in a cave :D
| ajmurmann wrote:
| 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.
| jayd16 wrote:
| 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.
| petesergeant wrote:
| > 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 code, but usually that's not
| what you're being paid for, and while I consider myself a very
| strong developer, they can be purchased for less than the CTO's
| salary, rather than the more expensive CTO doing the work. FWIW
| I went back to IC after a few years and plan to stay that way
| for the rest of my career.
| yard2010 wrote:
| I would love to know how and why you made that decision and
| how it's going for you (good I bet), can you please
| elaborate?
| petesergeant wrote:
| If "that decision" you mean going back to IC, it's going
| well I think? I work remotely from outside the US, get a
| decent salary, and have a lot less stress than I used to!
| I'm currently working on AI projects I find really
| interesting and I'm getting a decent US developer salary in
| a tax-free company. Plan to retire in 15 years.
| maayank wrote:
| What were good time management resources for you?
| gorgoiler wrote:
| For me, the hacker super power -- the one worth carrying
| forward as you progress in leadership -- is being able to
| prototype something that works and proves a concept.
|
| Realistically, a proof of concept is also only 20% of the work
| an engineer needs to do in order for a change to become
| production worthy and I respect that my sketched ideas need a
| lot more care and craftsmanship than I have time to give them.
| Where I can help other ICs is having that initial 20% idea
| around which they can then build a working idea, and do so
| autonomously.
|
| It feels very cringey to write -- oh brave new world that has
| such people _as me_ in it! -- but I can easily reassure myself
| by remembering all the times earlier in my career where I was
| very grateful to be initially pointed, with quite a lot of
| prompting, in a particular direction and then being given the
| chance to deliver on it.
|
| I'm just a lead, but I can imagine part of being a CTO takes
| the same form as what I've described.
| whilenot-dev wrote:
| I've also had the experience where the CTO was activly coding,
| 80% of the code base were theirs, and the company was hiring
| software engineers who could and wanted to fix up their stuff -
| there was this true luxury problem for this start-up: bad bugs
| everywhere, but patient and resilient customers. They found 4
| willing engineers with good chemistry at first, at least up
| until they were constantly vetoed by the CTO in their
| decisions, because the teams best practices conflicted with the
| CTO-way of "getting things done" - it's a rigid hierachy after
| all, and not a democracy.
| scarface_74 wrote:
| The job of a CTO is _strategy_. The last thing you want is a
| manager that codes. They always end up either being shitty
| managers who don't do the things that I need from a manager -
| making sure the team gets the resources we need,
| prioritization, big picture, etc - or they end up being shitty
| developers because they can't keep their commitments because of
| management responsibilities.
|
| Development is not a "super power". Developers are a dime a
| dozen and if you look at the leveling guidelines of every well
| known tech company, how well you code only makes a difference
| up to the mid level.
|
| Knowing what to develop, knowing how to deal with business, how
| to lead an implementation, managing trade offs, "dealing with
| ambiguity", etc is the differentiator.
| cyberax wrote:
| > The job of a CTO is strategy. The last thing you want is a
| manager that codes.
|
| For a large company the size of Google? Yes. For a startup?
| No.
| scarface_74 wrote:
| For even a 20-30 person company. My CTO at the last startup
| I was working for was constantly flying to talk to
| customers - B2B with long sales cycles. He was the first
| technical person that the CxOs at the other companies spoke
| to.
|
| I find it quite funny when startups reach out to me about a
| "CTO" position that is really just a glorified team lead
| where I would be doing more hands on work and less strategy
| (with lower pay) than I was doing as a mid level (L5)
| employee when I was working at AWS (Professional Services).
|
| I've interviewed former "CTOs" at startups that never did
| handle the scope of work, budgets and strategy that we
| expect from our "staff" level employees (my level now) at
| the medium size company I work at.
| cyberax wrote:
| > For even a 20-30 person company. My CTO at the last
| startup I was working for was constantly flying to talk
| to customers - B2B with long sales cycles. He was the
| first technical person that the CxOs at the other
| companies spoke to.
|
| That's really not a job for the CTO. It's a job for a
| sales engineer (with whatever their CxO title is), and it
| requires a different skill set. You need to be able to
| extract the product requirements from the customer, and
| to distill them for other teams. You don't necessarily
| need to be able to guide their implementation.
|
| > I find it quite funny when startups reach out to me
| about a "CTO" position that is really just a glorified
| team lead
|
| But that's exactly what a CTO position is! Their job is
| to lead the technical teams, on the company level.
|
| And a good CTO will know how to scale up. When you're
| working at a 10-people startup, you'll need to get into
| the details of the code on the actual "team lead" scale.
| Once you grow into a larger company, the job becomes a
| bit more abstract.
|
| I worked at L6/L7 positions in AWS, and it indeed is a
| much more relaxed place if you want it to be. Being a CTO
| in a startup is way more stressful.
| scarface_74 wrote:
| 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.
| cyberax wrote:
| > A CxO doesn't want to talk to a sales engineer who is
| not technical. They want to speak to someone on their
| level
|
| Well, yes. That's why you invent a CxO position (Chief
| Sales Officer?) or maybe "VP of Engineering" for it.
|
| Or you can do the reverse, "CTO" can be a de-facto CSO,
| and you can have a separate CxO position for the
| technical stuff.
|
| > I'm not in sales. I am the first deep technical person
| that a customer talks to (consulting).
|
| This means that you're in sales :)
|
| I think the distinction here matters. CTO is a more
| inwards-facing position, they are responsible for
| formulating and executing the technical plans and
| maintaining the quality of the product.
|
| In other words:
|
| CEO - "we need to get the city of San Francisco as our
| customer"
|
| CSO - "San Francisco needs a bridge"
|
| CTO - "we can build a cable-stayed bridge across the
| Golden Gate"
|
| Tech Lead - "we can use 1 meter cross-section cable stays
| to construct a cable-stayed bridge across the Golden
| Gate"
|
| In reality, especially in startups, there's always going
| to be some level of responsibility sharing.
| scarface_74 wrote:
| > This means that you're in sales :)
|
| You didn't have to be mean :)
|
| But the other half of my job is leading the project once
| the contract is signed
| nedt wrote:
| Every junior has mentors and leaders that help them and that
| they can follow. As you grow you might become one of them.
| That's the reason why you then let others do all of the coding.
| It's not like you unlearn everything, but you let your team
| grow and become you in the end. It can be really satisfying. If
| you can't stop getting your hands dirty then maybe it's not for
| you (yet).
| osigurdson wrote:
| Also, many start-ups seem to do fine without formal management
| structure up to 50 or more employees. The CEO / CTO is still
| coding, talking to customers, hiring, and making the product
| better.
|
| Getting "all managery" in early stages seems like a huge
| misstep to me. The skills needed to successfully create a
| start-up are far more rare than those needed to be a good
| manager.
| dowager_dan99 wrote:
| I really dislike almost everything Oracle and Larry Ellison,
| but he had an early-days adage "There are 2 jobs at Oracle:
| you're either building software or selling it". At a early-
| stage startup most people should be doing both.
| osigurdson wrote:
| Yes, totally agree. Don't hire people to work on "corporate
| culture" until you have money to burn.
| Aurornis wrote:
| At VP/CTO level you don't have time to contribute and maintain
| code. If you do, the VP or CTO title is probably symbolic, like
| when someone is a "CTO" in a team of 3 at a startup.
|
| The real problem is when people take early career roles that
| leave no time to code: They take architect roles where they
| just draw boxes on whiteboards and hop from meeting to meeting,
| or they accept a role labeled "tech lead" that is actually
| management in disguise.
|
| They get comfortable not writing code and years pass until one
| day they need a new job. Now they have to interview for coding
| roles while confronting the fact that they spent a good portion
| of their programming career not writing any code. It doesn't
| come back fast for many.
| upcoming-sesame wrote:
| I tend to agree but also think AI is changing this narrative.
| Now some of the coding can be done by LLM and the "architect"
| skills are more important
| dowager_dan99 wrote:
| This is how auto executives designed the Pontiac Aztek. How
| can you possibly become or develop new "architects" with
| this approach?
| scarface_74 wrote:
| Why would I have to interview for coding roles?
|
| I was an active developer from 1996 - 2018. Between 2016 -
| mid 2020 I started transitioning to team lead/architect roles
| with some coding until I did a pivot to cloud consulting
| specializing in app dev. First it was 50/50 coding/strategy
| until now where it is 10/90 coding/strategy talking to
| customers and leading teams.
|
| I can tell you it was _a lot_ easier finding full time jobs
| both in 2023 and 2024 as a "staff architect" at both product
| companies and consulting companies than regular old "senior"
| [1] enterprise software development jobs. Especially working
| remotely.
|
| Every job posted for generic developers gets hundreds of
| applications and most of the applicants are probably good
| enough to do the job. I applied for hundreds of jobs between
| both times I was looking and heard crickets. They were plan B
| jobs that actually paid less.
|
| On the other hand, in 2023 I had three offers for team
| lead/architect jobs in three weeks and one offer in 2024
| based on replying to one internal recruiter that reached out
| to me.
|
| Besides, I keep between 9-12 months of expenses in a liquid
| savings account outside of retirement savings. That gives me
| plenty of runway to prep for coding interviews if I had to.
|
| [1] "Senior" roles at most non tech companies mean "you codez
| real gud" not that you operate at any different level of
| "scope", "impact" or "ambiguity" than a mid level developer.
| film42 wrote:
| IMO the architect-leader role is an attempt at scratching the
| itch of not being able to code. I've worked with leaders that
| would spend any extra time they had building projects in new
| frontier tech to understand the nuances behind the marketing,
| and I'm sure we've all worked with folks that blindly parrot
| the marketing speak in design meetings.
|
| You don't have to always be building things to be a great
| leader, but I place more trust in a company with a technical
| CTO.
| scarface_74 wrote:
| I can build POCs, or I can just come up with high level
| ideas and ask my most senior architects to do the research
| and build the POC to see if my ideas are feasible.
|
| And I avoid "frontier tech" as often as possible. I want to
| base my implementation on proven technology with a healthy
| ecosystem. I don't want to use "frontier tech" just to read
| a blog post six months later about "our amazing journey".
|
| (I'm not a CTO. I am a tech/implementation lead).
| dowager_dan99 wrote:
| I'm a first-time Director at a SW company with a total org
| under me of ~30 people in 5 different subject areas. I struggle
| with what you highlight, but it's impossible for me to go deep
| in all these areas. MY boss is the CTO and he talks about
| "T-shaped" or broadly across and narrowly deep. I really don't
| like this, but the reality is I view myself as senior-dev level
| in one area, int in another, junior in 2, and barely familiar
| with the third - and I'm by far the most technical of all the
| Director/VPs
| jkingsbery wrote:
| Mostly because of the Maker's Schedule vs. Manager's Schedule
| (https://www.paulgraham.com/makersschedule.html) issue. It's
| really hard to be in a role that deals with a lot of
| randomization and then sit and focus for 4 hours straight on
| something.
| rhubarbtree wrote:
| It's hard but not impossible. First thing is to realise
| you're going to work longer hours than everyone else.
| Sytten wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I call them "shiny team and shitty team".
| DanielHB wrote:
| 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.
| actionfromafar wrote:
| I wonder though if there aren't more forces at play. For
| instance, the business problems some systems try to solve
| really _are_ so large and complex, you might need _some_ kind
| of overseeing function in your company.
|
| Also I have a hunch a team dedicated to providing helper
| "libraries" more than than "frameworks" could provide a lot
| of value without so much downside. If you can call a library
| function without it imposing a whole framework on the rest of
| your codebase, it's more self-contained and can't spill its
| abstractions all over the place.
| DanielHB wrote:
| If your org starts a platform team it is really important
| to have this concept drilled on early. Buffet, not
| framework.
|
| I clearly remember having some discussions with platform
| people in my last job and asking them "why should I use
| your solution instead of getting an open source one that is
| likely better tested and used by more people" and the
| answer was usually "we can help if you run into any
| problems". Well, the "help" is to be planned and
| prioritized in the next sprint and probably will only come
| next quarter. So now the devs in my team need to make PRs
| to the platform people code and beg for reviews, how is
| that better than using the open source?
| neumann wrote:
| argh! PTSD - This was exactly what happened at my last start-
| up. Two of the engineering team and one from the R&D team
| started a platform team and it became a pre-PMF product with
| the slickest pipelines, DevOps, Cloud-cost optimization ready
| to scale to infinity. But with no customers, a broken front-
| end, and a under-funded R&D team as all the effort was put
| into the essential SaaS Platform. Truly put the company back
| 1 year while burning two.
| DanielHB wrote:
| That is actually usually not that bad (if there is, you
| know, revenue). What is really bad is when those teams
| start to roll out a lot of custom code that other teams
| need to use. If they are just configuring standard tools
| for everyone else it is usually fine (as long as they are
| not going to crazy with it).
| bluefirebrand wrote:
| The "platform" team at my company has rolled out a
| completely custom query language that we have had to
| learn and write so they don't have to make new endpoints
| to access different combinations of data
|
| And they haven't documented anything
|
| "There are integration tests, those are documentation go
| read those"
|
| Good times
| SketchySeaBeast wrote:
| That's really the best, when not even intellisense can
| help you.
| DanielHB wrote:
| Yes, this is exactly what I mean.
| SketchySeaBeast wrote:
| This was the first place I worked at. The platform team
| became more and more insular and detached and more and more
| convoluted. As a result, things got harder to add on and soon
| they were telling the implementation teams that the features
| that the clients were requesting couldn't possible be needed.
| Million dollar contracts but no, you don't need to be able to
| put links into text blocks, that's a stupid feature and the
| client can't possibly want it.
| franktankbank wrote:
| _insular architect waves hands_ These are not the features
| you are looking for.
| Aurornis wrote:
| That has been the fate of every platform team I've worked
| with in recent years.
|
| Then they become gatekeepers, refusing to allow anything on
| their platform unless it conforms to their ideal vision. The
| catch is that their vision won't be ready to use for 6-12
| months, so you can't deploy. Now your biggest problems aren't
| engineering, it's constant politicking to get around the
| platform team.
|
| Add to this the concept of "architects" who don't code but
| jump from team to team critiquing their work and you have a
| recipe for getting nothing done. One half of engineering is
| coding and trying to ship, and the other half of engineering
| is gate keeping and trying to prevent anyone from shipping
| fatnoah wrote:
| > Then they become gatekeepers, refusing to allow anything
| on their platform unless it conforms to their ideal vision
|
| As the owner of a platform team, this very common attitude
| of platform teams kills me. Yes, we have a long-term vision
| that we're working towards, but our main goals are two
| accelerate developers AND produce more robust systems.
| Outside of totally egregious violations of company
| standards, my team is expected to focus on how to get
| things done. That means being flexible, working side-by-
| side with other teams, etc. to make sure that a) they're
| able to deliver what they need and b) we help them build it
| in such a way that it can eventually be aligned with our
| utopian long-term vision.
| Aurornis wrote:
| That's exactly how every platform team starts. There is
| inherent tension between accelerating developers and
| building their own systems, though.
|
| In my experience, the platform teams developed an idea
| that their conceptualized system would accelerate
| everything once it was done, but working with product
| teams was a distraction from getting it done. They also
| didn't like the idea of deploying something now and then
| having to rework it later when their ideal system was
| ready. So they defaulted to gate keeping, delaying, and
| prioritizing internal work over requests from the product
| teams.
|
| The only way to get things done was to leverage
| management chains to put pressure on the platform team to
| prioritize getting your thing deployed. This was constant
| no matter how much headcount the platform team received
| because with every new hire they developed new ideas and
| goals to add to their internal roadmap.
|
| It's not supposed to work like this, but it plays out
| this way in many companies.
| fatnoah wrote:
| > It's not supposed to work like this, but it plays out
| this way in many companies.
|
| Absolutely, and I've been on both sides. We go much more
| with a carrot approach than a stick approach, and have no
| ability to "block" any product team from doing things.
| Our goal is to ship things that are useful and lower the
| effort required for product teams to ship their products,
| which is handling basically everything except product-
| specific features. However, product teams don't have to
| use the platform, but then they own the operational
| burden of whatever custom stuff they're using. When that
| happens, we still work with them to minimize that or bake
| that capability into the platform and eventually take it
| over if it's useful to the wider org.
|
| "Success" of the platform team really depends on serving
| the product teams, so blocking or being a barrier goes
| very much against that. We try to provide opinionated
| golden paths, but also try to build a properly abstracted
| stack of capabilities so teams can also extend/consume at
| a lower level if that better suits their needs.
| charlie0 wrote:
| There probably isn't any middle ground in practice then.
| If the product teams have control, then the tech debt
| just keeps building as they keep prioritizing new
| features over longer term maintainability. I see it
| already happening at my startup where product has a lot
| more influence than engineers in terms of what goes on
| the roadmap (there's practically zero time devoted to
| lowering tech debt.)
| incognito124 wrote:
| That's actually the "premise" of Google's SRE book
| chasd00 wrote:
| i think this is where a large portion of the tech
| consulting market comes from. Someone in business gets
| absolutely fed up dealing with IT and trying to get
| something they need in production. Next, they go find a
| budget, call a couple firms, get some proposals, pick one,
| and do it themselves.
| pyrale wrote:
| > It allows your feature team to remain 100 percent focused on
| the future, undistracted by customer support work.
|
| AKA "it allows your feature team to be completely oblivious to
| the horrors they unleash, and keep at it until the ship is
| solidly planted in the iceberg"
|
| Not talking about the conflicts it creates for merging between
| sales-supported feature teams and customer rep-supported
| maintenance teams. Given that the "customer crew" is described
| as something you grow out of, there's no question who wins
| arbitrages.
|
| > It provides another career path for individual engineers,
| especially junior engineers, to learn and level up on your
| team.
|
| "Senior staff doesn't want to fix shit so we have juniors do
| it"
| n4r9 wrote:
| Further down the article:
|
| > The Microsoft blog post referenced above recommends
| swapping some team members between the two crews every week.
|
| This would hopefully mitigate the worst of the effect you
| describe, since everyone eventually gets exposed to the
| consequences of poor feature development.
| pc86 wrote:
| I don't know about you but it's rare that I've neatly
| wrapped up my tasks at the end of any given week. Single-
| day tasks are rare, there is always carry-over work
| including over the weekends.
|
| The only thing worse than a feature that got rushed out the
| door Friday afternoon because you had a completely
| different role come Monday is one that was 80% done then
| passed off to someone else because you had a completely
| different role come Monday.
| BossingAround wrote:
| In my company, we rotate every 5 months. So every 6th
| month, I get put into the customer-facing team for 1
| month. Every other month, a different team member is on
| the customer-facing team.
|
| This is still annoying, but gives you enough time to work
| on features, and enough time to try and crack some
| customer cases (though I could even see being in the
| customer-facing team for more than 1 month, as sometimes,
| this is not enough to debug the issue and provide a fix).
|
| I've got to admit, as much as I dislike being on the
| customer team, it's certainly less annoying than working
| on features, and have constant customer issues
| interruptions though.
| djeastm wrote:
| Maybe when you know you're due to start support the next
| week, you stop feature work sometime the previous week
| and do small maintenance/backlog tasks and or
| documentation. Like a cooldown period before task
| switching
| SkyPuncher wrote:
| 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 off a
| playbook for common support needs then delegate everything
| else out.
|
| It really sucks when you get pulled into support a feature
| you launched, but it really makes you want to build your next
| features better. Better internal documentation, better
| customer documentation, better UX/requirements, better edge
| case handling, etc, etc.
| quacksilver wrote:
| 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 something while I am being pinged about unrelated
| stuff all day.
| dowager_dan99 wrote:
| hand-off needs to be really carefully defined and managed
| efficiently. Client tickets rarely respect arbitrary
| calendars, and the context switching alone can be really
| expensive. The best I've seen is a primary/secondary
| setup where you move from copilot to pilot, so you're not
| coming into everything cold
| SkyPuncher wrote:
| 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
| pc86 wrote:
| > Is dedicating 20% of your team to support _that_ much
| different than the entire team spending 20% of their time
| on support?
|
| Yes, it's [much] worse. Because nobody wants to be the
| support crew, so you end up with the 20% most junior, least
| outspoken people. Then the other 80% cares less about what
| support requirements will come out of the code they're
| writing because it's not their problem.
|
| It's the perfect scenario for the aggressive prima donna
| who thinks their code is golden and everyone else's is
| dogshit.
|
| I feel strongly that your front-line support should be
| full-time (not rotating) front-line customer support. That
| should be their job. If I reach out to a company for
| support I don't want my first contact to be with someone
| who writes code 95% of the time and this is their one week
| answering Zendesk tickets. I want it to be someone whose
| entire job is fielding customer issues and resolving them
| quickly and efficiently.
| BossingAround wrote:
| That's why you rotate everyone, not just those that
| "volunteer"... This way, you're spreading knowledge to
| everyone, e.g. if I'm forced to deal with an issue on
| code you wrote, I'm forced to learn about it.
|
| Of course, I might have to ping you and get you to help
| me with it, so it's less efficient. Then again, if you
| leave the company, I have some knowledge about the
| feature, so... There's tradeoffs for sure.
| dowager_dan99 wrote:
| I believe you're referencing the Engineering Management
| principle of "share shit work evenly".
| madeofpalk wrote:
| Developers must run and maintain the software they build. It's
| as simple as that.
| x0x0 wrote:
| And take the calls.
|
| Don't like being paged at 3am? Write robust software and
| test.
| dowager_dan99 wrote:
| The best development teams WANT this.
|
| They will readily take on the responsibility to get the
| autonomy. The problem is many companies give the former
| without the latter...
| JohnCClarke wrote:
| Well, what's the time horizon? A PE backed outfit, or a CTO
| looking to move on within a year or so, would be well advised
| to follow this guidance. Lots of success now, and the problems
| deferred to later.
| bravetraveler wrote:
| This may put me and my peers out of work _(in a good way)_. SRE
| is a consequence of this function being lost, IMO. Pattern:
| developers don 't like it? Give it to Ops/SRE.
|
| Take away the escape, we will all be better for it.
| plomme wrote:
| The book mentions having a rota:
|
| > 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.
|
| In my experience this works well. With my current and previous
| client each team had a "hero of the week", whose responsibility
| was second line support and monitoring. If nothing came up the
| hero would work on their tasks as usual.
|
| If something does come up the heroes of the week would be
| tasked with solving it or pulling in someone who knows how to
| solve it. This leads to engineers both having to accept
| accountability for writing shoddy code, but it also exposes
| engineers to the wider codebase when pulling on threads. It
| also solves the issue where no-one or the same person always
| takes responsibility for handling bugs.
| marcinzm wrote:
| Isn't this just called on-call? That's very different from a
| separate team.
| plomme wrote:
| Maybe - though I associate being "on-call" with being
| expected to respond outside of normal business hours which
| was not the case in the teams I worked in.
| dowager_dan99 wrote:
| This just sounds like having a point developer. The challenge
| is too many companies expect this without giving up a
| feature-dev headcount. Any work the get done aside from point
| is a bonus and unplanned.
| hnthrow90348765 wrote:
| >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.
|
| This is the PM's job - one or a few people who are deciding the
| vision of how all of the features fit together based on
| feedback by working with customers. Customers (esp. non-
| technical ones) will definitely not have a coherent product
| vision and only want immediate fixes regardless of what else
| may be planned. Customers may also not communicate to one
| another and their feedback can conflict.
|
| If you put this burden on developer shoulders, they now have to
| manage all of that communication in addition to requiring
| technical skills to know the code base and maintain it well, on
| top of every developer needing to have the same coherent vision
| to make thoughtful decisions. That's now two to three jobs in
| one depending if your developers also manage infrastructure
| like many roles are requiring these days.
| marcinzm wrote:
| 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.
| hnthrow90348765 wrote:
| I'm okay with that knowing those developers are doing two
| jobs for the pay of one. And most products turn into that
| once the original developers leave.
|
| It's not like you can't learn the product through the PM
| either.
| pc86 wrote:
| I think you're conflating "doing two jobs" with "not
| being allowed to just type JavaScript into a computer all
| day in isolation and being expected to actually
| communicate and think about things other than data
| structures and algorithms."
|
| If you're a true senior software engineer as most of us
| claim to be coding is a small part of your job, not your
| entire job.
|
| You should be learning the product through the PM for
| sure, and I don't think a senior engineer should be doing
| first-level support, but especially in small companies
| talking to customers is good and should be expected from
| basically everyone who is working on the product.
| hnthrow90348765 wrote:
| Let's flip this around and see if it still fits:
|
| "the PM can't be expected to sit in meetings all day,
| they need to learn the coding side of it too so they know
| the potential limitations of the features they want to
| suggest"
|
| But if a PM does have a technical question, they don't
| need to go google stuff and figure it out - they ask a
| developer.
|
| Likewise, when a developer has a product question, why
| can't they rely on a PM to answer that for them? Why must
| we _also_ be expected to be in customer meetings and
| putting in extra effort, when PMs definitely won 't put
| in effort to learn the technical side?
| tristor wrote:
| Yes, it still fits when you flip it around, speaking as
| an engineer turned technical PM. PMs should absolutely be
| technical and have enough depth of understanding about
| the product they can figure things out for themselves, as
| well as write code.
|
| That's not going to prevent the PM from asking questions
| to the developers though. I ask questions all the time,
| because I want to validate my mental model with others
| and verify my understanding. Asking questions is a /good/
| thing.
|
| The part where you are missing the boat is acting like
| customers are a distraction or an enemy. Customers are
| /the point/, the /only/ point, really at the end of the
| day. Every role in every business is customer-facing to
| some degree.
| marcinzm wrote:
| > But if a PM does have a technical question, they don't
| need to go google stuff and figure it out - they ask a
| developer.
|
| In a good organization they first try to figure it out
| themselves versus distracting a developer (thus costing
| possibly hours of productivity due to breaking someone's
| flow). The same way a developer would first try to answer
| their own question before they start badgering another
| developer.
| marcinzm wrote:
| Unless you're working 80 hours a week you're not doing
| two jobs. You're doing one job.
| hnthrow90348765 wrote:
| Giving away flexibility for free is a collectively dumb
| move on our part. If someone knows you can take on coding
| tasks and customer interviewing vs. just coding, you are
| more valuable to them and they should pay more for it.
|
| They've already gotten away with adding infrastructure
| and architecture (aka system design) rolled into one
| developer position. And putting it behind long and
| stressful interview processes. I'm not doing PM stuff on
| top of all that and not getting the pay and prestige for
| it.
| marcinzm wrote:
| 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.
| regularjack wrote:
| 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.
| marcinzm wrote:
| You're right, I didn't mean there shouldn't be PMs but
| rather that the PMs shouldn't be the sole people
| concerned with product.
| swat535 wrote:
| 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.
| esafak wrote:
| It is not a problem if you measure and reward the infra team
| for their ability to enable the feature team, such as change
| lead time and deployment frequency, as well as the the
| stability metrics that the infra team might want to pursue.
| agnishom wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| MichaelMoser123 wrote:
| 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 wrote:
| I'm still none the wiser. What attitudes?
| Earw0rm wrote:
| 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."
| MichaelMoser123 wrote:
| > "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 situation where
| you might need "diversity of thought" - and the ability to
| incorporate different kinds of feedback.
|
| Though I don't quite think that you will find this insight in
| this frigging book.
| marcinzm wrote:
| I'd say it's the opposite. Diversity of thought is what
| requires a top-down structure to force everyone to
| eventually go down the same path despite believing it's not
| the right path.
|
| If require everyone to just organically align based on
| whatever argument is made that the group sees as the best
| then, congratulations, you have a mono-culture around that.
| That's not how most people act or react.
| Aurornis wrote:
| > 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's the cynical interpretation, but more often than not I've
| seen culture fit used to protect candidates from taking a job
| they'll loathe.
|
| At one of my first jobs they tried to ban anything that could
| be called culture fit from the hiring criteria. It led to a
| couple hires yo joined, hated the company, and quit within
| weeks or months. The first one was a candidate who emphasized
| planning and predictability and complained that past employers
| had moved too fast. We were a startup. Predictably, he hated
| it. But we were disqualified from voicing those concerns in the
| hiring decision process because it was "culture fit" and they
| were afraid it would lead to discrimination.
|
| There were several other instances before the policy quietly
| went away and we were allowed to evaluate candidates for
| compatibility with our engineering culture once again.
| underdeserver wrote:
| 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 wrote:
| Probably no place implements all of them, but with all best
| practices, they should be asymptotic.
| underdeserver wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| hansmayer wrote:
| 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.
| jon-wood wrote:
| One company I worked for had very cyclical sales spikes,
| culminating in Christmas week each year. During that week
| _everyone_ did operations, we had developers out in
| delivery vans carrying parts of the extra large orders to
| customer 's houses, and at least one back in the office
| mostly handling calls from customers and suppliers.
|
| Without fail that week generated a stack of minor
| improvements that could be implemented in a matter of days
| in the new year, because we were out there using the
| software we wrote, and had the necessary knowledge of how
| it worked to spot places where we could save people
| cumulative days of work with a 30 minute patch.
| maccard wrote:
| Not OP, but I have.
|
| What you've said here is exactly why the CTO should be on the
| support calls with the most problematic customers. They need
| to be the ones who shield the rest of hte company from
| letting this happen, and the only way to do that is to
| experience it first hand to see _just_ how disruptive some
| clients are.
| robjan wrote:
| 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.
| pphysch wrote:
| If you have to constantly tell customers to RTFM, you have a
| poor product. Or at least poor documentation. But no amount
| of documentation can paper over fundamentally poor product
| design, because docs are also technical debt.
|
| Even if devs aren't taking calls directly, there should be a
| product manager communicating this feedback to developers.
| hansmayer wrote:
| Exactly - not having empathy towards customer is something our
| entshittified big-tech platforms can afford, at least for a
| while. For a nimble startup, that is the path to death. I agree
| that engineers absolutely should not be shielded away from
| their design decisions. Not that they should sit on support
| calls all day long, but spending half a day per quarter in such
| calls can be very revealing. Some of the best understanding of
| my customer pains, and sometimes even issues I would have not
| even aware of, came out of talking to customers, or just
| listening in to the calls.
| hansmayer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Did you read the first or third sentence in point 1?
| andruby wrote:
| > 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 wrote:
| Someone has been bitten by Leo Tolstoy. "Release and Downtime",
| 700 pages.
| osigurdson wrote:
| Deciding up front on the meeting frequency and type sounds more
| like how to run a department at a government agency.
| mocmoc wrote:
| 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.
| esafak wrote:
| 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.
| lobsterthief wrote:
| 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.
| frantzmiccoli wrote:
| Any chance someone has an epub or a PDF of this?
| croisillon wrote:
| https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/ma...
| codingdave wrote:
| > 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.
___________________________________________________________________
(page generated 2025-03-12 23:01 UTC)