8 ms·

I remember an experience many moons ago where there was some "emergency" situation and our manager was just insufferable. Every 40-60 mins wanting to check with

• eastbound 4y ago
  You gained seniority. I have employees who don’t take a support case with a customer waiting with the straightest path, instead they take the opportunity to refactor code, so I check on them all the time; Others who refactor the code after delivering the bugfix, and those I leave them alone.
  • deleted 4y ago
    [deleted]
  • slgurtman 4y ago
    This is a result of always having the refactoring put on hold for feature development. Eventually engineers realize the only way to address tech debt is to refactor as part of a feature or bug fix. This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.
    • mk89 4y ago
      > This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment. To my surprise, this is not always true. Some engineers do things because they have fun, even senior ones, and they will keep on refactoring things until there is a hard stop. Best is to never generalize. It may depend from team to team, etc.
      • evilduck 4y ago
        Yeah, everything is situational. Someone can be a very competent developer, even an congenial coworker, and still be a terrible employee.
      • candiddevmike 4y ago
        If you don't let them do this from time to time they will quit eventually, IME as a manager. Whether that's beneficial to the org or not is debatable. You can kind of "release the pressure" in a planned manner via hackathons, but those almost always never have the appropriate frequency.
    • vgatherps 4y ago
      The prioritization of refactoring is strongly context dependent. A small startup with a fast moving product trying to acquire and retain customers cares much more about serving said customer right now than an established business who has more freedom and engineers available to dedicate time to forward thinking projects like refactoring.
      • jrockway 4y ago
        I've worked at both large companies and small startups, and I've never seen taking on tech debt pay off. Features never get delivered as quickly as anyone wants, but sometimes tech debt completely prevents even thinking about features, and not being able to even imagine implementing something is a much worse problem than being 2 extra weeks late to the newest pivot. If I were starting a software company today, I'd want to keep my POC code about as clean as I'd keep production code at a large company. Well, cleaner. It's going to be alive as long as you are, and there will never ever be a good time to rewrite it. Having said that, I am very skeptical about what some people identify as tech debt. Things like "we're using X logger instead of Y logger, this codebase is unmaintable" I tend to not prioritize, but things like "this system looks weird and we don't understand if the code is wrong or the documentation is wrong" is something that should be addressed with high urgency. It's very easy to spend a lot of time maintaining misbehavior that should just be fixed, and the first step is understanding whether or not something is wrong.
    • lazyasciiart 4y ago
      When my coworker did it, it was the result of zero self discipline or focus, so he straight up got distracted by thinking of a way he could rewrite the whole app instead of making the two line *already understood* fix. He was a very good programmer and a terrible engineer and terrible coworker.
    • ilyt 4y ago
      I do that on non-time-critical cases, if it doesn't matter whether I deliver it within an hour or day better to just do it now when I have it fresh in my mind. But anything longer gets thrown to backlog
  • Waterluvian 4y ago
    I think this is an interesting comment because it seems to try to re-locate agency back onto the manager. Ie. It’s not that the other manager was better, it’s that I somehow earned the better management. Correct me if I’m misinterpreting you.
    • vgatherps 4y ago
      It seems like a pretty standard (and simplified for HN) classification of employees who are and aren’t able to prioritize well. Employees who can prioritize well will naturally be given more independence to make choices than those who don’t. This of course assumes the management is able to make good decisions about prioritizing but I think the commenter should be given benefit of the doubt here.
  • NikolaNovak 4y ago
    This is an interesting point and may be part of the factor. I.e. There are two variables, and chances are that playing with either affects the outcome - experience and self sufficiency of the hands on person, and experience and self sufficiency of the manager (plus, I'll argue, other variables like maturity of processes, and client relationship / management state, etc). There is an inclination to focus on one variable only. Fwiw. I've been a hands on techie for 20 years, then ops manager for 5. I've certainly been an Inexperienced/been a bad manager at times (especially as for a while, highly functional specialized vols reported to me as well), and I'd like think I'm becoming a decent or even good manager. But even still, there are definitely teams and individuals that I will feel the need to manage and focus ; vs others that I feel I can let prioritize and self manage. (In the ops, of course, establishing formal urgency levels and resulting comms expectations and paths, can reduce stress on EVERYbody)
  • telman17 4y ago
    How do you coach the former to behave more like the latter?
• Godel_unicode 4y ago
  When I interview for a job I always ask my prospective manager about the is. “What’s your process for getting status updates during a crisis”. This question is graded pass/fail.
  • ahepp 4y ago
    Examples of passing and failing responses?
  • iamcreasy 4y ago
    Can you share some of the good/bad responses and was your inference correct?
    • givemeethekeys 4y ago
      Not having a process = fail.
  • davnicwil 4y ago
    I am sure you know this, but be careful with this strategy. The worst managers of all will tend to give you the answers you most want to hear in these situations. The best will tell you the truth. This might be the same in the best case but is often less than perfect in reality (though, per being a good manager, can at least improve).
    • sigstoat 4y ago
      > The worst managers of all will tend to give you the answers you most want to hear i don't think the worst managers even know what the right answer is.
      • ilyt 4y ago
        They might repeat something that they heard.
      • deleted 4y ago
        [deleted]
• 908B64B197 4y ago
  I've seen this distinction and it always boils down to two factors: is the manager technical and what's the caliber of the engineers. Technical managers typically have a pretty good idea of what the rough requirements for a given situation will be. They might not be familiar with the exact details but should have some clue, so they just want to make sure everyone has a plan and it's sound. Non-technical managers don't understand what's going on so need to micro-manage because they perceive everything as high risk and complicated. Caliber of engineers is pretty self-explanatory, but maybe that's selection bias; a 10x engineer won't stay long where he's micro-managed.
  • zmmmmm 4y ago
    definitely this .... non-technical managers have literally no tools at their disposal other than to bug other people to do things. in a crisis, therefore, all they can do is dial up how often and how much they bug everyone else to do the actual work. At best they act as communication hub, gathering crucial information and coordinating to ensure it gets to the right people as fast as possible and they act on it in the right way. But even in that role they are limited because they don't have enough insight to really know who needs to know what and what they can do with the information.
• Jenk 4y ago
  I've worked in >1 companies where the SLA requires hourly updates for incidents, and they have to have substance beyond "still fixing." This is in large scale finance and/or investment sectors where it is immeasurably important to keep clients (both "those paying us" but also the "those integrating with us" types) well informed of progress so as not to cause market panic. Sometimes communicating is worth it for interrupting the team.
  • emeraldd 4y ago
    There's communication by interruption and there's observation. If you have a situation where there need to be hourly updates, there should be a person explicitly tasked with observing and noting what's going on to be able to provide those updates with minimal impact to the group that's actually working the problem. Unfortunately, that means the observer has to be able to understand and follow what the engineers are doing while staying out of the way as much as possible. Tricky, but something you really need if for no other reason than to communicate and look for any holes that the team/person working the problem may not have thought of in the interim.
    • roland35 4y ago
      Yes, this role is defined as the "journalist" at my company and is an engineer tasked with writing status updates and the post-mortem report. It is important to have this role assigned from the start so that expectations are clear!
  • bluGill 4y ago
    If that is the case you should pair program, where one of the pair's only job is to sit behind the engineer doing the job and listen in, then take the meetings. This needs to be a full engineer who is fully capable of doing the work, but instead is just understanding the work, but not doing any. If the main engineer has a 'family emergency' your communication engineer has enough context to take over, while another engineer is assigned to communication.
    • antod 4y ago
• jrockway 4y ago
  I like to practice incident response on a regular basis, so people, including managers, know what to expect out of the process. If you do a practice incident every week, a real emergency will feel routine and people will be less anxious. If people are really distracting on the incident response call, you can always kick them off and elect someone to keep them updated, of course. I've never had to kick anyone off a call, though. I was introduced to Pagerduty's incident response guide and like it a lot: https://response.pagerduty.com/ https://response.pagerduty.com/
• lnxg33k1 4y ago
  I had a manager at my last job who tried to do the "what's the update" during a crisis and I just decided to make fun of her saying "I solved it but decided it would be funnier if didn't tell anyone" and she stopped
• onion2k 4y ago
  Something to note is that there are two important variables in the second story. The first, as you say, is that you had a different manager. The second is that you had more experience. In every situation a manager is only ever as effective as the information they have, and that comes from how good their team is at communicating with them. I'd hazard a guess that you were better at telling your manager what they needed by the time the second event happened. If the team has good comms, and experience of both working and communicating updates to their manager regularly, and the skills to explain things in ways people understand, generally speaking you find the manager needs to check in less often. They can trust you to raise things promptly, to ask for them to do things for you, and that when you're quiet it's because you're busy rather than stuck. I find that teams who complain about their manager very often don't trust their manager and vice versa. Building up that trust by getting both sides to work on improving comms fixes a ton of problems.
  • rhommel 4y ago
    > In every situation a manager is only ever as effective as the information they have, and that comes from how good their team is at communicating with them. So much true in these words
  • serial_dev 4y ago
    > > Every 40-60 mins wanting to check with the ~3 engineers working on the issue for an update > I find that teams who complain about their manager very often don't trust their manager and vice versa. I get that sometimes it's not (only) the manager's fault if there is no trust, but if as a manager you need a status update every 40 minutes while the people are fire fighting and working on an incident, I feel like you failed as a manager.
    • viraptor 4y ago
      I feel like there's a good and bad way to do this at the same interval. Of course it depends on the situation as well and what you say, but when I'm dealing with an actual emergency, I can't imagine not posting an update every hour or so. Usually much more as a way of documenting what's happening for a later PIR. If a manager doesn't get the required details to know what's happening (I'm situations where they do and still ignore it), then the whole process could use an improvement. From my SRE perspective, if an incident takes longer than 30min, I want my manager/coordinator to be constantly updated and handle communication with the rest of the company/customers.
• bitL 4y ago
  As a VP I had some conflicts with subordinate managers who were super anxious and transferred their anxiety on their own teams. Basically they had no clue how to solve problems due to not being technical and as a consequence made their whole teams neurotic like they were. I typically had to take over for a while to cool down the team and shield them from their managers whereas managers were supposed to shield the team from me.
• awinter-py 4y ago
  Crisis communication is an specific sub problem of team communication. Good takes on this often come from experienced disaster responders, like a fire chief or FEMA. Their version of this is very real: 1) the annoying manager bugging for updates is the mayor's office or other powerful executive branch, 2) the emergency from which people are being distracted is life or death, 3) a jumpy executive can give wrong messages to the public which increase the workload or danger level. Saw a lecture about this once, takeaways were 'clear lines of communication' and 'clear chain of command'. Wherever possible, put a person or a process between non-operational managers and front-line responders.
• Pxtl 4y ago
  Hah, when an emergency is happening only one person asking for hourly status updates would be a goddamned reprieve. When stuff hits the fan I expect to be getting constant questions from the business analyst, the helpdesk, and manager, as well as having to explain to every other person who hasn't heard that I'm busy that no I can't help them with that today.
• treeman79 4y ago
  Had something similar. Deadline to go live was Monday at noon. We didn’t even have a working proof of concept on Friday. Has multiple managers at my desk every 30 minutes on Monday. At 11:58 they announced they were calling client to go live with them. Product was not working. Manager. Hey they say it’s not working. Me a few final key stokes and a save. (On prod server) Try now! Client says it’s working now! Went to the ER. Thought I was having a heart attack. Never again.
• brailsafe 4y ago
  God I've been feeling this lately. Manager turned into full micromanage mode. I started regretting waking up and checking slack, because there'd be an "Any updates on X?" message sitting there, often coupled with some passive aggressive remark. When I feel like I have more autonomy, I intuitively feel the urgency and act appropriately, updating people as updates happen.
• Rapzid 4y ago
  Yep, a manager makes or breaks role. Good manager manages up and acts as a bulkhead against pressure coming from above.
• dmatech 4y ago
  In that scenario, it's often because the manager has someone breathing down his neck too, so you have bad communication and high stress all up and down the org chart. But sometimes the manager is the source of his own stress and all you can do is manage that.
• Aeolun 4y ago
  I had some emergency a while ago where they insisted on being on a call with 10+ people while it was resolved. After an hour of badgering and applying fixes that all those helpful people thought up I told them I couldn’t focus, went off the call, and fixed the damn thing in 15 minutes. Being on a call with people trying to be helpful is extremely aggravating.
• sufehmi 4y ago
  All the good managers I've ever encountered have the same skill: They ask smart questions. ==== At the beginning, they try to understand the situation by asking the very dumb questions - but they're not shy about it. They'll say, "Let me pick your brain", "Sorry I'm an idiot, so let me ask this dumb question" - and so on. No ego. But in no time, their questions will become smarter. Coupled with their big picture view / perspective, their understanding of the system and the business - they quickly became a very helpful assistant for us to understand the problem, and in many cases, even able to suggest the, best, solution. ===== Bad managers gives no added value, and instead distract you from your job. Any senior management should understand these, and should be able to pick the good ones. Otherwise the company/institution will be mired with persistent problems in no time.