101–110 of 148 posts
Earlier quoted context omitted.
How/where did you find former CTOs to talk to?
The slack community in https://randsinrepose.com/welcome-to-rands-leadership-slack/ has a pretty good number of CTOs and other leaders.
I've been a CTO a couple of times (VMware, startup), I don't think I'm a good one (I am better as an individual contributor, rather than as a manager), but I have one piece of advice for you: ignore books, or use them as secondary source of truth. You should instead TALK to long-time or former CTOs and ask them for advice. You won't find that advice in any book. It's invaluable.
How/where did you find former CTOs to talk to?
7 CTOs is another one that I have heard of but haven't participated in.
I think the #1 thing when you become part of an exec team is that you should be optimizing for the _business_, and not your function. The working assumption is that you will keep your function executing and delivering, but what is really hard is helping to figure out what the right decisions are for the business. Should we invest more in product or sales? What if there’s a huge top of funnel problem — what can we do…
You should do this even if it leads to layoffs for your department, because, again, your goal should be a thriving business, not a thriving engineering department and a lackluster business.
Source: I did recommend and lead this course of action once (the outsourcing, not the layoffs). Company is still using an outsourced solution.
Earlier quoted context omitted.
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.
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.
https://github.com/kuchin/awesome-cto
Some hit-and-miss there but I discovered a lot of great advice.
An Elegant Puzzle: Systems of Eng Management (https://lethain.com/elegant-puzzle)
and
The Art of Leadership, small things done well (https://www.amazon.com/Art-Leadership-Small-Things-Done/dp/1...)
There are a lot more that were helpful to me, but those two encompass most of the important concepts and skills already in a usefully synthesized way, at least for me.
Earlier quoted context omitted.
not always a him
When does Simone become something else?
https://en.wikipedia.org/wiki/Simone_(given_name)#Simone - Pick any of the Italians off the list and they're almost certainly men, most of the non-Italian Simone's are women.
Of course, it's still safer to look them up if you don't actually know the person in question and want to use he or she.
If you’re building, I’ll echo other commenters…stop reading and go code.
For just about any advice I’d say go read Rework, in between coding sessions.
CTO skills needed for a 10-person company is radically different than a 10,000-person company.