Hacker News Reader

Comment by dzonga | Hacker News Reader

you also have bozo managers like my recent one measuring metrics like PR time open, review count

while the team hasn't shipped anything useful in 6 months.

Its crazy how management has gone from productivity to a kind of policing, crowd control and abstract number management that has no sense.

One of things that's being discussed now is AI won't really help people ship products faster, because no one was serious about building them at the first place. In most large corps the managerial layers simply care about preserving their own jobs and comp.

Also similar things an be said about Product management too. Only a few months they would says developers are busy with other things, now that we can ship quite fast, whats your world changing idea? None

I like my manager but I think what many people don't seem to understand is that the manager tends to be the bottleneck. We were moving as fast as he was able to give requirements even without AI, and now we're being told to use as much AI as makes sense and now we just more product roadblocks faster. We may be shipping faster but amortized over all the roadblocks I'd say our velocity is like 10% faster.

Code was never the bottleneck.

Honest question — why don't managers like this get fired? My team wants us to ship fast. If I don't ship for a month I'm probably gonna lose my job, and rightly so.

If a whole team is spinning its wheels at the behest of its manager I feel like the manager should get axed.

It depends, of course, but in my experience managers like this do get fired after a few years, followed shortly after or before by their manager.

Years! I can see why managerial positions can be so coveted. You can be shitty at your job for years before getting sacked.

It's easy to hide in those positions. Many people don't know how to measure performance there and they get to point fingers.

My advice to anyone in this boat is to talk to the team underneath them every now and then. Get a pulse check. See where they get stuck and then set the managers goals based on that. At least one of their goals. It can be a small thing. It need not derail any roadmap or anything else. Explain why it's important for their team, explain where the team is having trouble.

See if they do it. If they do, they care about their team. If it's a small task/goal, it proves they can also be productive. Often times we have people taking on enormous goals that are vague or difficult to measure or complete in a timely manner. So a little mini goal (or a few, test a few over time) is very important here. Now, if they can't meet this goal or are unwilling to - you know you have a manager that doesn't care about the team they are managing. They can't manage that team or they can't be at the org. You can of course always try a different team or role for them.

In my experience a lot of managers (especially middle managers) kinda like to sit up there in a tower shouting orders at people, but never want to get their hands dirty or never want to support their team. They sometimes don't even realize the orders they are shouting are incorrect or impossible tasks to complete. This is where you get the "you now need 95% test coverage." That very often doesn't come from a C-suite level or customer demand because they don't care what the % is, they just want it to work.

Because the managers of those managers don't know the difference.

typical management layer in big tech

manager < senior engineering manager < director of engineering < vp of engineering < cto

why are so many layers needed ?

it incentivizes busy work and shit metrics like I outlined above. if they fire the manager it also means their managers have to get fired too

it's like communist party bureaucracy just veiled with tech

Depends on size of org. Many orgs end up too top heavy too quickly and don't have things in place to support that. That's where you get the "busy work." It's because they have too much time on their hands.

cto is a very wide title and in a global enterprise with hundreds of thousands of employees it's impossible to have a flat organization. There's probably 15 vp of engineering reporting to the cto. Each vp is going to have 10-20 directors reporting to them and beneath directors the fanout gets even wider. It does incentivize busy work and in a large org you can hide in the corner and be a potted plant for your whole career if you're smart enough to find it. But that is the nature of a large cooperation, I can't remember who said it but something like 80% of impact and progress to keep a business going is made by 20% of employees whether it's a big company or not. The rest are just sort of there playing along.

Because if that's what they were told to do. The organization is likely very dysfunctional, or has messed up priorities, which is probably about 80%+ of the startups out there and companies in tech in general.

Seriously. There's not many healthy engineering organizations out there. So if you fire one manager you end up with either another bad one or one who performs poorly due to the organization.

Paramount here is culture. It's important to remove toxicity. I remove toxic managers (and team members) because even if they were smart or productive, they ultimately drag down the entire org and the net of it is negative productivity. I don't care if they were the most skilled programmer on the team. Doesn't matter. They could be unproductive or could be making others unproductive and unhappy. They're out. They're out before they burn or push someone else out.

So you may also find that is the reason. If the manager is generally a positive influence on morale or culture, but is perhaps just a little too reckless, they may still have value. Remember that the reckless pressure may even being coming from top down. A lot of people still subscribe to (and misunderstood) the whole "move fast and break things" mantra.

Hey, I'm now measuring PR open time ... Only because there's been open PRs for months. It is of course possible that broad directional metrics are useful.

Reply on news.ycombinator.com