Depends a lot on your situation:
Does "CTO" mean you are the tech lead of a small (single team) engineering organization? Then everything written for staff engineers applies. E.g I've heard good things about "Staff engineer's path" by Tanya Reilly.
Does "CTO" mean you are leading an org that is too large to be hands-on with tech, and need to build an effective structure and culture? Then I second the recommendation for "an elegant puzzle" by Will Larson.
Or does "CTO" mean that you switched from being an engineer to managing a team of engineers? Then everything for new managers applies, for starters I'd recommend "Becoming an effective software engineering manager" by James Stanier, or "Engineering management for the rest of us" by Sarah Drasner.
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, and if you want to create your own they are excellent starting points.
And maybe CTO means “the founding programmer of a new startup” in which case my advice would be to stop reading and start coding :-)
There's always time to read, you can't only code. E.g. I run a lot so I get through a hell of a lot of audio books.
I don't think the parent comment means only code, never learn. I think their intention was to not worry too much about the "CTO" title and instead focus on building the product at hand.
Yep. When building a startup you’ll find a lot of well-meaning people (in books or in person) who really do nothing but distract you. YC got it right, you should make something people want. Everything that’s not either making something or finding out what people want is just going to slow you down.
Too reductionist.
You must "sharpen the saw".
This takes many forms including adequate learning / training for self improvement as well as investment in your tooling that will pay dividends on delivering faster or with higher throughput.
These are second and third system effects that require intention to monitor or measure but the effect is real.
I'd say the time for sharpening the saw was before you started the company. The next opportunity to invest into best practices / long-term is when the company actually has some traction.
The entire point of sharpening the saw is that it is continual though. It doesn't have to be a major investment or long-term, in fact it explicitly references "Daily Self-Renewal". I believe the original comment branch just meant don't worry about "what's applicable to the CTO".
Sure. But the point was that if you're a team of 1 engineer, even if your title is CTO, time spent learning "how to be a CTO" when you don't have any team whatsoever is time not spent building the prototype that needs to demonstrate $XX value/growth by YYYY-MM-DD in order to survive.
Learning is always encouraged, but you should be learning to solve the problems you're about to face. Learning to solve problems which aren't going to be obstacles in the near or mid future isn't helping you in your immediate circumstances. Sometimes the immediate circumstances aren't much of a concern, but when they are, you need to be sure you're learning with that in mind.
Of course nothing is black and white, but if you have limited time/money then you want to get to ramen profitability fast and you simply don’t have time for business model canvases, the perfect employee option scheme, a scalable k8s setup or a perfect CI/CD pipeline.
There’s so much stuff that feels important and valuable, but so little of it really cannot wait until after your wheels are off the ground.
When you read postmortems of startups that didn't get enough customers, often it’s this stuff that actually went wrong. Too much time spent on other stuff than “build something” and “that people want”.
To my experience, it’s difficult to resist all that good advice that’s all over the internet, books, accelerator programs and the like, and saving it all for later. People will tell you “you should get $PETPEEVE right from the start” for every imaginable pet peeve (all the way from legal stuff to unit tests to SEO) and they’ll be very convincing. Trying to resist this is not reductionist, it’s super hard.
And honestly, pre product-market fit my advice would be not even coding, but iterating in an extremely scrappy way (read: Google Sheets, Jupyter Notebooks, no-/low code, handwritten invoices) until you have people paying for your product and not churning after the first month. Everything else comes secondary. For every company that didn‘t manage to scale their tech and teams fast enough, there‘s 100 that die by „building and they will come“ a polished app with great UX through 4 ecosystems that get launched to deafening silence.
Tbf I believe this depends a lot on the product category. Uber could do this in their first few months but eg Retool couldn’t.
Obviously some ideas can’t be tested without writing some code, but it’s more of a mindset than a strict playbook–many programmers (myself included) tend to bias towards wanting to write code and avoid sales conversations until the thing feels “done”. Tech message boards are littered with programmers trying to justify why their app has to have a full polished build that will take a year before they can begin selling it.
When you get in the habit of asking yourself, before building, how you can learn the most about what people want with the least amount of code, clever ideas often come to mind.
this is perfect advice which i can't agree with enough. that is unless the founders insist on a flawless UI... then you are in for a world of pain
never understood why teams of literally 1 or 2 devs are always forced to try attempt to acheive the visual quality of apps like instagram, whatsapp, etc
For the same reason those kinds of places have more managers than workers… it’s a vanity project.
:-)
Haha, for sure. I wrote about that contrast here a few years ago: https://www.mooreds.com/wordpress/archives/2555
That's a very good point. A "CTO" can mean any mix of managerial, leadership and technical responsibilities.
It is my assumption that a CTO is usually coming with technical background already except when he/she is a cofounder and they got technical domain as a result of division of responsibilities. But I am suspicious of startups where none of the cofounders come from technical background.
That leaves managerial and leadership. IMO, if you are a CTO, managerial is something you can hire other people to do for you as your technical organisation grows and leadership is something you should really be focusing on.
You can have flourishing technical organisations with the CTO being a poor manager but a good leader but very unlikely with a CTO with good management but poor leadership skills.
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.