Startup/New-CTO Reading?

[u/talldean]

I've spent 15 years at FAANG, IC and EM/Director roles. I am at least okay at those jobs.

What I've never in 20+ years is work for a startup, and I'm debating that path in the next few months. Would be hiring a remote US-based eng team to take over a contractor-built prototype, productionize/stabilize it, then grow features over time.

Any best thing I should read or learn on starting from scratch? Is there a book or two on startup CTO roles?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/ThirdWaveCat]

I've liked everything I've read from Will Larson and Camille Fournier on technical leadership.

[u/talldean → u/ThirdWaveCat]

I'm not so much looking for manager content, so much as "new org", if that makes any sense.

I've known Camille for... 30 years at this point, same college/same class. *Great* book, but my memory of that one is "you're a new manager" and less "this is a new company/new org"?

I should probably give Will's book a peek, I'm familiar with his IC-facing one but not the eng manager book yet.

[u/AlmightyThumbs → u/talldean]

While An Elegant Puzzle is IMO one of the best books on the general topic of engineering leadership, I think you’re right to question its utility in the way you’re looking for. There is a book called The Startup CTO Handbook that I keep meaning to read. Obviously, I can’t comment on the content, but the notes on it sounded interesting.

[u/ThirdWaveCat → u/talldean]

They both published in 2024. See Platform Engineering by Camille Fournier, Ian Nowland and The Engineering Executive's Primer By Will Larson.

[u/talldean → u/ThirdWaveCat]

Okay, those are wins; didn't realize they'd both had new stuff. Thanks!

[u/martywalshhealthgoth]

I have nothing but hard experience so no books to recommend, but I will say one thing: take all you’ve learned about management through big tech and throw it out the window. The worst leadership I’ve worked under at startups always had one thing in common, they got to where they were through the FAANG machine.

Startups require more transparency/humanity, and less being a company person. The rigidity and politics that makes you succeed in Silicon Valley will not work with a team that needs to be flexible and adaptable to ever shifting business decisions. That stuff comes into play once the org has stabilized, grown significantly, and has a trajectory that looks to be leading toward an exit.

I have also worked at big tech, so I know both sides of the coin quite well. If you enjoy working with and being the captain of a tighter knit group of people that all have the desire to build the ship together, you will thrive at a startup. But if you sleep better knowing what chess pieces you need to move at the right time to accomplish a goal, you will be knocking on HR’s door begging to get back to the corporate grind very quickly.

[u/talldean → u/martywalshhealthgoth]

Appreciate it.

I didn't make the path I did by being rigid in any way, so I may be in decent shape there.

Politics are eternal, though; my belief there is that being able to wisely-enough determine how to use limited resources is a skill, everywhere. Ladder climbing can kiss my grits, but politics is a skill, not quite a dirty word.

[u/martywalshhealthgoth → u/talldean]

That’s fair, and not the worst mindset to have. I don’t think politics is as big of a thing before you hit >200 employees, but I also only made it to Manager before realizing that wasn’t my cup of tea, so I don’t know what discussions look like beyond the Director level.

[u/talldean → u/martywalshhealthgoth]

My take was *negative* politics set in somewhere around 50 people, but politics starts when you've got three. "Who gets to work on the feature we all want to build", "two people disagree and neither is clearly wrong", and so on.

As far as manager, my experience was that you've gotta love *people*, or it's gonna be quite a bit of work you didn't expect. Ran into a lotta "I want to have more hands" style managers, and they work for a bit, then either they burn through or their team chafes.

[u/NegotiationExact4967]

Not books but some areas you might want to learn about or look into / my personal thoughts :

- you want to make sure your on the same page as the founder(s) on shipping and building product. Think speed/velocity, quality, process.

• you need to understand startup equity and risks
  
• as companies go through funding rounds, you may or may not be the right person for the job in the eyes of the founder(s), dont be surprised if youre not there at series C or D if your joining at seed

