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.
Depends on the ditch. That's effectively how the Loon Lake Powerhouse was constructed. Traversing the entrance shaft funicular you can see the bobble where the upper and lower "ditches" deviated somewhat.
> 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).
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.
I was on a project where we added 6 people to an 8 person team in 2 weeks. Velocity stayed exactly the same as before for a sprint or two but quality issues jumped. We then spent an enormous portion of time on bug fixing. It took about 2 months before the overall team really saw a net benefit to velocity by adding those people.
Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.
> We have developers committing code in their first week. Sometimes day 1 or 2.
If you're doing anything complex (which can just be: if your codebase is more than a year or so old) than the quality and velocity of code someone can contribute on day 1 is vastly lower than they can a month later.
I see the Mythical Man Month tossed around as an excuse for not trying sometimes - by people who haven't even tried to split up and spread out chunks of work in parallel - but onboarding cost is definitely real.
You gotta evaluate "can I get enough overall throughput at this point in time to make up for the total efficiency lost" and also the rest of the business priorities outside of this one project.
> 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.
I vaguely recall reading Soul of a New Machine years ago, but I don't recall there being a lot of SWE lessons in it. Maybe it was because I read it so long ago. Mind sharing a few things you got from this book?
It's been a long time since I read it as well and I knew the hardware/microcode people in the book better than the OS folks--and I think the book probably focused on them more. Maybe it's not really SWE lessons per se as so much as just a really good account of a computer systems project. (I worked at Data General for many years though I joined a few years after the events of the book.)
Showstopper (about the development of Windows NT) is more focused on software obviously.
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.
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.
Well you can set standards, if you're the picky type you can then say how you want things done.
I am often less picky than other people, but I find that the picky types often want things that I feel are less than optimal.
So getting offered tech lead coming into a place can be seen as a good defensive choice if you are coming from a place where you feel like you've been suffering because you didn't have the control.
Sounds like you've never worked at a startup where the CEO walks in one day and says "we're changing direction" everyone stops what they're doing and desperately tries to turn the boat around, only to have that happen again two week later...
Like it or not, that is what power is.
Building respect and trust is great, but you can have all of these things and not have any real power. I've seen trusted respected people let go in a heartbeat when times are tough. The people that can decide to 'let people go' are the ones with power.
In my experience tech leads and middle managers often have to do the difficult task of balancing the whims of power with sound technical decisions. This is a hard task because it's frankly much easier to just bow to the whims of leadership and wait for the day when they decide a "shakeup" is needed and layoff most of middle management.
I mean that's not really power if your staff quits on you after you do that. If you want to be able to pull off those sorts of pivots successfully, you need your coworkers to respect your competence and judgement.
Could any other CEO have come into Apple in 1997 and done what Jobs did? They respected Jobs more than they would have a generic CEO.
Heck didn’t the Pandora CEO convince people to work for two years with no pay?
A number of us stayed at a startup until the bitter end because the leadership was completely honest with us and the investors promised to pay us for every hour we worked.
Edit: I'm saying this because I decided to stop being "tech lead" recently, precisely because of the problem of responsibility without authority.
Yes, people respect me and my decisions, up to a point (we have several very competent people and we don't always all agree) . They did that before I was tech lead and to the exact same amount after. My work did not change one iota compared to what I was doing before. But suddenly I got blamed for some things that I had no power to prevent.
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.
Power implies the ability to cause change. When you say "real" power I think you might have some specific kind of change in mind. What kind of organizational influence are you considering "real" power?
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.
Which Drive book are you talking about? who's the author? Those books you mentioned seems interesting, I'll check out. If you have more on topic that you think are also worth recommend, please let me know.
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?
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.