You'll be surprised at how many FAANG middle managers make $500,000+ per year and add 0 value to their engineering teams. From my 4 years at Big Tech, I saw execs do all of these: 1. Listen to their engineers' detailed project timeline, ignore it to give an insane deadline instead, and then be surprised when the final product is half-broken 2. Torpedo a well-scoped project at the last minute with a sudden feature change, so they could claim credit on the product's final direction 3. Hire armies of annoying project managers who simply asked "Is it done yet?" every week to make burnt out engineers move faster (it didn't work) At Google's scale, it's simply impossible to prevent people from realizing they can just play politics all day instead of doing any real work. That being said, there are many genuinely amazing managers out there. Big Tech in particular has tons, with a proportion much higher than industry average. If you're joining a larger tech company, most of your success depends on finding one of the good ones to be your manager. Learn how to do that with our 21-part engineering manager valuation guide, now 100% free: https://lnkd.in/gE8aZzn9 #techcareergrowth #softwareengineering #layoffs #google #management
There are many 'project managers' and 'scrum masters' who literally make a spreadsheet of progress and costs and pass it along to the budget holder/business. No removing/anticipating blockers, no leveraging multiple projects to avoid redundancy or get new feature idea/connections, no talking with the customer about expansion opportunities and lining up goals. Show me your incentives, and I'll tell you your outcomes. If your only deliverable is a budget report...
I'm more surprised when I find a middle manager, in any company, that adds value.
#3 touches a nerve for me. Many years back my team of very capable doers and builders at one point were put at the mercy of Program Managers who started a lot of meaningless "is it done yet" "what are the blockers" "what is your workaround" it brought down the productivity of the team to less than 50% as they started doing these useless overhead activities rather than actually coding and building.
Let me translate this corporate theater into actual numbers: The real cost of "zero value" management: • $500K salary × 100 managers = $50M burned • 50% efficiency loss × 1000 engineers = 500 engineers wasted • 30% project delays × $10M projects = $3M/project lost • Countless good engineers leaving But here's what nobody talks about: This isn't a bug. It's a feature. Large tech companies NEED: • Political layers • Decision diffusion • Responsibility dispersion • Accountability shields Why? Because at scale: • Clear ownership = clear blame • Direct communication = direct responsibility • Efficient processes = fewer managers • Quick decisions = risky careers The real game isn't finding "good managers." It's understanding that: • Systems create behaviors • Scale rewards politics • Size demands inefficiency • Bureaucracy protects careers Want actual success? Don't look for "good managers." Build small, accountable teams. (From someone who's seen both sides of the management matrix) #TechReality #NoBS
I love studies and papers. One paper looking at Data from USA and Denmark showed that managers with business degrees provide almost no improvement in productivity and in 5 years time can reduce their employees wages by 6%. https://economics.mit.edu/sites/default/files/publications/Eclipse%20of%20Rent-Sharing%20-%20the%20Effects%20of%20Managers%20.pdf In my opinion, managers are useful for only providing structure and an accountability-hierarchy. But too much of middle management hampers team productivity rather than improving it. A technically adept member who has spent enough time in the trenches is no less (or probably better) than a manager bringing in frameworks and processes, yet no real value.
Product/Project/Program managers do a lot more than just ask “is it done yet”. I had a colleague put it really well a few months ago on a request for feedback when he said “You enable me to do my best work as you go out, deal with the “people” side of things, arrange for data, handle compliance, update leadership, meet with partners, gather requirements/feedback, etc so I can spend my time where it’s best spent - building”. It also helps to have a technical background. If there’s ever anything my engineering colleagues do not have the capacity/time to go build, I can do it myself and then pull them in if I have questions.
This sounds very familiar. In some cases, I’ve observed roles where the primary focus seemed to be on tracking progress or facilitating meetings, such as checking off tasks or creating Jira tickets—activities that could potentially be automated. At times, these roles involve gathering input from developers and presenting it to leadership, which may inadvertently overshadow the hard work of the engineers.That said, product managers and leaders play a critical role when they effectively bridge the gap between teams, prioritize work strategically, and advocate for their teams’ achievements. It's encouraging to see a shift toward streamlining middle management, which can ensure that the contributions of developers and other team members are more directly recognized and valued.
I take some exception at the third point. The project managers are an integral part of delivery; you bring up an old trope of “annoying” project managers who appear to only exist to perturb the DEVs. If the PM is perceived as just being a budget keeper, then you have reduced a critical team member to a caricature. That is a leadership/management issue when that happens to a team member with the PM role, and it damages team trust. It is not the PM that is “annoying” the delivery team.
Pity :/ come work at Netflix :) best managers I’ve ever had who stay out of your way yet who fight for and empower you
From cars, computers, & batteries to software, spacecraft & gigawatts – Solving problems big and small | Stanford | Michigan | PhD
2wAt one point, when I was a young engineer, me and a few other junior engineers had bingo cards with all of the standard questions that anyone clueless about a program could, and did, ask. The questioner’s game was usually to see and be seen, not drive a program forward. The bingo cards made many long, trivially useful meetings more tolerable. After the meeting, we junior engineers would compare notes to see who’s bingo card won. Rarely did any of us not fill our card. Later in my career, I worked with an adversarial senior management team. During meetings, once a victim was selected, increasingly pointed questions were asked until the victim failed to give a satisfactory answer. These sessions rarely drove progress and usually stalled a planned agenda on one of the first items. There the game was to guess how far the interrogation would go until the victim floundered. The best I could figure, it was like statistical process control. If enough questions were answered without failure, it indicated things were in good hands.