
Classic books for tech leads or those aspiring to be - bmgoss
https://sourcelevel.io/blog/3-classic-books-for-tech-leads-or-those-aspiring-to-be
======
mikestew
I don't know if it's a good list for tech leads, wannabe or otherwise, but one
could do worse in choosing three books.

I do take issue with the the _Mythical Man Month_ blurb, though. My copy has
disappeared from my bookshelf again, but IIRC the "adding more people makes it
later" bit was just one of many essays in that book, but it's the only one
people ever mention. But it's the one that allows us all to pretend we read
it. Quick quiz, hot shot: what did you think of the surgery team metaphor?
Another thing few mention about _MMM_ : at least some parts are noticeably
dated. (But without a copy in front of me, I don't recall which parts.) So,
good book that we probably all should _actually_ read instead of just spouting
about nine pregnant women, but not all of it will be relevant today.

~~~
fnord123
Brook's law is also outdated. It's mostly only relevant for when you deliver
your software with a forklift.

Even Steve McConnell of Code Complete and Rapid Development has argued against
it:

[https://stevemcconnell.com/articles/brooks-law-
repealed/](https://stevemcconnell.com/articles/brooks-law-repealed/)

~~~
jqcoffey
> Brook's law is also outdated. It's mostly only relevant for when you deliver
> your software with a forklift.

Hmm... not sure I agree with this. A few points come to mind:

\- Some portions of a project become hotspots at different times and have a
natural code concurrency limit (it may not be 1, but certainly 10 people can't
make changes to the same class or other critical code path concurrently)

\- Onboarding is a real thing. It requires current staff to train newcomers,
at the very least. At worst, they have to account for the newcomer's
coding/architectural misses

\- Communication and consensus building with more folks takes exponentially
more time (or is it combinatorial, I can't keep that straight).

~~~
fnord123
In a SaaS world the value stream is broken up and delivered as appropriate.
What does it mean for a project to be late if there is a value stream
constantly being delivered?

Onboarding is a real thing but Brook's calculations are absurd by today's
standards. 1 Month to onboard someone? We have developers committing code in
their first week. Sometimes day 1 or 2.

Read McConnell's essay. It's v. good.

~~~
bluebknight
At Google, engineers start committing code in their first week too.

That doesn't mean they're fully on-boarded until 6 months in.

------
staysaasy
I've put together a reading list for VPs of Product here, which is pretty
analogous to the tech lead concept but for PMs:

[https://staysaasy.com/product/2020/06/14/a-vp-products-
readi...](https://staysaasy.com/product/2020/06/14/a-vp-products-reading-
list.html)

(edit: we write stuff for engineers too)

------
sosilkj
it seems like "tech lead" is a position with responsibility but no real
authority, a sort-of middle manager. i'm sure the books are good, but the
thing I'd want help with is how to achieve a balance between ensuring the team
is delivering good work (in a technical sense) while making sure the people
above you on the food chain - those with actual power - are kept happy.

~~~
carterklein13
I feel like "tech lead" also varies so much from company to company. Where I
work, people are technically bestowed the title of "tech lead," and this just
means they have to take ownership of far more work for essentially no more
pay.

Most "tech leads" where I work are senior engineers, but not all senior
engineers are "tech leads." Here, it seems more like a purgatory positions
where you don't want or have the skillset required for engineering management,
but are far more senior than other senior engineers.

~~~
closeparen
I usually see it as “most senior person with responsibility for this domain”
which, if it’s a smaller / less intense domain, may not be that senior at all.

------
valbaca
Here are my three:

"Unwritten Laws of Engineering"
[https://www.amazon.com/dp/0791801624](https://www.amazon.com/dp/0791801624)

Originally meant for mechanical engineers, it provides specific and general
non-technical career advice. It focuses on what we call “soft” skills today.
This field puts so much weight into technical prowess that we often think of
these “soft” skills as somehow beneath the “hard” skills. Nothing could be
further from the truth. If you don’t spend time on learning how to navigate
your career, you’ll be as well off as a dragster on the backroads: you’ll get
nowhere fast. I only wish I could have read this book sooner; it would’ve
saved me a lot of trouble early on.

"Becoming a Technical Leader"
[https://www.amazon.com/dp/0932633021](https://www.amazon.com/dp/0932633021)

Don’t let the title fool you: this is not just for people planning on becoming
a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this
book you must work through the exercises to get the full effect. It will be
worth it. It’ll be like having your own therapist, life coach, and mentor,
except that it’s just you and a notebook answering very important questions.

"The Pragmatic Programmer"
[https://www.amazon.com/dp/020161622X](https://www.amazon.com/dp/020161622X)

I consider this book 10x better than Clean Code and Code Complete combined!
(Though that may just be because I read PragProg first?) As the name suggests,
this book provides more tactics advice but also gives great career advice too.
The most famous is to “learn a new language each year.” This kind of advice
seems a bit much, but over my career I’ve had to write in over a dozen
different languages, even though 90% of the code I’ve written has been in just
one language, the ability to pickup new languages quickly and easily is a
solid skill to have. And that’s just one particular tip from this book.

(These are excerpts from my suggested reads blog post:
[https://valbaca.com/posts/my-suggested-
reads-3cie](https://valbaca.com/posts/my-suggested-reads-3cie))

------
neves
These are nice books, but I don't believe in a technical manager list without
Jerry Weinberg's books:
[https://leanpub.com/b/peopleskillssoftbutdifficult](https://leanpub.com/b/peopleskillssoftbutdifficult)

------
dredmorbius
A grasp of organisational theory, its history, and observed realities is also
recommended.

Charles Perrow, _Complex Organizations_ is both a classic and review of
previous literature (through about 1985):

[https://www.worldcat.org/title/complex-organizations-a-
criti...](https://www.worldcat.org/title/complex-organizations-a-critical-
essay/oclc/979139067)

Though it makes little discussion of the high-tech world, I read its
observations on the music industry from ~1940--1980 as highly similar. Labels
are largely analagous to VC (including YC), and the disruptions of new trends
and technologies, and re-forming of controlling monopolies, strikingly
similar.

------
username_taco
This article has so many omitted words that it’s hard to follow, even if the
content is decent. I’m left wondering - did the author ever actually read what
they wrote, or did they just press send and hope for the best.

------
catsarebetter
Don't want to be too negative but there's a decent amount of politics that
you're required to navigate to get their and then handle, wish someone would
write a guide for that, dead serious

~~~
tjchear
If it helps anybody, this is what I learned from my time at G.

Suppose you are given an objective. Now you drive a project to achieve said
objective. For starters:

0\. Identify project requirements and scope.

1\. Identify stakeholders. These are people/team who are directly/indirectly
affected by your project/decisions. They are also people who may have nothing
to do with your project, but could stand to gain something from working with
you.

2\. Talk to said stakeholders. Find out what they are good at, what they want
and need. The underlying driving motivation for everyone is almost always
career progression (promotion/bonus/etc), but this translates to different
interests and goals. E.g our team just built this new tool and we want it to
be adopted more widely in the company for greater impact to show that we're
worthy of promotion to the next level.

3\. Now that you have identified people's roles and interests, it's time to
figure out how to align your interests with theirs. For example, you're
migrating off a deprecated framework/tool, and another team is peddling their
new framework/tool. Maybe you use their framework/tool. Maybe they customize
it for you. Maximize this alignment. Business people would call this synergy.

4\. Consulting with people shows that you are not a lone wolf, that you can
work with others, plus no single person holds the entire picture along with
the details. One added benefit is people feel good when they're consulted
with. Makes them feel important. It also gives you visibility amongst upper
leadership. This step is to build support for and awareness of your project.
When everyone has a hand in it (no matter how small), they'll care more that
it succeeds.

5\. You get back to the drawing board and start designing the system/solution.
You hold regular meetings with stakeholders to keep them in the loop, and to
incorporate their suggestions. Any time there's a blocker or consensus can't
be achieved, you go to their manager directly, or you have your manager talk
to their manager. This is the diplomacy/politics part, and where great soft
skill is needed (you can leave it to your manager as well). Ideally, if you
did a good job with step 3 and 4, you won't have to get into this quagmire.

6\. You partition work and dole them out to junior engineers, preferably
pieces that can help them in their career as well. This is mentorship +
delegation. It's what allows you to be productive and effective - you leverage
other peoples' skills.

7\. When you finally launch, thank and credit everyone involved (including
leadership). Everybody gets to look good.

------
jsperson
Joel on Software - practical advice for both the leader and the developer. I
still reference it frequently.

Edit - more explanation

