Classic books for tech leads or those aspiring to be
sourcelevel.io
sourcelevel.io
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.
Even Steve McConnell of Code Complete and Rapid Development has argued against it:
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).
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.
That doesn't mean they're fully on-boarded until 6 months in.
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.
Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.
Upper American River Project, east of Sacramento.
https://en.wikipedia.org/wiki/Upper_American_River_Project
Video tour:
That said, I'm not sure I'd recommend the whole book today.
Might also include Soul of a New Machine and Showstopper!
Showstopper (about the development of Windows NT) is more focused on software obviously.
This is an excellent principle for software development as well IMO.
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.
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.
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.
https://staysaasy.com/product/2020/06/14/a-vp-products-readi...
(edit: we write stuff for engineers too)
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
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.
That's just not healthy.
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.
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.
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.
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 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.
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.
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.
"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)
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.
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.
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.
Edit - more explanation