Hacker News Reader

Comment by nine_zeros | Hacker News Reader

This dilbert-style management has become very normalized in tech - to the detriment of everyone.

It fundamentally comes from a place where there are too many layers of managers, none of who want to make crucial decisions that can bite them back.

Aka leadership only in org chart but not in setting direction, leading from the front, or accepting tradeoffs.

Ultimately it all boils down to org chart leadership. If managers could be voted out of the org chart by people below them in the chart, they'd have no choice but to show more spine and help the people below.

But this is not going to happen in corporations. So the best thing to do is quiet quitting. There is a reason this exists.

View on HN

It gets worse: A manager in those kinds of organizations that is truly scared also doesn't want people under them to make decisions either, so eventually everyone learns inaction.

At sope point the organization comes up with a code freeze, and a manager is afraid of changes near the freeze. Them said freeze keeps expanding as you get down to ICs, and eventually nobody gets to release anything in December, even if something is wrong and is costing the company users and money.

It's bad when people choose to quiet quit on management, but it's scarier when they basically are told to do it, in not so many words.

> code freeze

But they're saying they're doing "CI/CD". Why they do code freezes? Why are people still afraid to deploy on Friday?

Because they're not doing Continuous Delivery.

There are times when mistakes will cause more serious problems for customers. There are times when staff will be less available to aid recovery. A good strategy shouldn't deny these truths.

Deployment freezes are (should be) completely normal and justifiable.

Do you really think that Amazon is deploying (non-emergency/operational) code changes during BFCM or re:Invent? Or that Fox/CBS/NBC are deploying code changes during the Super Bowl?

Also (unless you have some business need to deploy before the weekend) why deploy on a Friday afternoon? You're just asking for latent defects to page you in over the weekend. Save yourself the trouble and delay that deployment till Monday morning. Your team will thank you in the long run.

Sometimes repetitional and/or sleep damage isn't worth being uncompromising on idyllic CI/CD goals.

typo: Reputational not repetitional ofc

I disagree, from a certain point of view. Consider the CDN. One customers downtime is the IRS’s filing date. The IRS’s slow time is during the Super Bowl. The NFL’s season of rest is baseball season. Baseball goes dark on cyber Monday.

When should the CDN undertake updates? Continuously.

(Obviously I do get your main point: the NFL should not upgrade at halftime of the Super Bowl. But there is a time and a place for different models.)

I think we actually agree with one another. Code freezes/deployment windows should be justified by business risk, not idealised always be pushing mentality.

CDNs and cloud providers are a bit of a special case. AWS definitely has soft blocks during tax peak and large sporting events, CDNs (guessing here) would likely be doing follow the moon(?) (i.e. off-peak) rolling releases

My disagreement with the parent comment was driven by lack of nuance

IME this is much more prevalent in organizations that hire "nontechnical managers". I personally will never work in such companies again, the experience of having your boss have literally no clue what it is you do for a job is not one I'll sign up for again.

I think the problem is a bit harder than that. I've seen a lot of managers who were once technical, but whose last hands-on experience was years, or decades ago. They have a vague idea of what they need to know/do but lack the skills to find things out themselves. and they turn into a major drag on productivity.

I should have been more specific--what I mean by nontechnical managers is managers who don't commit code regularly.

IME the differentiator is not a technical background; it's whether they care more about ladder climbing/appeasing their own managers or doing something useful.

This is a more accurate assessment.

A quick filter of effective management is asking the question: What do you hope to gain out of this job?

If the answer is a promo or ladder-climbing, you know that they will make sub optimal decisions that guide their ladder-climbing journey.

I regularly ask the question "how do know I'm doing good" in exactly those words. You'd be surprised at how easy it is to identify their management style from the answer to that question.

Can you elaborate?

aka the entire c suite

Disagree - I've seen this all over. The problem has absolutely nothing to do with tech whatsoever, and everything to do with decision making.

You also get developers made manager that are terrible at management and trust so lean on micromanaging.

There's a happy medium somewhere.

Reply on news.ycombinator.com