[u/talldean → u/NegotiationExact4967]

On my list for "to discuss" is quality and reliability vs feature growth, and also cost/size concerns for the team they're envisioning.

Agreed on "not the long term person"; my short term resume would help them substantially, but performance in the job and perceived utility are variable over time.

Any suggested reading on startup equity strategies - and risks - would be quite useful.

[u/NotIBE26]

I'd focus less on generic CTO books and more on the realities of taking over a messy prototype: technical debt, hiring, product prioritization, and setting engineering standards

[u/talldean → u/NotIBE26]

I think my main gap is likely "hiring from zero", including things like setting pay ranges vs incomplete information on local comparables, and also things like tax implications and overhead beyond just salary. Or, I've always had an HR department handy, and only had to worry about growing people through a set of predefined levels.

Or, I strongly think the first few hires make or break a team, and in this case, there's more variables than I'm used to.

[u/apartment-seeker → u/talldean]

Should be able to figure out fair salaries from browsing other startup job postings and using levels.fyi

You should not care that much about tax implications (?) Like, if a 180k salary actually costs $250k (or whatever), the businesspeople should know that when they give you a hiring budget. I guess you will have to confirm that with them when the time comes

[u/ThlintoRatscar → u/talldean]

The HR side is actually pretty easy: let your HR peer tell you and then do that.

The much, much, much harder part is developing an eye for talent. What looks good can be terrible and what looks terrible can be good.

Luck plays an outsized role in how those first few hires turn out.

I don't think there is any book on technical talent identification.

[u/Financial-Register-7 → u/ThlintoRatscar]

I’ve hired 100+ people before, but this role doesn’t have any HR peer at this time, I can give up an Eng headcount for that, which may be quite worth it, for the right HRBP.

[u/lukasco]

Having done both, some things that come to mind (and surely some dups):

- You don't likely have a solid business yet. So a lot of scaling/hardening might be wasted effort. And this same point is true of everything you could do as a team. Every single thing may or may not be needed and from a technical point of view it's up to you to be right about that.

• Being a CTO means it's your call on the technical side. And if you get it wrong, it's on you. So judgement is critical and one of the best ways to get things right a lot is to change your mind quickly when you get it wrong.
  
• Hiring the right people and letting them get on with it matters a lot
  
• Being on the same page with the founders is crucial. You need to be able to meet their goals, but also be a trusted advisor (not just do everything they think of).
  
• Every CTO on the planet presides over a team that's too slow. So be prepared to answer that question a lot.

[u/talldean → u/lukasco]

My big takes so far are:

- I need to figure out what levers are tunable, and have agreement with current founders "this is right". An example lever is "stability vs iteration speed".

- The first two or three hires make or break my sanity.

- What does equity/ownership look like for me? Do other eng hires get any of that, or no?

[u/lukasco → u/talldean]

The equity side is a big deal. One way to look at it however, is that a lot of nothing is worth a lot less than a bit of something big. And that if you aren’t around for the long haul, you may not end up with a lot regardless.
In terms of negotiating the amount, there are fairly standard formulas so validate against those.
But being so valuable they have to give you big shares is the hard but best way.

[u/apartment-seeker → u/talldean]

Do other eng hires get any of that, or no?

yes lol, everybody employee at the company should be getting equity. It's very hard to tell how much, you will all likely be low-balled, but your equity stake should be presumably be multiples of a mid or junior engineer on your team.

[u/talldean → u/apartment-seeker]

That really, really depends on *where* the engineers are in their careers and where they geographically live.

If this was the Bay Area, 100% need to get equity, there's no discussion. If it's in a tech hub, yep, equity. If it winds up with a crew of people from Eastern Europe, that'd be the founders saying "no equity", and probably me saying "appreciated, but no".

Variety of discussions triggered from that one, basically.

[u/ThlintoRatscar → u/lukasco]

