Thank you for taking the time to make this. I was delighted to see some of your top choices, Jerry Weinberg and Eli Goldratt for example, and will be sharing this with several team mates who are working toward leadership.
I like that it's short and somewhat curated, try to make it stay that way. Most awesome lists grow to be link dumps. For instance the awesome-js is over thousands lines long now, containing all sorts of random crap. It can be nice as a way to know what's out there, but when it contains 40 mvc alternatives in addition to react/angular and other big ones, it's just not useful.
I believe the most important knowing if your list is either or, and ensuring it sticks to that. For awesome-JS it might be the directory path (then make sure that's what users get out of it), but for a list like this I totally agree one should not make it a register of everything out there.
One of the most important skills is learning to communicate clearly.
You need to give up details and be able to express the key concepts clearly on different levels of detail and business/technical understanding.
Explaining this is something you will be doing again and again, so it is worth a lot of effort to get there.
I recommend iterating until you have an A4 with the skeleton you need explain all this. It will include key stakeholders/users/integrations, key technologies/protocols, key services/components and the high-level system landscape with key internal and external systems.
Notice that a good diagram for this mixes a lot of different views and formal notations.
The key idea is that you should strive to provide a skeleton on which your audience can place their understanding and fill in the blanks that they are interested in based on you explanation.
If you try to put everything there or follow a formal model like UML you will drown out the key concepts in the noise of the details.
IIRC he did that to support something that wasn't otherwise possible at the time, having the same code base run in ASP and PHP (i.e. Windows and Linux).
My biggest challenge as a CTO is that, by nature, I'm singular in focus. If I am developing something I find it hard to context switch and review other developers' work. The best strategy I have found so far is to block certain times in the week solely for reviewing everyone's progress.
I think these are both valid approaches for different company sizes. If it's a team of 3-4, you're primarily an IC, who also CTO's. If it's a team of 10-15, it's the opposite.
That is interesting. I'm a CTO, originally a CTO of a startup, now CTO of the much larger acquiring company. It is fascinating to see how different the CTO job can be across industries. I find my time is spent in almost the opposite direction, with the majority of it involving deep technical context switched rapidly.. and that really is the skill that I have need to refine the most - the ability apply high focus quickly. Cool to hear other stories.
The biggest accelerator, at least for me, was having a child. As anyone who has children know, the first few years are a long sequence of tasks interspersed with small breaks. If you want to get anything done, you have to be able to do it in small increments. On the hobby side for instance, I worked at keeping a running note log with my projects so I could walk in and actually make progress on a project when I only had 10 mins free. I carried a notebook with 'thought areas' that needed some thought applied, and if my daughter was sleeping I might crack it open and look at one of the problems and work on it.
The ability to do real, forward progressing complex work in small chunks has made a huge difference in both my personal life and my professional one. I suspect it will also be helpful as I get older, because eventually great memory skills fade!
I second this. Ok, I'm on the Manager schedule now. How do I still make things? Having kids puts you on the Manager schedule (interruptions are to be expected and blocks of time without pre-scheduled interruptions are rare) whether you like it or not.
I'm interested in hearing more about the idea of being an effective CTO while focusing on also being a developer.
I imagine it's necessary for small companies, possible for growing companies, and eventually impossible for sufficiently sized companies where the CTO role is at least 40 hours of your week.
I personally find it to become the case with as little as 5-6 developers under me (assuming they are good and I can trust them to program without needing me to step in and solve their problems of their own making on a regular basis).
Also as someone nearing his late 30s I'm sometimes surprised how good some programmers are as young as late teens/early 20s! These rare talents mostly need me to prevent them from going into rabbit holes but when they are pointing in the right direction can produce amazing results.
I am sure my time is better spent helping a few of these do better than what I'd get from just myself programming directly in the same amount of time (management is a multiplier on the team's productivity and that multiplier can easily get smaller than 1.0).
What about someone growing into the role of CTO? I run a tiny company (single-digit number of workers) & am de-facto the only "boss"/executive so I guess you can say I'm the CEO (I'm also an individual contributor - as I said, tiny).
But I still need to sometimes also do what a CTO would do in a bigger company, and if things go well and the company grows I may need to incrementally learn more and more of the themes above (up to the point where I hire a CTO to replace me in that role I guess).
While that's true, these articles don't teach you that much as a CTO. The most leveraged way to learn how to CTO is to work for a good one and keep the curiosity level high. The next way after that is to cultivate good relationships with CTOs you look up to and develop a mentor-mentee relationship. The next most leveraged way to learn how to CTO is to just do it.
Ultimately, reading the material on these lists is a very small fraction of the job. Personally, I've already read most of the items on the last list years ago when I was earlier in my career and wanted to understand different historical organizational models. That's the right time to read this kind of stuff, because you can use it to pattern match and dig into what others around you are doing in an environment where you are not on the hook for their strategic mistakes.
By the time you're actually doing it, this material will probably not be that much help. You'll be in the driver's seat, not the passenger's seat. You'll need to use driver's seat tools, not passenger's seat tools.
This is my personal opinion, so don't take it too hard. But your post triggers my BS alert.
First of all, how many CTO's do you know? And how many of them are good?
Second, is this "mentor-mentee" thing real, or just something business coaches and get-rich-quick gurus claim? Never seen it in the real world.
I'm an old timer. Most of my experience comes from experience. Most of my intellect comes from books an articles written by people who know what they are talking about. Claiming that the latter is a waste of time seems very wrong advice to me.
> Second, is this "mentor-mentee" thing real, or just something business coaches and get-rich-quick gurus claim? Never seen it in the real world.
Have you ever learned from one of your more senior coworkers or peers? Worked alongside someone who showed you the ropes or helped you level up your skills? Then you've been a mentee.
Have you ever taken time to guide new hires or junior coworkers in something you're familiar with? Provided advice to accelerate someone's learning? Then you've been a mentor.
Mentor/mentee usually isn't an explicit declaration. It's a very valuable way to accelerate skills, though not the only way.
Sure I had those, but it's more explicit when you are one of the many programmers taking advice from a senior programmer.
In the case of a CTO, since it's a unque role, you have to go outside of your company to get mentored. And that doesn't seem so straight forward to me. Because asking a colleague about a problem you are facing is way easier than calling someone and talking about your problem at your work.
Maybe I'm ignorant about this topic, and maybe such things are more normal in US than here in EU. Such things go really against my nature, but I aslo never seen such relationship outside of the same company.
> Maybe I'm ignorant about this topic, and maybe such things are more normal in US than here in EU.
If you're ignorant about the topic, why not explore the other perspective with curiosity rather than gruffly dismissing it as provoking a BS sensor? Mentorship is an enormous part of the lifecycle of executive tenure of the ecosystem I participate in, which is the NYC startup ecosystem.
I've observed that when my colleagues have built a deep relationship with their manager during their tenure, often times, they gain that mentorship permanently whether they stay at the company or not. The reason the mentor does it is because it's just another version of the old adage of paying it forward -- they know that a job they land in the future could come from one of their old reports; in fact, they might even end up working for one of their old reports!
Investing time and energy into cultivating and keeping these relationships going is a large part of how my colleagues have continued to keep their career moving upward as they approach mid-career.
> I'm an old timer. Most of my experience comes from experience. Most of my intellect comes from books an articles written by people who know what they are talking about. Claiming that the latter is a waste of time seems very wrong advice to me.
I wonder if you're making my point for me. As an old-timer, what you bring to the table that's more valuable than gold is hard fought experience -- not the things you've read. It's easy to read things, but to actually apply them and be responsible for their long-term consequences is rather different.
To answer your other question, I know quite a few CTOs. In particular, there are two that I know very well because I worked for them on the ground-floor building $1B+ startups at the seed-series A stage. So much of what I know came from observing what they did, asking for help, asking them to explain how they came to certain conclusions or made certain major decisions. I wanted to take apart how they did things even if I wasn't responsible for them, so I could put it back together and understand how it works. Not only that, but I kept in touch with them afterwards and found them very valuable sounding boards for when I gave my first CTO gig a shot.
It's true that experience is harder to get than knowledge from reading. But I still think reading offers a huge amount of benefit that you cannot get from experience.
One thing is that it opens up a world that is broader to your own. Another thing is that it can provide clear mental models that you probably won't figure out yourself, and that you can observe only after you know the theory.
Let me give you a clear example.
Early in my career I had to manage a junior. At the time I was reading The 7 Habits Of Highly Effective People. I applied the "stewardship delegation" from that book to the letter. It worked perfect. In my 19 year career, I apply it all the time, with great success (it also works on your kids :D).
But nobody I know knows about it. I could have never learned one of the most important things, from experience alone.
Even when you look at people like Bill Gates for example, they also still seem to get great value out of reading.
Thanks for the conversation, and sorry for my snarky remark, I admit I was wrong judging you :)
I have a pretty good relationship with my boss (not a CTO, but a member of the executive leadership at my company). I definitely do consider her a mentor to me, and I am certain that she considers me a mentee. Over the last few years she has explicitly gone out of her way to help me improve my leadership skills. Not saying that this is kind of relationship is common or not, but it does exist.
I do agree with the overall content of your post, though.
> Perhaps we should add “Don’t say things like ‘The most leveraged way to learn how to CTO’.” to the list.
Please leave the unnecessary snarkiness for other forums. I could have said "The most leveraged way to operate as a technology executive" but that's rather wordy. More than happy to engage with any substantive critiques you have with my point of view. It's what has worked for me, and it's based on my own experience.
If you think that’s how leaders of companies should talk and that people who criticize you for talking like that should be written off as pedants then good luck to you.
I don't think I've ever met a CTO who wouldn't benefit from a list like this - or who would deny that it would be useful.
The secret to getting good at management is to acknowledge that it is a huge, deep and learnable set of skills. The best managers I know are the ones who constantly seek to improve their skills, and "do the work" to improve.
Makes me think of the two Lex Fridman podcasts with Jim Keller. The second one (last week) got quite fun/loose.
It's clear that Jim is constantly reading/actively improving, sometimes doing kinda unusual things, like having a specific strategy for priming his REM sleep by thinking a lot about some current problem combined with some kind of meditation exercise.
"I don't think I've ever met a CTO who wouldn't benefit from a list like this - or who would deny that it would be useful."
The most valuable thing for me, and I am a CTO, is exactly the reminder of the breadth of the list. Most of the areas of the list are things I am familiar with, but it is easy to let a few areas fall short. One of the key expectations of a CTO is broad expertise, which is a tall ask.
> One of the key expectations of a CTO is broad expertise, which is a tall ask.
Being a generalist + working in many separate areas will get you there. It does take time to build experience. I guess you can accelerate it slightly by reading books, but really, most of the lessons are best learned by doing, I think.
Fixed = your talent is fixed, you will not learn, challenges will either show your talent or reveal you're a fake, helpful sheets and reminders like this are a proof of your lack of talent, therefore never admit that you're don't know anything
It's not a syllabus for a training program, it's a list of resources you might need at different times, as a refresher or supplement for areas where you're weaker than in other areas.
I find CTO title without knowing at least company size ambiguous.
Engineering managers, directors are more constant across companies.
Is there a big difference between engineering manager with a team of 8 working on a product and CTO with the engineering team of 8? I would say no.
I feel that the list will be helpful for those who want to learn more about engineering leadership and soft skills.
BEWARE: There are a lot of investors that will try and take advantage of your skills to build their business with the promise of equity that isn't real or can be changed or diluted on their terms. DONT be fooled into taking more salary over equity.
