Hacker News Reader

Hacker News

Comment by turbojet1321 | Hacker News Reader

Parent Full thread

turbojet1321

If everything is an emergency, nothing is an emergency. I don't understand why so many managers fail to grasp this.

It's the same with prioritization. I've literally had conversations that go:

Manager: I need you to drop everything and do X right now, it's top priority

Me: Ok, well I'm currently doing Y, which was top priority this morning. Which is more important, X or Y?

Manager: Well, they're both equally important!

Me: OK, sure. I can't work on both, which one would you like me to do first?

Manager: [uncomfortable thinking noises]

Manager: Are you sure you can't do both at once?

Me: Yes

Manager: [Pause] Keep going with Y. I'll see if someone else can do X

sigh

View on HN

Making decisions is by definition cutting off stuff. It is hard, and requires courage, both of which no-one wants to expend. Because of course we want it all. Reducing WIP is probably the most efficient and least liked management tool.

Most teams I've been a part of have the syndrome you describe at every level of the hierarchy. I'm in constant battles to reduce the scope of what I have to build to avoid spending a year before it sees the light of day. I integrated a team a little while ago to help them do better. 7 people, 12 features in progress. I remember an organizational-level presentation we had was presenting the 15 priorities and accompanying 11 focus areas for the next 6 months. In the company wide evals, on top of our "self-defined" personal goals, we also have 3 imposed ones (d&i, security and learning) that were imposed by the corporation over the years as a reaction to something, and no-one will ever have the courage to remove.

This is almost a disease, and I've lost faith in that it will be cured some day

Exactly and literally; from the roots of "de"="off" and "caedere"="to cut" [0]

If you can't cut something off, you cannot decide.

decision (n.)

mid-15c., decisioun, "act of deciding," from Old French décision (14c.), from Latin decisionem (nominative decisio) "a decision, settlement, agreement," noun of action from past-participle stem of decidere "to decide, determine," literally "to cut off," from de "off" (see de-) + caedere "to cut" (from PIE root *kae-id- "to strike").

[0] https://www.etymonline.com/word/decision

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.

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.

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

typo: Reputational not repetitional ofc

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.

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?

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.

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.

aka the entire c suite

From TFA, everything is an emergency:

> we leaned on Code Yellow’s so aggressively that they became part of our standard operating cadence.

Code Employees-Prep-Their-Résumés

I have a highest priority queue where X is going into, and where Y is already comfortably sitting together with the other highest priority items (of course i don't have other queues :). Everybody loves that their X is going to be a highest priority item for me. "a" not "the". Thanks, English.

I've found this is only a short-term solution. It's much more effective IME to force the priority call onto the person making the demand.

I've done this as a team lead/scrum master. You want to add something to the sprint? No probs - you just have to choose something the same size to take out. You want to take a person off the team? Sure, you just have to negotiate with our clients about which work gets taken out of the sprint.

It's amazing how many things are suddenly less urgent when someone is forced to make an actual trade-off rather than push the pressure down onto the delivery team.

>to force the priority call onto the person making the demand

I prefer no forcing. Especially when it is say a moronic VP which i don't have enough force to exert upon him. In USSR we had a cartoon where a greedy customer wants a fur hat from a sheepskin, and he asks whether the hat tailor can make 2 hats from the same skin, and the tailor says sure he can ... that goes to 7 hats, and when the customer comes to receive the completed order he receives the 7 hats as ordered https://youtu.be/gSpjDi2BrQk?t=193

Smart people understood what hats they would get given the sheepskin and the number requested. And less smart - well, it is the cartoon fun.

My dad used to flippantly say he had three piles of papers on his desk: "urgent", "very urgent" and "no longer urgent".

As time passed the papers would get moved from one pile to the next.

I call this "top of the notes" syndrome, from my years in medicine, where every now and then a consultant physician would print something out and say "this is important, it should be on top of the patient's notes" (i.e. clipped on the cover of the physical folder, as opposed to affixed in it, so as to be the "first" thing one sees on grabbing that folder).

Which sounds great, until you have two of those.

And in reality, quite often you'd see folders where the "top of the notes" stuff had more entries than the normal contents of the folder itself. So, ironically people would skip the top stuff and jump straight into the folder as normal.

Managers are taught to live in a world of emergencies. I believe that someone who takes a measured and thoughtful approach to things is excluded from management out of principal.

Reply on news.ycombinator.com