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.
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.
> 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.
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))
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.
> 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]).
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.
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.
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
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?
As someone working with datastore/firestore in a product first created around 10 years ago I wish you could have been there at the time. Running a migration to add a boolean field to all existing documents of a certain type took ~40 hours.
Funny thing is we are now migrating stuff out of datastore (and new stuff is not in datastore to begin with) into an RDBMS, but we are doing it microservice style with each microservice having its own separate database. So relationships are now cross-services concerns...
Not that having EVERYTHING in a single DB is the best approach always, but IMO we should default to keep everything in one single DB.
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.
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.
3/4 companies in the Bay Area senior software engineer interviews require a System Design interview where they will tell you "what if you had 10m users" and expect a distributed write-heavy sharding answer
You’re not wrong in the literal sense. But the “inside baseball” of that question is just that it’s a prompt to talk about how you would horizontally scale a system should the need arise. It’s not a prompt to start questioning whether 10mm or 200mm is the specific limit.
Lots of people were mad that my employer developed a new distributed NoSQL database engine, but it was literally just an API to encapsulate what an application doing "sharded MySQL" would do in its own data tier. A lot of this is a question of framing and storytelling.
Sharding, write scalability, and similar are the technical advantages that can matter at scale (and mattered a lot more before SSDs became so common), but I think for most users the only tangible ?benefit? was the schema less nature.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I'm a few years out of date, but I don't believe that any sort of PHI scanning is specifically required by HIPPA either, though I've seen plenty of consultancies happy to sell you it.
The section on performance management is circular and vague: a good one is motivating and a bad one is demotivating. OK. Glad we got that out of the way.
The whole intro reads like a puffy resume and lots of gilding. Even a section of gushing testimonials.
And he puts his name on the title so you don't gotta read the author byline. Total cheese.
The section on performance management is at least five pages long, and it covers compensation, leveling, job titles, PIPs, and firing. Perhaps you mistook the introduction to the section for the entirety of the section?
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.
> 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.
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).
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.
Of course not, that was just part of the story to draw the picture. Where it might be required to pay for some consultant that will help with initial setup.
But maybe not go full attestation mode right away - but also tricky to find one.
I think this stuff is highly folkloric and that any startup that picked a reasonable high-touch auditor and talked to some friends about their experiences could get through a Type 1 with virtually no effort (outside of their bizops team, who the auditors will definitely harass).
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.
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).
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Getting Things Done and Seven Habits set the foundation, and then just iterating on those principles until I found systems that worked for me. Big believer in not using the Inbox as a task list, and apps that make setting, repeating, and organising reminders very easy.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
There's nothing wrong with working in sales! No kink shaming here.
Startups usually require people to wear several hats at once. That's normal. But suppose that your company grows to be 20 times larger. Would you still be working with customers or directing the projects to implement their requirements?
I’m far from the only staff level consultant at the company. Doing requirement analysis is considered “leading a project”. It’s a billable project assigned to a staff level consultant once sales brings in a customer and usually last 3-5 weeks.
While I’m considered a specialist for “cloud native applications”, I can pinch hit for almost any of our specialties at this level except for migrations.
Once the customer accepts the proposal, then leading the implementation is considered another project that is assigned to a staff level consultant. The “architects” (non staff) are the specialists that lead their “work stream” and are hands on and leading their sub team depending on the size of the work.
An implementation is made up of multiple work streams (epics).
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.
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
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.
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).
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.
Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew".
I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.
At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in their spare time on what they wanted as long as they saw value for the company in it. It was a good bargain. Everyone else was grateful the small team was doing the dirty work and the maintenance team was delighted they could use the remaining time working on things that had always bugged them, do research, etc. This was a few years ago and I forgot details but I vaguely remember that we got some really cool improvements and research from them. The people on that team also were really excellent and self-motivating which helped make this a success but also more expensive.
> 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.
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.
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.
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 .
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.
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."
> 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"
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.
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.
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
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
> 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.
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.
> 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.
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.
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.
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
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.
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
> 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.
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.
> 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.
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.)
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.
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.
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).
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"
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.
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?
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.
>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.
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.
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.
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.
"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?
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.
> 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.
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.
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.
In my experience, both are needed. Product owners and developers who understand the product. It's possible to have both, they're not mutually exclusive.
Yes, but it's the Product Owner's responsibility to clearly understand the requirements from both customers and the business and communicate them clearly to engineering.
Having engineers handle "support calls" doesn't make much sense, they are not equipped to manage product feedback or understand the business implications.
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.
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.
> 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.
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.
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.
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.
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.
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)
> 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.
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."
> "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.
It can go either way. A top-down company can be interested or disinterested in culture. Some would argue that for a company to affect disinterest is an active and consequential choice. Consider the "bring your whole self to work" touchy-feely open-plan Valley startup vs a trad IBM-style cube farm. The latter is arguably more accommodating of genuine oddballs, for "good fences make good neighbours" kind of reasons.
As regards pivoting, think about it like a joint having freedom of movement on more than one axis. You want to keep flexibility in as many as possible, but also straight-line speed/strength/efficiency. Somewhere there's going to be a trade-off. A genuinely diverse team (I don't mean just "ticking all the DEI boxes", but profound differences in background and life experience) takes longer to find their groove than a bunch from similar social backgrounds, but they'll have insights that a "TV sitcom cast"-looking team never will.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
I agree. Product owners should be part of the team.
The separation is because I often saw Product owners saying “how” something should be made in the stories. Or invite all the developers to meetings.
If your developers need a meeting for more details, they’ll ask for it.
And let them decide how to make something; as a PO your job is to keep a lot of nonsense away from your team and talk about “what” to make with the client. Perhaps the tech lead joins some of these conversations, especially in the beginning.
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.
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.
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.
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.
> 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.
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))
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.
> 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
> 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.
Definitely - I've been surprised at some very complex pipelines built with pandas, etc. because someone didn't want to use SQL...
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.
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.
My default position nowadays is “Postgres” and engineering should have to justify why it is insufficient if engineering wants to use something else. It’s worked pretty well
Hahaha, that is good, not justify why to use a certain tech, but rather justify why not just use postgres
This should be default decision-making process. If your proposition is to move the compromise scale please not only provide the benefits, but also the drawbacks and analysis on transition. This forces proposal to analyze existing status quo and reasons behind it, which is often enough for the proposal to be withdrawn.
Distant relative of 5 whys. We need NoSql document store -> so we can store json blobs -> so we can do databasing at app level -> because DBAs with their insistence on schemas are slow. Oh, so we can solve the problems by hiring one DBA and maybe training two devs instead of hiring full dev team and refactoring stuff for a year?
As someone working with datastore/firestore in a product first created around 10 years ago I wish you could have been there at the time. Running a migration to add a boolean field to all existing documents of a certain type took ~40 hours.
Funny thing is we are now migrating stuff out of datastore (and new stuff is not in datastore to begin with) into an RDBMS, but we are doing it microservice style with each microservice having its own separate database. So relationships are now cross-services concerns...
Not that having EVERYTHING in a single DB is the best approach always, but IMO we should default to keep everything in one single DB.
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.
>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.
Ah yea the old “web scale” phase. I think everyone’s more or less accepted that very, very few startup-level (or even SMB-level) workloads need more scalability then Postgres/mysql gives.
My favorite example is that Twitter used mysql for all tweets, writing ~5k/s 24/7/365, until about 2016ish. Well into being a public company with billions in revenue and 300mm+ MAUs.
Has everyone accepted that?
3/4 companies in the Bay Area senior software engineer interviews require a System Design interview where they will tell you "what if you had 10m users" and expect a distributed write-heavy sharding answer
You’re not wrong in the literal sense. But the “inside baseball” of that question is just that it’s a prompt to talk about how you would horizontally scale a system should the need arise. It’s not a prompt to start questioning whether 10mm or 200mm is the specific limit.
Well that's the thing. You don't need a NoSQL database to design a data tier that scales to accommodate distributed write-heavy workloads.
Lots of people were mad that my employer developed a new distributed NoSQL database engine, but it was literally just an API to encapsulate what an application doing "sharded MySQL" would do in its own data tier. A lot of this is a question of framing and storytelling.
Sharding, write scalability, and similar are the technical advantages that can matter at scale (and mattered a lot more before SSDs became so common), but I think for most users the only tangible ?benefit? was the schema less nature.
> 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.
> 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.
It can definitely become a problem. But if you’re at that point, you don’t need a guide that explains SQL databases to you. :p
Realistically this guide should be bifurcated in terms of scale.
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.
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.
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.
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.
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.
Yea agreed, my comment was more of a sidenote than a direct response.
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.
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.
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.
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.
By all means use tools like these, but be very careful, because they (and auditors that use them) will lead you into engineering changes that are not required for SOC2 and may not be what's best for your team. For instance: there is absolutely no need to set up PHI scanning or a WAF to get SOC2.
My startup has to maintain a HIPAA cert, hence PHI scanning. But, you are correct.
I'm a few years out of date, but I don't believe that any sort of PHI scanning is specifically required by HIPPA either, though I've seen plenty of consultancies happy to sell you it.
I posted two guides downthread. It's hard because people make it hard, or let people make it hard on them.
The section on performance management is circular and vague: a good one is motivating and a bad one is demotivating. OK. Glad we got that out of the way.
The whole intro reads like a puffy resume and lots of gilding. Even a section of gushing testimonials.
And he puts his name on the title so you don't gotta read the author byline. Total cheese.
The section on performance management is at least five pages long, and it covers compensation, leveling, job titles, PIPs, and firing. Perhaps you mistook the introduction to the section for the entirety of the section?
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.
> 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.
How are we both right? I think you literally should wait until the last minute to start a SOC2 process.
GP's point is that having SSO and protected git branches _is_ starting the SOC2 process.
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).
That and having a ticket system (e.g., Jira) to track why you touched prod and you can answer just about every question.
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.)
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.
You absolutely do not need an SDLC process in order to get SOC2 attested.
Of course not, that was just part of the story to draw the picture. Where it might be required to pay for some consultant that will help with initial setup.
But maybe not go full attestation mode right away - but also tricky to find one.
I think this stuff is highly folkloric and that any startup that picked a reasonable high-touch auditor and talked to some friends about their experiences could get through a Type 1 with virtually no effort (outside of their bizops team, who the auditors will definitely harass).
SDLC?
Software Development Life Cycle
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.
Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?
Manage identity centrally is probably referring to using an identity management system like Okta, Microsoft Identity, or hosting your own IdP and using strong hardware 2FA. You don't want people creating their own accounts manually for everything or shared accounts that everyone knows the password for (or is on a shared spreadsheet that the entire company has access to).
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.
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.
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.
Do you know of a good resource which describes these simple best practices?
I wrote two:
https://www.latacora.com/blog/2020/03/12/the-soc-starting/
https://fly.io/blog/soc2-the-screenshots-will-continue-until...
Thanks!
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.
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.
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.
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).
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
This is how auto executives designed the Pontiac Aztek. How can you possibly become or develop new "architects" with this approach?
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.
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.
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.
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.
Can you really do any of that if you forgot how it's done?
> 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.
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?
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.
What were good time management resources for you?
Getting Things Done and Seven Habits set the foundation, and then just iterating on those principles until I found systems that worked for me. Big believer in not using the Inbox as a task list, and apps that make setting, repeating, and organising reminders very easy.
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.
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.
Yes, totally agree. Don't hire people to work on "corporate culture" until you have money to burn.
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.
It’s hard but not impossible. First thing is to realise you’re going to work longer hours than everyone else.
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.
> 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.
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.
> 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.
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.
> 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.
> 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
There's nothing wrong with working in sales! No kink shaming here.
Startups usually require people to wear several hats at once. That's normal. But suppose that your company grows to be 20 times larger. Would you still be working with customers or directing the projects to implement their requirements?
You probably won't have bandwidth for both roles.
I’m far from the only staff level consultant at the company. Doing requirement analysis is considered “leading a project”. It’s a billable project assigned to a staff level consultant once sales brings in a customer and usually last 3-5 weeks.
While I’m considered a specialist for “cloud native applications”, I can pinch hit for almost any of our specialties at this level except for migrations.
https://www.linkedin.com/advice/3/how-do-you-conduct-consult...
Once the customer accepts the proposal, then leading the implementation is considered another project that is assigned to a staff level consultant. The “architects” (non staff) are the specialists that lead their “work stream” and are hands on and leading their sub team depending on the size of the work.
An implementation is made up of multiple work streams (epics).
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.
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
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.
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).
Elon Musk, for example, appears to be wholly self taught as a coder. Do you want Elon doing your code reviews?
I want him to call me a pedo while I'm trying to save people stuck in a cave :D
Lol. Nice one.
> 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.
Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew".
I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.
At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in their spare time on what they wanted as long as they saw value for the company in it. It was a good bargain. Everyone else was grateful the small team was doing the dirty work and the maintenance team was delighted they could use the remaining time working on things that had always bugged them, do research, etc. This was a few years ago and I forgot details but I vaguely remember that we got some really cool improvements and research from them. The people on that team also were really excellent and self-motivating which helped make this a success but also more expensive.
"support extension" not "super extension"
> 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.
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.
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.
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 .
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.
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."
> 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"
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.
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.
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
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
> 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.
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.
I believe you're referencing the Engineering Management principle of "share shit work evenly".
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.
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.
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.
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
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.
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
> 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.
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.
> 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.
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.)
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.
That's actually the "premise" of Google's SRE book
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.
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).
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
That's really the best, when not even intellisense can help you.
Yes, this is exactly what I mean.
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.
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?
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.
insular architect waves hands These are not the features you are looking for.
>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.
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.
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.
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.
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?
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.
> 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.
Unless you're working 80 hours a week you're not doing two jobs. You're doing one job.
Giving away flexibility for free is a collectively dumb move on our part. If someone knows you can take on coding tasks and customer interviewing vs. just coding, you are more valuable to them and they should pay more for it.
They've already gotten away with adding infrastructure and architecture (aka system design) rolled into one developer position. And putting it behind long and stressful interview processes. I'm not doing PM stuff on top of all that and not getting the pay and prestige for it.
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.
In my experience, both are needed. Product owners and developers who understand the product. It's possible to have both, they're not mutually exclusive.
Yes, but it's the Product Owner's responsibility to clearly understand the requirements from both customers and the business and communicate them clearly to engineering.
Having engineers handle "support calls" doesn't make much sense, they are not equipped to manage product feedback or understand the business implications.
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.
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.
Developers must run and maintain the software they build. It's as simple as that.
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...
And take the calls.
Don't like being paged at 3am? Write robust software and test.
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.
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.
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.
Isn't this just called on-call? That's very different from a separate team.
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.
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.
I call them “shiny team and shitty team”.
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.
Popular in 2023 (452 points, 156 comments) https://news.ycombinator.com/item?id=37971795
I'd like to recommend a book about same topic written by a friend of mine many years ago:
https://ctofieldguide.com/
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)
> 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.
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."
> "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.
It can go either way. A top-down company can be interested or disinterested in culture. Some would argue that for a company to affect disinterest is an active and consequential choice. Consider the "bring your whole self to work" touchy-feely open-plan Valley startup vs a trad IBM-style cube farm. The latter is arguably more accommodating of genuine oddballs, for "good fences make good neighbours" kind of reasons.
As regards pivoting, think about it like a joint having freedom of movement on more than one axis. You want to keep flexibility in as many as possible, but also straight-line speed/strength/efficiency. Somewhere there's going to be a trade-off. A genuinely diverse team (I don't mean just "ticking all the DEI boxes", but profound differences in background and life experience) takes longer to find their groove than a bunch from similar social backgrounds, but they'll have insights that a "TV sitcom cast"-looking team never will.
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.
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…
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.
I'm still none the wiser. What attitudes?
> 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.
Some people like videos, some like text. Both are an investment in effort and payoff. Gen AI makes it easy to do both now.
> 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.
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.
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.
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.
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.
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.
Not all products can be a box with a single red button on top.
And the best documentation is useless if someone doesn't bother to use it.
Also, it's normally a few annoying customers that want to be hand held, rather than all customers having the same problem with the same issue.
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.
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.
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.
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.
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.
It depends on your budget and size. A 3-person team doesn't need a CTO that doesn't code. The CTO there might well be the CEO too.
Exactly
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.
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.
Probably no place implements all of them, but with all best practices, they should be asymptotic.
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.
Deciding up front on the meeting frequency and type sounds more like how to run a department at a government agency.
Someone has been bitten by Leo Tolstoy. "Release and Downtime", 700 pages.
Any chance someone has an epub or a PDF of this?
https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/ma...
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.
> 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.
I agree. Product owners should be part of the team.
The separation is because I often saw Product owners saying “how” something should be made in the stories. Or invite all the developers to meetings.
If your developers need a meeting for more details, they’ll ask for it. And let them decide how to make something; as a PO your job is to keep a lot of nonsense away from your team and talk about “what” to make with the client. Perhaps the tech lead joins some of these conversations, especially in the beginning.
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.
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.
Did you read the first or third sentence in point 1?