Ask HN: What are good books/blogs to read for a first time CTO?

https://www.amazon.com/Peopleware-Productive-Projects-Teams-...

It's a classic, and also a pretty easy read. If you're in technology and haven't read it yet, you should.

Your peers are not other engineers and engineering managers like you would be in most situations, but marketers, product people, designers, PMs and so on. Who is the founder and ultimate authority (CEO) and if you are a co-founder or not also really changes things. A founder CTO is also very different from a non-founder CTO. Co-founder conflicts is a huge thing to manage, (see https://flocrivello.com/co-founding-considered-harmful/ ) because at a small size even as a non founder, you're pretty close to it. You should decide upfront if you're going to approach the job as another effective founder or employee and communicate that to founder at the start as part of a conversation.

I made the transition from staff eng to eng manager to CTO at a small startup, and each one is still a very different job even though the skill sets transfer greatly. I code way more at the startup than I did as an eng manager too. Several things I would suggest:

1. You're an exec, even if your company is tiny, and how it works is different than being a manager. Concepts like the 'first team' https://www.michaelvizdos.com/resources/first-team and 'getting on the balcony' matter way more than when you're in a purely product & eng organization: https://www.bettermanager.co/post/move-away-from-the-dance-f...

2. Don't be shy about getting exec coaching, and having the company pay for it. We did that and it was very helpful.

3. Read Radical Candor (updated edition!!!), but also read it with a bit of a grain of salt, realizing the title and advice was chosen because the writer wanted to balance their general high agreeableness with a counterweight that goes too far for the typical person IMO, which the writer writes about that exact dynamic in the second edition.

2a. Learning to be properly direct is super essential, especially at small sizes where its more make or break based on how emotionally deluded you are. The people you are working with need be able to handle you being real with them too. If they cannot, move on, it's that important.

4. Expand your skill set, do everything technical. If you're a backend engineering manager, expand your stack to all parts of the business. That means the back end, the front end, data, analytics, observability, devops, AI models, performance tracing, etc. I started as a mobile eng with previous backend experience, and I wish I expanded sooner so the company had those things on lock sooner, especially in the data analytics side. Engineers hate analytics, embrace it fast to counteract that tendency.

5. Gergely, Will Larson, etc are good resources, but also note they come from what I call the "Uber strain", and thus structure a lot of their experience and advice based on formative years working at Uber. I also worked at Uber when they were there and I recognize a bunch of Uber-isms in their writing.

A good chunk of what they talk about is how to be successful at a place like Uber. Something I've realized later with them is that other companies can be pretty different, and what they espouse sometimes might not match. But on the other hand, Uber's work culture came from previous strains of silicon valley tech culture, especially google's due to the top engineers being from google and setting up their promo system to match googles (vs lets say apple) and the knock on effects of that. Something about that place made people get really good at understanding what is needed to succeed in tech leadership and write about it, I guess it's kind of a paypal mafia effect.

I have the software written, and it appears to run as intended. Now, doing computer systems management, silly stuff; main problem, getting past bad documentation, e.g., was just up all night working with video adapters, device drivers, display resolution, font scaling, HDMI, display port, flickering cursors, etc. Since the documentation was so bad, I did take some notes on the more important things I learned, e.g., by the TIFO (try it and find out) Method. The results are not perfect but are good enough for now. I can delay more until the business is growing nicely (if it ever does). That is, for now concentrate on giving people "something they want" and put video issues way down on the TODO list.

But a concern: If such silly technical stuff does go well, then I could be going live on the Internet fairly soon. Then some of the issues might be:

(1) publicity and getting the first users

(2) getting advertisers

(3) billing and accounting

So, from this thread and a few hours at Google this week, I just concluded: For nearly all that stuff, nearly every business has to do it. So, there are well polished options for how to do it, and I can put it low on the TODO list for now.

For what to do if the business starts to grow, I saw some of that at FedEx and elsewhere. Right, as in this thread, focus on providing "what people want", the work, and the revenue. E.g., if I get a lot of users, then that should help getting some advertisers. Then will need billing and accounting, and, uh, there is no shortage of people who can provide such services for me -- getting the revenue is the hard part; given the revenue, it stands to be easy to work with an accounting service! Or, for a lot "I don't know how to do it, but there are plenty of people who do."

In particular, for management and in particular engineering management, I've seen, been in, and done some of it and conclude now that my business will be nicely successful before I will have to look into the theories of it. In particular, I saw several cases of guys really eager to work hard, occasionally all night, get good stuff done, with no credit from any management.

For the core technical stuff, my efforts have some of that, and it should be a business advantage, uses some of my experience and Ph.D. in applied math, I would say beats AI, and easy for me -- early on in the effort I wrote up the math in Knuth's math word processing TeX. Then used the write up when I wrote the code (Windows, IIS, .NET, ASP.NET, ADO.NET, platform invoke, etc.). So, the core technical stuff is done, not even on the TODO list! On with the rest with the balances as often in this thread.