I haven't heard the term ScalepUp CTO. There's a company named ScaleUp, but I'm assuming you're not their new CTO ;p but a CTO promoted during the "scale up" phase of a startup. I'm a lead engineer but was responsible for scaling a service to 500M monthly users. So sample size=1. And my suggestions will be from the "T" part of CTO and nit really the "C" part.<p>Firstly, I think youtube is a great primary resource here that you shouldn't neglect. There's a lot of conference talks by companies that scaled very quickly which go into great technical detail.<p>Also blog posts, there's a lot of great blog posts from the scale up phase of companies that don't hide anything.<p>The reason these fairly transparent conference sessions and blog posts exist is because the company is trying to interest top-level applicants and to look good for a future sale (I know because I experienced these requests) but it's great for just learning from.<p>For actual books, my suggestions will be very related to the system I had to scale. So my main suggestion is to first find some means to learn the optimal ways for your own system to scale before you go deep into any specifics.<p>"Designing Data Intensive Applications" by Martin Kleppmann is as the title describes. If "data" storage or manipulation is central to your systems (and what modern app isn't), I'd say it's essential to at least skim through. It's more of a breadth than depth book, but it goes deeper than you'd expect.<p>"Big Data" by Nathan Marz was foundational to the system I ended up designing, usefulness may vary. It describes a specific architecture for a flexible and high throughput data-based application. He has a new framework(?) named Rama that's open source, has some good blogs, and was recently featured on HN. And it appears to be based on improvements to the ideas in Big Data. So that's free and may be a better first look, though the available details aren't as in depth as the Big Data book.<p>"Event Streams in Action" by Alexander Dean & Valentin Crettaz is another one that may be specific to the area I needed. But if that's what you need, it has what you need.<p>"The Data Warehouse Toolkit" is another somewhat specific usecase book. It's also more developer-level than CTO level in a lot of areas. But it includes good, very specific examples such as several chapters dedicated to case studies of specific industries like banking, accounting, ecommerce, healthcare.<p>"Working Effectively with Legacy Code" By Michael Feathers is a personal favorite. Maybe a bit opinionated. You might think "We have older/early startup code, but we don't have legacy code", but Michael introduces a unique (and IMO very effective) idea of 'Legacy Code', anything that doesn't have tests is legacy code. It's a great resource on refactoring/maintaining/modifying and even rewriting important code without comprehensive coverage, and not written to make test coverage simple. The way I now look at it, any services written before the "scaleup" phase are almost always legacy code.<p>"Scrum: The Art of Doing Twice the Work in Half the Time" By Jeff Sutherland. If you're doing Scrum abd haven't read the original, I'd give it an extreme recommendation. The most important part of Scrum (in my opinion) is the flexibility and self-modification. The team I lead chose to trial Scrum and it was fantastic. The whole company decided to implement it. When the CEO learned we had abandoned literal "standups" for daily slack threads he made us revert to standups. The whole company had to follow the initial template laid out by Scrum with no deviation. It failed horribly and everyone hated it, it became the dreaded "waterfall with sprints". The main issue is he didn't listen to us about how it's meant to be modified, but I also think a big issue is he ordered 50 copies of some 30-page cliff-notes version of Scrum for the whole office, which completely omits the "kaizen" and other details about how malleable it can be.<p>"Don't Make Me Think" by Steve Krugg. Not so much about scaling but about user testing. So maybe not technically CTO territory but please advocate for this :P I'm paraphrasing some phrase in the book but 2 hours of proper user testing from random people off Craigslist/etc will provide you with 2 months of dev-work. You will not believe the features users misunderstand or various opportunities for additional sales users completely miss until you try with real people off the street.<p>"High Output Management" by Andrew Grove is about where management can be effective or harmful in developer productivity. It's an older book, sir, but it checks out. Some of it is fairly commonplace information nowadays, but still a good intro to tech management, and probably some useful information for very high-level management since Grove was the Director of Engineering at Intel when he wrote it.