
Ask HN: Books and Courses for Wannabe CTOs and Heads of Engineering? - iforgotmypass
How did you become the CTO or Head of Engineering at a larger organization? What books and courses did shape your growth and prepare you for this role and&#x2F;or solidify your knowledge as a CTO &#x2F; Head of Engineering?<p>---<p>I&#x27;ve got a background as a software developer and development team lead. I&#x27;ve filled shoes as an architect, infrastructure expert and an IT project manager. I&#x27;ve got a solid understanding of the business side as well.<p>What books, courses and other &quot;theoretical background&quot; you would recommend to make the jump &#x2F; transition from a development team lead to a Head of Engineering or CTO at a company with 100-250 employees?<p>This is not a question about career progression as it is more about &quot;growing with the company&quot; (so gaining all the required knowledge in advance before actually gaining that know-how in practice - for example, when you are a &quot;CTO&quot; of small yet fast-growing startup).<p>The recommended literature should contain info on:<p>* scaling the software development team (e.g. if I&#x27;ve lead a team of 8, how do &quot;I&quot; &quot;handle a &quot;team&quot;&quot; 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?)<p>* defining and measuring KPIs and&#x2F;or OKRs for technical people in all the levels<p>* 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<p>* talking to the management (reports, bridging the understanding between the business and the IT)<p>* everything else I haven&#x27;t thought about<p>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 &quot;whatever works&quot; and &quot;let&#x27;s just do it the start-up way&quot;.
======
thiago_fm
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.

------
macando
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...](https://www.amazon.com/Becoming-Technical-Leader-Problem-Solving-
Approach/dp/0932633021)

"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."

------
davismwfl
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.

