> For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them
One word of caution: Engineers and EMs read these newsletters and even management books, too.
It’s not hard to see when your leadership is just parroting things they read from a book or newsletter and trying to pass it off as if they had deep leadership experience. Engineers are good at seeing through cargo cult leadership.
I suggest that if you embrace a practice found in a book or a newsletter, be transparent about the source. Encourage people to read more about it in the book or newsletter where you found it. Don’t try to pass it off as a management technique you invented or pulled from deep background experience, because it feels disappointing to the team when someone realizes their CTO is just parroting things from a newsletter or blog and trying to hide the source.
Also, don’t get into the mindset that having read a lot of books or blogs or podcasts or newsletters is a substitute for experience. Some of the worst leaders I’ve had were those who would lord their book knowledge over everyone as though it made them the confident expert on everything, while we could all clearly see that the extents of their knowledge started and stopped with what was contained in the books they read. Books contribute bits and pieces and give suggestions to add to your corpus of knowledge, but if you treat them like definitive, all-encompassing sources of wisdom then it’s going to be clear to people that you don’t really know what you’re doing. Be honest and stay humble.