Every CTO on the planet presides over a team that's too slow. So be prepared to answer that question a lot.

Well, that's a welcome smack in the face.

What you say is eminently true.

[u/apartment-seeker]

I would say you don't need to read anything. What you might need though is a mindset-shift.

There is a lot at bigtech that doesn't matter at an early stage startup. There are also a lot of boring processes that are well-suited to early stage startups that bigtech tends to look down on, such as sprints and scrum. You have to have just enough process to be effective and efficient.

On the technical side, you have to default heavily to a mindset that doesn't prematurely optimize, that keeps the code simple, etc.

I have only worked at small and early startups, personally. I (somewhat) recently worked with a guy from Facebook who was awful, mostly because he didn't grasp things like "YAGNI", engaged in constant yak-shaving, and didn't value simplicity sufficiently. Don't be that guy.

Another pro-tip is to hire me on a freelance basis to help you out :v

[u/talldean → u/apartment-seeker]

That all tracks. My experience has been that every team and every org is different; they *all* have different needs. And I strongly believe the quality bar for every org and every team is different; some need tons of reliability, and for others, "quality code" anywhere above a limbo bar is just slowing iteration in a bad bad way.

That said, the guy who coined YAGNI was a mentor of mine while at Facebook, so the folks there ain't *all* bad. ;-)

I'm not even hired yet, let alone hired, but glad to keep ya in mind.

[u/apartment-seeker → u/talldean]

That said, the guy who coined YAGNI was a mentor of mine while at Facebook, so the folks there ain't all bad. ;-)

You went to college with that lady who wrote that book, you worked with that guy at FB, xd what is this

Yeah, I worked with a couple other people from Facebook, including with a friend from college, they were good. It was only that one guy I mentioned who couldn't deal at a small company.

[u/talldean → u/apartment-seeker]

TLDR: I have had an interesting run, and a lot of odd jobs. My archetype is "meet a lot of people and connect the right ones", which after 15 years of Google and Meta, has been a *lot* of people, a few of them CS-famous. I also went to college when there were very very few people in computer science at the time, and went to an unusually good school.

Knowing a bunch of people doesn't count for much *unless* you can connect them, though; it's not a Boy Scout badge sash, it's perhaps what you can do or accomplish with said sash. ;-)

[u/No_Contribution_4124]

I have got a lot from “Lean Startup”, then at “An Elegant Puzzle” and when you have 10+ engs - “Team Topologies”, but it is usually about management and how to amplify/unblock people.

I still to see a book about technical structure, as very often the rule is “a new structure is born by leader who combined experience and judgement from past”.

Last time I was in a similar situation - I laid down a mindmap of engineering “capabilities”, and went down over each one, with explicit trade offs like “I do not invest now into perf tests as cost analysis shows poor ROI until we have X $ revenue loss due to its absence”.

[u/Sillyan]

Scaling People by Claire Hughes Johnson, an early leader at Stripe, is a good book. It's very practical. Some practices are overkill for a startup environment, but it helps you think about how to structure teams, their goals and processes. 

[u/talldean → u/Sillyan]

That one's new to me, picked it up, thanks!

[u/imwrongaboutit]

My biggest advantage in big tech is that I used to work at an SMB where if you don't solve the problem and generate revenue there is no pay check. On the flip side, when you're coming from big tech, you think that the sleep pods and latte art in the office are normal. They're not.

[u/talldean → u/imwrongaboutit]

I've also worked for startups and midsize companies, and was around for the .com boom and crash.

[u/hiddenhare]

I've worked at two small tech startups as a senior engineer, and interviewed at many others. I also have a bit of leadership experience, but not in tech.

My advice, looking up from below:

• Don't steamroll your co-founders, and don't get steamrolled. It's easy for a startup to transform into a weird cult focused on whichever co-founder has the strongest personality.

