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.
I really think that the Sharp Tools essay is pretty significant. That's an initiative that I'm really trying to push at my work. In the one essay about how adding people can make a project even more late... I think too few people focus on the significance of partionable tasks -- that is, when you're a tech lead, it's very important to understand what tasks should or should not be partitioned, and equally as important, _how_. For example: If you need two long ditches dug and have 2 workers - you might say "you dig ditch A, and you dig B". Or you might say "You start at the north end of A and you at the sound end -- dig towards each other and meet in the middle. Then, repeat for ditch B" But you would NEVER say "You dig the top half of ditch A, and you dig the bottom half, meet in the middle, and repeat for ditch B". Not enough managers/leaders put an emphasis/importance on understanding how to partition a task -- or that it often requires more than MBA knowledge to do so.
> Quick quiz, hot shot: what did you think of the surgery team metaphor?
Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.
The best of Brooks is the silver bullet article. It was included in newer editor editions of the book. Great to understand why the shiny new visual programming product someone is trying to sell your company won't improve your productivity
> 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
The reason it is continually mentioned is companies make this mistake over and over and over again. I am witnessing it happen right now on a project, and I have seen it happen many times before.
Now, I love the story about the biblical quantities of paper documentation that was produced, distributed, and consulted every single day during the development of OS/360. But broadly the book has aged poorly -- it's quite thoroughly misogynistic for example -- and absolutely does not get a pass since the author explicitly declined the opportunity to update it in later editions. Moreover, the writing is nothing special, and the ideas have seeped quite deeply into our culture, so it's not necessary to read the primary source. Folks today would be better off reading the Wikipedia page which does cover the main concepts, including the surgical team.
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.
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.
The power that comes with a job title or position is actually quite limited. And it also calls into question as what exactly is meant by power. Personal power (getting your way?) or creative power (putting forth your energy for the benefit of the organization). I find that it's actually not too hard to have a great deal of creative power, regardless of personal power -- by listening and responding well to the needs of others and by effectively solving problems.
It doesn't matter where you are in the org chart. Being a good leader is about prestige and respect, not dictatorial power.
With prestige comes attention to what you say and do, and ability to influence decisions.
If you feel like the middle manager is powerless, these are exactly the types of books to read. Other recommendations include High Output Management, Drive, How To Talk So Kids Will Listen (I'm serious), Turn the Ship Around, Out of the Crisis, and more.
That’s something I have learned early in my career. No one will “give” you authority. You have to create your own role through trust and leading by example.
This description sounds more like a product manager and this is essentially how I see Tech Leads in my department. This makes them really think hard about their responsibilities and the actual job, that needs to be done.
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.
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.
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.
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.
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.
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
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.
I am an engineer that works as a civil servant. When I first encountered politics (both office and "real") I started reading political philosophy, rethorics and sociology books.
Pretty broad theme. I know.
My biggest takeaway was a framework for explaining my reality. To be specific. I now view some interactions though a perspective of "power".
I don't know if it helps me navigate the interactions better. But my emotional well being is much better.
I agree with this. Eager to hear advice / tips / book suggestions on how to deftly navigate this without explicitly appearing political to the rest of the team?
[+] [-] mikestew|5 years ago|reply
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.
[+] [-] daveslash|5 years ago|reply
[+] [-] fnord123|5 years ago|reply
Even Steve McConnell of Code Complete and Rapid Development has argued against it:
https://stevemcconnell.com/articles/brooks-law-repealed/
[+] [-] mandarg|5 years ago|reply
Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.
I had wondered about (and rour comment inspired me to look up) whether people have had any experience trying it out, https://softwareengineering.stackexchange.com/questions/3552... has some interesting references and pitfalls of the approach.
[+] [-] neves|5 years ago|reply
[+] [-] jmchuster|5 years ago|reply
[+] [-] Mc91|5 years ago|reply
The reason it is continually mentioned is companies make this mistake over and over and over again. I am witnessing it happen right now on a project, and I have seen it happen many times before.
[+] [-] cgrealy|5 years ago|reply
So yeah, some of it has dated, and some of it I disagree with, but it kills me that a lot of the lessons are still not learnt 45 years later.
[+] [-] ghaff|5 years ago|reply
That said, I'm not sure I'd recommend the whole book today.
Might also include Soul of a New Machine and Showstopper!
[+] [-] gkop|5 years ago|reply
[+] [-] staysaasy|5 years ago|reply
https://staysaasy.com/product/2020/06/14/a-vp-products-readi...
(edit: we write stuff for engineers too)
[+] [-] sosilkj|5 years ago|reply
[+] [-] carterklein13|5 years ago|reply
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|5 years ago|reply
a) coworkers respect your competence & judgement so they align with your decisions on technical matters
b) engineering manager believes what you have to say about what the project needs, which may include staff allocation & performance management
[+] [-] techiferous|5 years ago|reply
The power that comes with a job title or position is actually quite limited. And it also calls into question as what exactly is meant by power. Personal power (getting your way?) or creative power (putting forth your energy for the benefit of the organization). I find that it's actually not too hard to have a great deal of creative power, regardless of personal power -- by listening and responding well to the needs of others and by effectively solving problems.
[+] [-] kqr|5 years ago|reply
With prestige comes attention to what you say and do, and ability to influence decisions.
If you feel like the middle manager is powerless, these are exactly the types of books to read. Other recommendations include High Output Management, Drive, How To Talk So Kids Will Listen (I'm serious), Turn the Ship Around, Out of the Crisis, and more.
[+] [-] baxtr|5 years ago|reply
[+] [-] scarface74|5 years ago|reply
Classic management theory is that their are three levers of power in an organization - relationship, expert, and role in that order.
No one is going to go the extra mile for a leader they don’t like or one they think is an idiot. Role power is the least effective.
I’ve left plenty of jobs because of a reorganization put me under a lead/manager that I didn’t like or respect or I thought they were an idiot.
Even if you don’t leave a company because they lean on their role power too much, people will “work to rule”.
I’ve had a lot more influence working at small companies by building relationships and demonstrating expertise.
[+] [-] procinct|5 years ago|reply
[+] [-] _the_inflator|5 years ago|reply
[+] [-] solidist|5 years ago|reply
Well said.
[+] [-] neves|5 years ago|reply
[+] [-] valbaca|5 years ago|reply
"Unwritten Laws of Engineering" 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
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
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)
[+] [-] dredmorbius|5 years ago|reply
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...
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|5 years ago|reply
[+] [-] catsarebetter|5 years ago|reply
[+] [-] tjchear|5 years ago|reply
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.
[+] [-] maCDzP|5 years ago|reply
My biggest takeaway was a framework for explaining my reality. To be specific. I now view some interactions though a perspective of "power".
I don't know if it helps me navigate the interactions better. But my emotional well being is much better.
[+] [-] tsjq|5 years ago|reply
[+] [-] jsperson|5 years ago|reply
Edit - more explanation
[+] [-] blargmaster33|5 years ago|reply
[deleted]