6 ms·
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 lit
by turbojet1321 2y ago
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
- nine_zeros 2y agoThis 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.
- jcgrillo 2y agoIME 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.
- ern 2y agoI 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.
- jcgrillo 2y agoI should have been more specific--what I mean by nontechnical managers is managers who don't commit code regularly.
- turbojet1321 2y agoIME the differentiator is not a technical background; it's whether they care more about ladder climbing/appeasing their own managers or doing something useful.
- nine_zeros 2y agoThis 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.
- delusional 2y agoI 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.
- polishdude20 2y agoCan you elaborate?
- modzu 2y agoaka the entire c suite
- maccard 2y agoDisagree - I've seen this all over. The problem has absolutely nothing to do with tech whatsoever, and everything to do with decision making.
- stuaxo 2y agoYou also get developers made manager that are terrible at management and trust so lean on micromanaging. There's a happy medium somewhere.
- hibikir 2y agoIt 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.
- arkh 2y ago> 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.
- erik_seaberg 2y agoThere 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.
- bobnamob 2y agoDeployment 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.
- bobnamob 2y agotypo: Reputational not repetitional ofc
- trhway 2y agoI 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.
- magicalhippo 2y agoMy 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.
- turbojet1321 2y agoI'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.
- trhway 2y ago>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 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.
- charles_f 2y agoMaking 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
- toss1 2y agoExactly 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 https://www.etymonline.com/word/decision
- heresie-dabord 2y agoFrom 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
- sameoldtune 2y agoManagers 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.
- tpoacher 2y agoI 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.