Ask HN: Books and Courses for Wannabe CTOs and Heads of Engineering?
3 comments
1. you don't handle a team of 50-70, you hire good team leads and handle only the team leads, trusting them to do their job and try to get what they want from top management done
2. there are a lot of books on that subject, but the most important thing imho is that you and your company about the KPIs they chose. It's an art like painting. If you do the colors and forms the way others do, it is very unlikely that you will beat competition, and if there would be a book that would tell you, everybody could become Picasso. I think this is the main challenge of being a C-level, all the rest is well documented.
3. Same as 2. I see you are addicted to perfect methods which even in team lead positions doesn't apply/exists. It isn't coding. If anybody knew the right way, they could just do it infinitely and create infinite useful companies/products.
4. I'd get a good communication course and practice often in different situations, you need to become very good in "powerpoint karaoke" and it's mostly a selling skill.
5. There is an infinite amount of information in that subject, you need to figure out what the combination of (you+company) needs and focus only on that.
My 2 cents: You should focus on creating a good environment for the people that work with you, so that they can just have a lot of autonomy and are empowered, feeling responsible for the future of the company. All your worries above are partially useless, things such as KPIs isn't so much a thing that a CTO should control/care. Instead create an environment that people would come up with ideas of what to do and you just enable them.
2. there are a lot of books on that subject, but the most important thing imho is that you and your company about the KPIs they chose. It's an art like painting. If you do the colors and forms the way others do, it is very unlikely that you will beat competition, and if there would be a book that would tell you, everybody could become Picasso. I think this is the main challenge of being a C-level, all the rest is well documented.
3. Same as 2. I see you are addicted to perfect methods which even in team lead positions doesn't apply/exists. It isn't coding. If anybody knew the right way, they could just do it infinitely and create infinite useful companies/products.
4. I'd get a good communication course and practice often in different situations, you need to become very good in "powerpoint karaoke" and it's mostly a selling skill.
5. There is an infinite amount of information in that subject, you need to figure out what the combination of (you+company) needs and focus only on that.
My 2 cents: You should focus on creating a good environment for the people that work with you, so that they can just have a lot of autonomy and are empowered, feeling responsible for the future of the company. All your worries above are partially useless, things such as KPIs isn't so much a thing that a CTO should control/care. Instead create an environment that people would come up with ideas of what to do and you just enable them.
A lot of eye-opening insights in: Becoming a Technical Leader: An Organic Problem-Solving Approach
https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
"It identifies which leadership skills are most effective in a technical environment and why technical people have characteristic trouble in making the transition to a leadership role. For anyone who is a leader, hopes to be one, or would like to avoid being one."
https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
"It identifies which leadership skills are most effective in a technical environment and why technical people have characteristic trouble in making the transition to a leadership role. For anyone who is a leader, hopes to be one, or would like to avoid being one."
I am a CTO today (albeit for a small startup right now), but I have run teams of 120+ people and I have run my own successful businesses. So my advice comes from that knowledge and experience growing an engineering team from 6 to 120+ in a year.
Books are interesting to read and can give you ideas, but in the end it is leadership that solves the problems and makes teams successful, not which OKRs you put in place. In fact, OKR's can be the death of a team if they are done incorrectly, and just cause Google uses them doesn't make them good. Six Sigma was invented at Motorola who used it mainly properly, GE started with it in a good way then twisted it so badly that it became a problem not a solution. Sadly that trend went around multiple industries, much like OKR's today. That's just an example though. OKR's and six sigma can be used properly to great success, but be careful with trends when you are a leader.
To the things you asked about specifically, there is no book or set of books I know of that will answer it all. Most of being a good CTO isn't about the technical part of the job or engineering specifically, it is about people. So if you are not a good people person that is the place to start. Read about people, read psychology books, read sociology books, understand how group think works and how to avoid it etc. Make sure your life is in order so you are not running around like a chicken without its head, because how you work is how your team will work. So if you are a negative person you'll surround yourself with negative people, either because you hire them that way or you'll make them negative through your own behavior. Negativity is bad, fairly blunt honesty with positive reinforcement is good.
Growing a team from 0-8 vs from 10-30 isn't much more difficult, the rules stay the same but you have to setup more structure. The biggest mistake new CTO's and Founders make is they don't put in organizational structure, thinking a flat organization is ideal, and truly flat. Flat organizations are great, but it does NOT mean you lack structure, please read on this if you don't understand it. People need to know who to go to when, how to resolve an HR problem vs an engineering issue etc. 90% of the time I see growing teams in trouble it is from a lack of organizational structure and process. And process doesn't mean some heavy weight manual on how to do a job, just where to go for what and when and who to ask what types of questions for quick resolution.
I could go on and on about each of the issues. What you need is a good mentor to help you and to give you advice. My 2 cents, if you want to grow with the organization into a technical leader understand that you need to be a people person and your technical ability is second. IMO you should never lose your technical knowledge and I feel CTO's should always remain highly technical ( at least in knowledge ), but your primary job goes from technology to leadership, so if you are touching code in a company that size as CTO you have failed big time. If you want to touch code, move to the principle or staff engineer type position and not a CTO/VP etc.
As for books:
Crossing the chasm (get the latest edition) -- good for technical product introductions and marketing behavior. CTO's/VP's etc need to know marketing and business methodologies well to be successful.
The Essential Drucker -- not saying I agree with everything, but at least it helps you understand a lot of concepts and you can see patterns.
Chainsaw by John A Byrne -- This book is about Al Dunlap and Sunbeam and corporate greed. I think all new founders, managers and business people should read it. It isn't a guide to being good but showing how you can destroy a company quickly. So worth the read, and interesting characters.
Also read all kinds of management books and military leadership books for special forces etc. It gives you good information on how to create high performance loyal teams.
Books are interesting to read and can give you ideas, but in the end it is leadership that solves the problems and makes teams successful, not which OKRs you put in place. In fact, OKR's can be the death of a team if they are done incorrectly, and just cause Google uses them doesn't make them good. Six Sigma was invented at Motorola who used it mainly properly, GE started with it in a good way then twisted it so badly that it became a problem not a solution. Sadly that trend went around multiple industries, much like OKR's today. That's just an example though. OKR's and six sigma can be used properly to great success, but be careful with trends when you are a leader.
To the things you asked about specifically, there is no book or set of books I know of that will answer it all. Most of being a good CTO isn't about the technical part of the job or engineering specifically, it is about people. So if you are not a good people person that is the place to start. Read about people, read psychology books, read sociology books, understand how group think works and how to avoid it etc. Make sure your life is in order so you are not running around like a chicken without its head, because how you work is how your team will work. So if you are a negative person you'll surround yourself with negative people, either because you hire them that way or you'll make them negative through your own behavior. Negativity is bad, fairly blunt honesty with positive reinforcement is good.
Growing a team from 0-8 vs from 10-30 isn't much more difficult, the rules stay the same but you have to setup more structure. The biggest mistake new CTO's and Founders make is they don't put in organizational structure, thinking a flat organization is ideal, and truly flat. Flat organizations are great, but it does NOT mean you lack structure, please read on this if you don't understand it. People need to know who to go to when, how to resolve an HR problem vs an engineering issue etc. 90% of the time I see growing teams in trouble it is from a lack of organizational structure and process. And process doesn't mean some heavy weight manual on how to do a job, just where to go for what and when and who to ask what types of questions for quick resolution.
I could go on and on about each of the issues. What you need is a good mentor to help you and to give you advice. My 2 cents, if you want to grow with the organization into a technical leader understand that you need to be a people person and your technical ability is second. IMO you should never lose your technical knowledge and I feel CTO's should always remain highly technical ( at least in knowledge ), but your primary job goes from technology to leadership, so if you are touching code in a company that size as CTO you have failed big time. If you want to touch code, move to the principle or staff engineer type position and not a CTO/VP etc.
As for books:
Crossing the chasm (get the latest edition) -- good for technical product introductions and marketing behavior. CTO's/VP's etc need to know marketing and business methodologies well to be successful.
The Essential Drucker -- not saying I agree with everything, but at least it helps you understand a lot of concepts and you can see patterns.
Chainsaw by John A Byrne -- This book is about Al Dunlap and Sunbeam and corporate greed. I think all new founders, managers and business people should read it. It isn't a guide to being good but showing how you can destroy a company quickly. So worth the read, and interesting characters.
Also read all kinds of management books and military leadership books for special forces etc. It gives you good information on how to create high performance loyal teams.
---
I've got a background as a software developer and development team lead. I've filled shoes as an architect, infrastructure expert and an IT project manager. I've got a solid understanding of the business side as well.
What books, courses and other "theoretical background" you would recommend to make the jump / transition from a development team lead to a Head of Engineering or CTO at a company with 100-250 employees?
This is not a question about career progression as it is more about "growing with the company" (so gaining all the required knowledge in advance before actually gaining that know-how in practice - for example, when you are a "CTO" of small yet fast-growing startup).
The recommended literature should contain info on:
* scaling the software development team (e.g. if I've lead a team of 8, how do "I" "handle a "team"" of 50-70 engineers? What are the common pitfalls to scaling the engineering team? Some common examples for the organizational structure for handling multiple software development teams?)
* defining and measuring KPIs and/or OKRs for technical people in all the levels
* project management techniques and tools to gather all the data (and what data and how should I gather?) to be able to make any decisions
* talking to the management (reports, bridging the understanding between the business and the IT)
* everything else I haven't thought about
I am looking more for a know-how that could be applied to existing enterprise as well. So more of an enterprise-way how-to than "whatever works" and "let's just do it the start-up way".