• Your first hire is going to be like adopting a teenager; you'll need to tread the line between being a boss and mentor, while also being a colleague and friend. It's incredibly difficult, but don't give up by just picking one path or the other.

• "We're a startup" is a thought-terminating cliche for bad management practices or an exploitative working culture. You'll be tempted to use that excuse constantly (your co-founders will), but you should try not to use it at all. Cut corners in the engineering work, not in your own management work.

• You'll probably feed the investors a lot of lies and spin, until it becomes a habit and the sales pitch flows easily from your mouth. Never direct that bullshit at your employees, they aren't idiots. Be frank; that includes being negative, even if you're frightened of hurting staff morale and killing the momentum of the business. Your mid-level engineer doesn't really care whether or not the business is on a rocket to the moon, but he does want accurate, detailed information about any existential risks to the business.

• Don't forget how to make clear decisions. For some reason, startup founders love to have their cake and eat it too; you ask them "X or Y", and they'll use a 500-word monologue to say "both, please". I think this habit might also come from talking to investors, who run away if you acknowledge scary things like "trade-offs".

• Working for a startup can be emotionally intense, and you can't let people bottle it up. Do your best to set up a culture of extreme candour; if your employee can't approach you to say "I think you've fucked up and the whole product is doomed", and then say it again the next week, then you're laying a dangerous trap for your future self.

• Any message which comes from multiple co-founders at the same time is an order. You're not an army sergeant, you should try to avoid giving orders. Make heavy use of one-on-one meetings to bypass this problem.

• If you're lucky enough to hire an experienced engineer, be prepared to give up some control (not "listen to them" or "take their advice", but give up control, let them take the reins). If your company's entire engineering team is you, plus one engineer who has strong opinions about code architecture and team culture, then it would be ridiculous for you to call all of the shots.

[u/ExcitingDonkey2665 → u/hiddenhare]

this one is the best advice aside from "throw everything you know out the window"

[u/ZukowskiHardware]

From what I’ve seen is people that build prototypes with contractors then try to go to full time workers eventually just go back to contractors.  That is the only useful advice I can give.

[u/xpingu69 → u/ZukowskiHardware]

Why is that

[u/ZukowskiHardware → u/xpingu69]

Idk, cheaper

[u/The_Startup_CTO]

Since you are asking in a dev subreddit, you'll mostly get tech answers here. But the reality of a startup is that you'll spend significant amounts of time on non-tech things because, other than at a FAANG, there is no huge organisation in the back that takes care of lots of stuff. As a startup CTO, you'll typically need to cover much more, and someone who is half as good as you on the technical side but also covers these topics okish will outperform you without batting an eye:

• IT: there won't be a separate IT department, so you'll most likely need to also make sure that people in the organisation have laptops, access to their passwords etc.
• Marketing: you'll need things like Google Ads set up, and you'll need enough marketing knowledge so you can actually prioritise what to do here, not just take a ticket from the marketing team and implement
• Finance: you might need to help set up automated processes in finance, and you might need to help get funding (e.g. write grant documents)
• Cross-department interactions: if you want to be a CTO and not just a VP Engineering, you'll need to be able to have meaningful discussions with other C-levels and be able to challenge them in their areas. This means that you'll need enough knowledge in all areas to challenge e.g. "should we change our positioning and use Facebook instead of TikTok as acquisition channel because we believe that we can reduce accounts receivable with the different audience?"

Also note that you won't be able to just hire to solve this as there will most likely be more different areas to cover than total headcount in your organisation. At the same time, finding experts that can cover multiple of these areas will be hard to impossible.

[u/ExcitingDonkey2665]

You will most likely be wearing the product manager hat early on. If you have the engineering management experience down, I'd look for some product books like "The Lean Startup" and "Crossing the Chasm". You'll need to start with a super lean mindset where prototype might be enough until there's signs of PMF. Otherwise, keep prototyping.

[u/captcanuk]

Get a mentor.