Why are non technical leaders obsessed with screen sharing during incident calls
Posted by RadioFieldCorner@reddit | ExperiencedDevs | View on Reddit | 244 comments
I can never work right when I'm sharing my screen in an incident call with 10 people on the line. I especially can't when I'm sharing my screen and some non technical leaders are asking questions and updates about every little thing I'm looking at, clicking or typing. I just can't. Am I the only one?
ahihidummy@reddit
Just do you job. They don't understand anw, they just want to have something to look at.
udivine@reddit
People that are kinda powerless in the situation want to know that somebody's making progress and that something's getting done. The screen sharing is simply a way for them to feel more agency over the situation and calms their nerves.
To their point thought, you may benefit a lot from learning to talk through what you're doing without it distracting you from completing the work. This could work well for presentations or explaining things on technical calls with other developers too. Not just for non-technical people.
BillyBobJangles@reddit
All the useless people are trying real hard to prove their usefulness.
Im regularly in production incident calls with 300-500 people as 1 of the 10 people doing the real troubleshooting.
Absolute chaos. Every 2 seconds there is a beep from teams for someone asking to join the call, every 30 seconds someone says they have the issue that we already know everyone is having. Product owners shouting random suggestions, leadership acting like they can bully a solution out of everyone, and operations reminding us every 10 seconds how fucked we are.
My go to move is to identify the people who can actually fix the thing and go to a seperate call. Then have someone go back and forth between the calls to give updates.
returntosander@reddit
wtf, why is this a regular thing?
IronSavior@reddit
Fair question with a real answer. Though that can be an indicator of real problems that don't get the priority they deserve, there are other causes that are less problematic. Having the same problems all the time is a big red flag. Frequently having new problems can be a consequence of operational growth.
For example, I used to be at an org that was fairly large (about 600 engineers, tens of millions of users, billions in revenue, not the whole company, just our org) and we had a lot of systems and things were always in motion. We always had new things causing new problems for an absurd number of people to whom we were accountable.
Incident calls had a process with a frickin wiki, a dedicated support team, it had its own on-call rotation for being in charge of internal communication. It's a lot. We certainly did have some recurring problems that didn't get correct priority (in my opinion), but overall we were spending our time on new issues and actually following up on them in a rational way.
Chaos caused by pretending your problems aren't real is a red flag. Chaos caused by having more customers than before and a steady flow of new features is a much better problem to have.
returntosander@reddit
thanks, that was really insightful. i’ve never worked at a place with more than 10 engineers, and even at my current workplace i sometimes get a taste of the complexities around incidents and stakes, etc. but then of course if worst comes to worst it’s still feasible to figure things out on a call with everyone. trying to make that “strategy”work with >10x the amount of people seems like a nightmare
chickadee-guy@reddit
see it regularly at my fortune 10
Vamosity-Cosmic@reddit
yeah wtf lmao
Turnip-itup@reddit
Why are 500 people on an incident call? That’s insane
kaouDev@reddit
completly insane
chickadee-guy@reddit
probably 400 of the 500 are just joining the call to say their app is down too
max_compressor@reddit
In big tech in a high profile incident, you get people in charge of status page/updating customers, whatever leadership who wants the chance to flex/be the hero, everybody who got paged wants to let you know they're affected (biggest category imo), PMs and others who will get asked about this later on, and then the people capable of actually fixing
t-tekin@reddit
I’m in big tech,
Our incident managers know better to isolate the devs working on the issues and curious onlookers and stakeholders. And update them. Their job is 90% that.
One of the common questions they would ask to a dev: “when should I bother you again for an update” - easy peasy.
So I have never seen what you are saying. Complain about your incident managers, get better ones that can say no and organize that mess.
Ariel17@reddit
Nobody cares about the amount of money spent in that meetings? Crazy af
fallingfruit@reddit
I sneak into the big incidents and grab some popcorn. Also usually there is something to learn for when its my issue next time.
oalbrecht@reddit
Do they have a popcorn cart coming around the office every time there’s an incident? Seems like a lot of people just there for entertainment.
spline_reticulator@reddit
Lady, he's putting my kid through college!
jay791@reddit
Big org, major issue with potential to impact business. Normal.
wetrorave@reddit
r/thatlookedexpensive
Ok_Chemist_3576@reddit
That reminds me of Scrum meetings back before AI was a common thing. Somebody calculated a about $15,000 on a daily basis. 5 times a week, 20 times a month. That's $300,000 wasted money on a monthly basis.
joske10@reddit
How does AI change Scrum?
Ok_Chemist_3576@reddit
Managers, executives, leaders etc have left Scrum behind as they feel it is not as useful anymore.
There even are managers who think they can vibe code the whole sprint with a couple of prompts. Once they have it they ask developers to review thousands of lines in a single PR and deploy it. Even tasks that are not part of the sprint gets mixed sometimes. They think that's good because "x10 productivity".
benruckman@reddit
Its big tech, they make average $200/hr. Are people multi-tasking after hours? Almost 100% no.
The real bill is how much money they loose per second x service is down. Thats not just cost (well and all of these people are salaried, so the cost is really 0 for pay), but when they are loosing millions of dollars a second, thats really not bad.
Ok_Chemist_3576@reddit
What a shitshow. I'd be on my nerves. Practices like this proves nothing and improves nothing. Nobody loads and rushes a surgery room when doctors are performing an emergency surgery.
We are to blame as professionals because we allowed these practices to happen. This won't prove our worth or how hard we are or higher emotional IQ.
mraweedd@reddit
This is the correct answer. Proper incident procedures should have one person informing everybody else and block access to the people troubleshooting.
I have had major incidents (think 10.000+ people not being able to work) were the CEO/owner were told to leave our floor and not pester the people working on fixing stuff
WitsBlitz@reddit
This is just sloppy incident management.
seanamos-1@reddit
And a more recent phenomenon is the: “Have you tried {insert wall of garbage from LLM}” from the non-technical people.
oupablo@reddit
The excuse given is always that they want "real time status updates" to share with customers. That's fair but asking for a status update every minute is in no way helpful to the people actually trying to fix the issue. It's like support/sales thinks that engineering is purposely hoarding the status to keep them in the dark instead of feverishly trying to figure out what went wrong. Then as each leader joins the call five minutes apart, you have to stop to give them an entire recap of where you are, further slowing everything down.
I've straight up said in the call before, "look. we're working on it. As we figure it out, we will post updates in the incident channel. Until it's fixed, let's hold off on asking questions about status and keep the line quiet unless you have identified the issue."
forbiddenknowledg3@reddit
This is a problem in other places too.
Like recruitment. Why do we need people who don't know the difference between Java and Javascript filtering resumes? Remove all these damn layers.
Nuzzgok@reddit
The alternative is asking the devs (as the only people to know there difference) to do it. That would drive me mad
dotnetdemonsc@reddit
Unfortunately for me, most of my career was spent onsite. Leadership would come sit in my cubicle. Apparently I was too stupid to fix a problem they had absolutely no clue about how to rectify.
pacman2081@reddit
They need to be seen as having value
gnuban@reddit
They could at least go and get some coffee
raughit@reddit
What a fuckin nightmare
Kqyxzoj@reddit
Time for some actual management? This is one of those things that proper management insulates you against. Buffer zone and all that.
This sounds like 290-490 people with nothing better to do. Don't they have some agents they have to supervise for some of that 100x productivity?
alienangel2@reddit
Calls like that we typically split the actual investigation off to a separate call and have a select few people relay updates from that call to the main one.
MrMichaelJames@reddit
Control the call then. It’s not hard to tell people to be quiet. People seem to lose their ability to communicate while on calls.
alinroc@reddit
This happened pre-COVID, when we were all working in the office too. Except it wasn't on Teams/Slack, it was people standing in your cube and literally breathing down your neck. It's a lot harder to tune people out that way.
mrbuh@reddit
That process is beyond broken. The second call with just the people doing the work should be the only call. Add an "incident manager" to handle communication with the 300 useless people.
third-water-bottle@reddit
Their necks are on the line, and this is an easy way to regain some semblance of control.
EdelinePenrose@reddit
where is your engineering manager?
RadioFieldCorner@reddit (OP)
On PTO in Disney World
MrMichaelJames@reddit
Are managers not allowed to take pto? Maybe this is actually a you problem based upon your attitude.
EdelinePenrose@reddit
then it’s a one off and not a real problem.
sootybearz@reddit
What’s your expectation of the manager in your question. Say OP worked the code area/responsible for the issue. I ask as a technical manager who would jump into these calls and try to help out but also there would be the expectation that the engineers on the product should be capable to do so too whether we are there or not
EdelinePenrose@reddit
management’s role should be to create a process were the engineers handling incidents are not being stressed out with bs as described in the op. setting boundaries for others. i’d also look into proactively preventing incidents through observability/instrumentation etc.
sootybearz@reddit
I agree about trying to reduce the stressful env but unfortunately when an emergency hits sometimes senior leadership will insist on screen sharing etc. and a manager trying to push back on that what help always. We’ve tried asking about going to separate breakout rooms to better concentrate - no we want to see as you work. I totally agree it doesn’t help but equally sometimes the manager has as much or in this case little power as the engineer themselves. A director won’t accept the pushback
xiongchiamiov@reddit
If your engineering leaders aren't allowed to own incident processes then that's the problem you need to solve.
I was at a company where due to being acquired we had an influx of people with Very Big Titles showing up and trying to exert a lot of (unhelpful) pressure on the engineers, and line managers and staff engineers had no qualms about shutting them down. Once I recall the incident lead Zoom-muting a President of something or other because they wouldn't behave.
EdelinePenrose@reddit
yeah, we don’t have the specifics of this situation. all we have is a stressed out panicked IC venting here.
of course, if the management layer doesn’t handle this then you’re in the “you’re fucked” category i alluded to earlier.
cobalt8@reddit
Did they edit their response or something? All I see is a direct answer to the question.
x2manypips@reddit
freeloading AND taking pto?
circalight@reddit
All-time response.
4444444vr@reddit
I’m imagining a manager who is just on a reverencing Disney vacation asking you to screen share while he is on a roller coaster
jaunonymous@reddit
I haven't had one of those in almost a year.
I report to the CTO, on paper, but in reality, I've not reported to anyone. I do my sprint work and get left alone.
Sounds nice, but we'll see what they think when we have a conversation about comp next time.
Ill-Education-169@reddit
Holy trauma dump, what were you attempting to address here?
tmarthal@reddit
They’re one of the non-technical people watching 😆
heubergen1@reddit
I don't mind. From my time in Help desk I've learned to comment what I'm doing at all times so I just do the same when I'm debugging the issue.
CodelinesNL@reddit
Neither can I. So I won't.
Successful-Actuary74@reddit
Communication 101. Looks like you skipped that course. I always share me screen especially on difficult to track down issues. Occasionally someone else notices something I missed. If not then no loss.
FishGiant@reddit
Tell them no. Only provide updates.
hopscotchchampion@reddit
I find setting jabba the hutt as my desktop wallpaper minimizes these requests.
HippyFlipPosters@reddit
underrated answer
llima1987@reddit
I used to have the political capital to send my boss a message saying "I'm working on the issue" and proceed to ignore any calls or messages without any consequence. But that's definitely a luxury.
Aamjray@reddit
this is crazy i genuinely get scared when i screen share even in small settings ot showcase or explain my work. incident calls, 10 people. i d get anxeity attacked right at the start
caboosetp@reddit
I just straight tell people, "i can either explain the issue, or i can work on the issue, but i can't do both."
Upper management is used to people sharing screens to explain it to them because people have had time to prepare presentations. They aren't used to people not sharing screens.
If they're going to get involved in incident calls, sometimes you need to be clear about how the process works and why explaining every step is hampering incident response. If you're not in a high enough position to tell off the CTO, then find someone who is to talk to them about it.
Bicykwow@reddit
This is the way. Can't believe so many people don't know how to say "no."
Ok_Chemist_3576@reddit
Many of them think they are "proving their worth" and how hard they are, so they allow this kind of silly performative pressure. It helps no one, and proves nothing.
Dyledion@reddit
Pro tip: you're always in a high enough position to tell off the CTO if you're confident and calm.
chalks777@reddit
and if your CTO has any worth whatsoever it might even get you promoted. It will at least get you noticed.
^^^^^but ^^^^^don't ^^^^^be ^^^^^wrong
mrbuh@reddit
I've used the phrase "zero sum" for this on multiple occasions. It seems to help cut to the chase with executive types.
p1-o2@reddit
Learning to "Drive" is a good skill. You can practice by just talking out loud as you work through stuff. That way when you have to do it on an incident call, you keep a nice consistent stream of dialogue going.
brainhack3r@reddit
Also, I used to be worried about if I had to take a 2 minute break for water or something.
If you're having that problem just literally say "I need to step away for 2 minutes. I'll brb".
Everyone understands you have to use the restroom or whatever.
What's really happening is that their ass is on the line and they want to make sure you're not out for coffee or something.
Ok_Chemist_3576@reddit
Because you are not driving, you are being DRIVEN. I just posted a comment explaining there's a difference.
codescapes@reddit
As I've gotten older I've noticed that "being real" like this is actually a confidence signal that often looks better than trying to treat things like a managed professional performance. If you need to get some water or pee or whatever then just say it and do it, do not overthink shit.
If you are demoing something and it doesn't go according to script then roll with it, don't try to keep a perfect 'frame' by worrying about how other people are thinking about you. Being genuine, sympathetic and approachable is broadly better for your career than being perfectly polished.
And when you're on an incident call people tend to make bad decisions if the stress is high. It's very easy to make a problem worse. You want the dynamic to be focused, transparent and sensible - not performative, fearful or needlessly tense.
Wonderful-Habit-139@reddit
Just had to deal with the usual demo curse very recently (good ol agentic systems amirite). I was just like "Yeah we got the agents a little lost on this one, let me try again". Restarted the discussion, went again and that was it.
Was it funny that it worked the 10 times I was trying things out before demo and failed the moment the demo happened? Yes. Was it a big deal? Nah.
ings0c@reddit
I hate doing live demos. I’ve started just recording a screen share with a voiceover ahead of time.
It’s a lot less anxiety inducing for me and there’s no risk of dev / staging going down while you’re mid demo, or some little gremlin manifesting either.
Saykee@reddit
I've done 5byears developing self driving forklifts. I could make that for lift drive the straightest line 99 times... The demo was always no. 100.
Ok_Chemist_3576@reddit
No, no. This is not "driving". Driving (also verbalizing) is when a pilot or surgeon is going thru a complex emergency issue and is explaining to his assisstants and apprentices what he is doing. All technically prepared to HELP and understand what he is actually doing. A surgeon getting assisted by nurses in ao ER while teaching medical apprentices. A Pilot talking to the Tower, while getting assisted by the copilot.
Driving is not being rushed by random onlookers who have no clue what's happening you are talking about nor can assist you. All the opposite, that's being DRIVEN. Let's stop this toxic idea.
donjulioanejo@reddit
Sure but an incident with 10 people watching while customers are blowing up the phones is too much pressure to to just learn.
xDannyS_@reddit
Yep, but it's a good skill to have and in this market you can't complain about it being too much anymore. These are normal standard expectations for other fields too. The IT sector (not all jobs in the sector, but most) have been spoiled in the sense that social and emotional skills haven't been a requirement for the last 2 decades at least, while they are normal expectations in literally every other field.
donjulioanejo@reddit
Sure, but time and place.
Example: you can learn to swim at your local pool. Or someone can throw you overboard in the middle of a storm, and you drown if you don't succeed.
Is swimming a basic life skill? Yes it is. But there's also a right way and the wrong way to learn it.
zhdapleeblue@reddit
This is such a good outlook. I'm deficient in this skill and get easily annoyed by other people's behavior, but your comment makes it sound like it's something I should work on. If there are any resources you could share that'd be great.
p1-o2@reddit
I learned by copying DestroyAllSoftware's style at first. Check out some of his free videos and you'll see what I mean.
That's the best example I know off-hand. The practice comes from pair programming sessions, mentoring juniors, and being on incident calls.
Though I think you could record yourself for practice too.
Emotional_Plate_1501@reddit
Second this. Feel free to share resources.
LittleLordFuckleroy1@reddit
Learning when to say no is arguably more important. Unless you’re presenting or actively brainstorming in a collaborative manner, having people gawk at you and slow you down while you’re trying to be useful is insanely inefficient.
It’s possible to get better at anything. Think hard about whether this skill is really worth it, or if you should just be more clear and direct.
alienangel2@reddit
Yeah I don't mind driving calls and usually end up having to even when I'm not on-call. But if someone is asking you to screenshare and you won't be able to focus while doing it, just say "No, I focus better without that, I'll get back to you when I have something to share".
Unless they are someone who can actually help you, you don't need to put on a show to keep them entertained while you're also the one doing the investigation. They can page someone else in to hold their hand if needed.
Frenzeski@reddit
I disagree with this, incidents are a high pressure situation and this is adding unnecessary stress.
pokeybill@reddit
I think its also perfectly fair to ask for 10-15 minutes to split off and report back with updates.
I will often set up a war room for engineers on the crew to do their thing while I (EM) liaison with the main group responding to the incident. That way incident response gets the updates they want (mostly) and engineers aren't stuck with a million eyes on the.
That being said, being able to execute under scrutiny will impress the people responsible for your career growth (presuming your roles have incident response written in to the descriptions)
kaladin_stormchest@reddit
Yup my general strategy is to get on these calls, get context from everyone and then just ask for 20mins or so to investigate the issue/check with someone in my team if they have more context and I'll be back.
80% of the work is done solo most of the times
Frenzeski@reddit
I don’t care about impressing people, i care about doing my job well
CandleTiger@reddit
Do you care about getting raises and promotions? That comes from impressing people.
Doing your job well is certainly correlated to impressing people, but it's absolutlely possible to do your job well for years while getting taken for granted and snubbed.
Frenzeski@reddit
Yeah I don’t want to work for people like that
pokeybill@reddit
I thinj doing your job well is what impresses people in this situation - whether you do it live on a call or after the fact, root cause analysis and postmortem discussions are part of the job (usually).
Frenzeski@reddit
Yes good communication is part of my job
adostes@reddit
You can get better by recording videos of you teaching or solving a leetcode and rewatching it.
TitusBjarni@reddit
Explaining things to my girlfriend has greatly improved my ability to explain.
vivec7@reddit
It is a very tricky thing. None of my thoughts really have words in general, and especially not while I'm working. I've always hated driving for this reason—I'm being asked to think about multiple things now, and in different ways, all while trying to do the work the way I usually would!
Which isn't to say it's a bad thing, I expect this is why rubber ducking can be a helpful tool.
But personally it feels on par with batting with a left-handed stance while being right-handed. It just feels unnatural, and while I can block a few basic deliveries, I'm not hitting any sixes.
pjc50@reddit
Yes, it's an entirely separate skill. It's rather like being a game streamer, there are some people who can hold an audience and carry on an entertaining conversation, sometimes in more than one language, while also fighting a boss.
You're the streamer, and chat are backseating you on the issue bossfight.
Shot_Marionberry5288@reddit
Indeed! It's also just like a lot of customer service jobs. I got really good at it from having to do patter while checking people out at farmers markets. Like i'd have to weigh out your carrots or count your beans or whatever, multiply out the price, and then manually add up all the prices and tell you it, while you're standing there in the hot sun or rain or whatever on your saturday morning with a line behind you. So I got really good at making small talk, lightly narrating my work, making little jokeyjokes, and doing mental math at the same time. It's been super helpful for interviewing, demos, and incidents because I'm able to sort of split screen my brain, and make lite narrative smalltalk while my big brain is solving the actual problem. But its definitely not the same skill as just doing my job silently by myself.
catch_dot_dot_dot@reddit
Streaming is actually so difficult and draining. Constantly talking, working/playing, and interacting with chat.
BusinessWatercrees58@reddit
This actually reminds me of the all star game recently. ESPN felt the urge to interview players while they played. Specifically, the pitcher and catcher. Skubal was barely talking. The catcher Raleigh took his ear piece out. Meanwhile Kershaw IIRC was pitching and chatting and a complete natural. Conversational and witty as if he wasn't even pitching against major leaguers. Fascinating how different people's minds operate.
stevemk14ebr2@reddit
Your thoughts definitely have words, you just don't have the skill to verbalize it yet.
shill_420@reddit
that's not true
stevemk14ebr2@reddit
So you think people just go around all day unable to articulate the concepts of why they're doing something?
shill_420@reddit
no, but not all my thoughts have words
new2bay@reddit
50-70% of people don't have an inner monologue.
stevemk14ebr2@reddit
This is not about a monolog. You are doing stuff for reasons, those reasons can be communicated
vivec7@reddit
I've had similar conversations elsewhere on the topic of internal monologues etc. I don't know if it's normal or not, but there's definitely a "translation layer" of sorts to get the thoughts into the right words.
It's why I prefer written comms, I tend to structure those comms from the outside in, so I will always be able to start a sentence better after I've gotten through most of it. Frustrating when trying to explain something, I have to fight the urge to start over when I get far enough in to have the right words to explain the start of it properly!
I've always been curious about the "thoughts have words" mentality though. Do bilingual people have two thoughts to a monolingual person's one? Would somebody absent language be unable to have thoughts?
To use another cricket reference, I recall while fielding hearing calls to throw to both ends, and a third call of "hit them". Now in hindsight I can find the right words to explain my thought process, but in that half a second between picking it up and throwing, my brain did not go:
"you've heard both ends called, the third call should be the tie breaker, _and the keeper is up to the stumps and if I need to hit them, it's probably not at the keeper's end because I'd throw it to him rather than go for a direct hot, so I should probably try to throw down the stumps at the bowler's end, and I know old mate is fielding at mid on so there's a fielder there in case it misses, so I should position my body this way and pick it up and let it rip"_
...and yet that's exactly what went through my mind in that moment. Those many words don't fit into that space of time.
Flashy-Bus1663@reddit
But I mean it isn't always appropriate to only use written communication.
Like on a prod support call being able to vocalize and share and express thoughts are important. It prevents mistakes from the operators fixing an issue, helps distribute work across available engineers, and allows stake holders the time to communicate to relevant parties the status of an issue.
U jumping on a call and magically fixes an issue with no words doesn't help me as a stake holders understand what happened and why. You might deliver a detailed follow up sure but u might not. I might have questions I need answered, the back and forth of written communication adds latency which is not always appropriate and written words can have multiple interpretations which can and do lead to confusion.
new2bay@reddit
Wait for the postmortem?
vivec7@reddit
No, and I'm certainly not saying that one should avoid other methods of communication, I'm just highlighting that I have a preference for one over the others. In cases where neither is clearly better, I will always opt for written.
And I'm not saying I can't just talk through problems. I do however prefer having a heads up on what the topic might be, because I'll go through and "pre-verbalise" a bunch of thoughts I've been having about the thing.
Verbal comms is just a thing that requires prep for me. I dislike having to go into meetings blind, or getting dragged into heavy discussions with no heads up.
I just won't be able to contribute as meaningfully, because half of my thoughts have all been hijacked to deal with communication itself.
I've worked with some devs in the past whose first instinct is to call me and try to solve the problem over the phone. I sucked it up for the most part, but there were definitely times where I just had to say "look mate, I need you to stop talking for a few minutes and let me think as if I were alone".
It hadn't been a blocker in my career so far. It's just a less enjoyable part of it, and one that I've had to work around.
No different to my tendency to walk around the house and do things every few minutes. I often solve problems while doing the dishes, for example. The absent-minded task helps. Can't do that on a screen share, but I manage when I'm forced into it.
IShitMyselfNow@reddit
Not everyone thinks in words. And a lot of people do think in words but tend to think more visually.
stevemk14ebr2@reddit
There's still words to communicate the ideas. That translating is hard and the skill, is the point.
luceri@reddit
This really is the foundation here, i am always the screen sharer on my scrum team, at least a couple of hours a day. You get used to talking through ideas and requesting the thoughts if others as necessary to move the team forward. It is much akin to voicing an inner monologue. The other half of it is the stress of being in the limelight and the systems of putting things in a visual presentable to others. I keep a dedicated standard ratio monitor specifically for screensharing, then an ultrawide for work that i never screenshare.
Skullclownlol@reddit
If this was true, business wouldn't hide the truth about everything.
sonofasonofason@reddit
I agree. In addition, learning to "sit in the backseat" is also a good skill. If someone is driving and they make a typo or accidentally click on the wrong thing, give them a few seconds to correct it themselves. Too many times I've seen the other person try to immediately correct when the driver already was on it. It adds so much unnecessary friction.
pokeybill@reddit
Its also very hard to learn without just doing it. In front of people. But, you are demoing your work to peers and during sprint reviews right? I do the same thing with incident postmortem - practice talking through the resolution with the crew and when you have to do it under pressure it will feel more natural.
Own_Candidate9553@reddit
Agreed.
A practical suggestion that helps me: have a multi - screen setup, even if just a laptop monitor plus one external monitor. Designate one screen for "presenting" where you can have a dashboard up or whatever and drive. Then your chats, investigation terminals, other sites are hidden.
Then when you're about to "do something" like run commands in the terminal, or click buttons in the console, etc, you can drag that into the screen you're presenting.
I know it sounds obvious, but I find it less stressful to have it split up like this so I'm not worried about every single character I'm typing or every chat I'm having with people that are helping.
Morel_@reddit
having to talking while thinking and doing "recon" is hard. you are processing many data points at the same time.
Bicykwow@reddit
I'm sorry, but no. Absolutely inappropriate to require screen sharing while debugging an issue.
Ok_Chemist_3576@reddit
Non-technical leading technical is all that's wrong in our societies. As oppossed to societies (Asia, for example) where engineers are in charge and actual meritocracy is the norm.
Meritocracy as in, a qualified subject matter expert to that specific field. Not meritocracy as in, the I-lobbied-this fake-it-till-you-make-it MBA.
Because of this engineering work is not engineering anymore. Recruiting is not based on proving technical knowledge, but a buzzword matching mysthical game.
Valuable_Ad9554@reddit
If it's adversely affecting overall time to close the incident, raise it at the post incident review. Get chatgpt to give you a diplomatic corpo friendly way of saying "there's too many fucking people on these calls and their distractions mean the client is suffering for longer". If it's not, just gotta suck it up.
donjulioanejo@reddit
Yep. Also pretty easy to just shut them all up. "Hey, I can either fix the issue, or explain what's going on."
Realistically, one person should be the incident commander (doesn't matter if technical or not). That person's job is to coordinate the incident between people actually fixing it, and people who all want to be in the loop because they're getting yelled at by customers or execs.
Non-technical people shouldn't be in the technical side of the call precisely because it's distracting. Even if they're not annoying the OP, they're still talking about stuff like how to word the outage notice or which customers to reach out to first.
It's a) annoying and distracting, and b) prevents tech people from talking about tech stuff like, "hey did you see this spike in async jobs 3 minutes before the incident, maybe our redis instance went OOM?"
MyUsrNameWasTaken@reddit
Out of Mana?
Wonderful-Habit-139@reddit
Starts with Mem and ends with ory
Potato-Engineer@reddit
Memdisestablismentarianismory?
VictoryMotel@reddit
They want to see what you're doing. It's up to you to smoothly set boundaries for what you can reply to and talk about while working. It's a skill that takes time to develop.
NoPressure3399@reddit
Get a third screen and write some bash macros with sleep in between and slow down output time. Generate some matrix graphics and some tables with buzzword spaghetti 👍
deathhead_68@reddit
'There's too many people on this call for us to really focus on debugging the issue, I think x y and z teams are the key people we need to look at this, so I think let's break off into a separate call and update you when necessary'
KallistiTMP@reddit
This is why Google SRE process has a dedicated "Incident Comms Manager" role. Their job is to relay updates from the war room and keep the anxious suits out.
ilyas-inthe-cloud@reddit
you are absolutely not the only one. the worst version of this is when someone starts backseat debugging over your shoulder. had a director once ask me to click on things while he narrated what he thought i should be looking at. on a sev1. at 2am. what actually worked for me was establishing an incident protocol where one person drives and one person communicates. the driver does not share their screen. the communicator gives updates to the bridge every 5 minutes. if leadership wants visibility they get status from the communicator not by watching me grep through logs. took a couple of incidents to train people on it but once they saw the resolution times drop they stopped asking for screenshares
serial_crusher@reddit
It's nice to have one person on the team (usually a team lead or manager) who's not directly involved in the firefight be the point of contact for the outside stakeholders. They usually just want to be reassured that something is happening, so if somebody they trust says "yeah, Phil's on it. Here's the solution, here's how long we're expecting it to take. Let's stay out of his way", they'll be fine.
ephemeral_resource@reddit
I think that they think it will help their anxiety to see what's being done as if they can identify any steps as helpful or not.
My leadership I consider top tier in pretty much every aspect. They still asked me to screen share in an incident. It didn't help me but they did well to try not to distract realizing it wasn't helping much. They're smart folks though and surprise me often with good ideas. Anyways, I don't blame them for trying and honestly I wouldn't discourage a screen sharing session like it in the future. We're all in this together just limit breaking the fixer's focus.
Unstable-Infusion@reddit
Far worse is "claude says..." I'm even getting this from very senior engineers who should know better. It's very much not helpful to tell me what claude says when you have no idea if it's correct or not. Especially when i already told you how i am remediating the problem. It makes me unspeakably angry when someone with less domain knowledge than me, who technically outranks me, tries to override my actions because Claude told them to. It makes formerly smart people into tragic has-beens. I don't know where all this leads but the brain rot is really happening.
Kerlyle@reddit
I cannot wait until the day that the vibe coders have to deal with an incident call they caused, and watch their face go white as they have no idea what they’re doing.
Unstable-Infusion@reddit
But they don't. They let people like you and me fix jt because we take pride in our work and we can't not fix something if we know how.
cobalt8@reddit
For the greater good you need to suppress that instinct. These people need to be exposed for what they are.
new2bay@reddit
The hell we can't. They built it, they support it.
forbiddenknowledg3@reddit
My manager (non-technical) sounds like a human form of GPT. He can't make a coherent point anymore. I feel bad for the guy, he needs to see a doctor.
l_m_b@reddit
In one of the moments I'm not proud of, I once hung up on a project manager who was pinging me for updates every 5 minutes (and thus preventing me from finally getting the one hour I needed to actually fix the bug).
They were very annoyed at me. But the product shipped.
mikkolukas@reddit
Answer: I am on the issue. I work most effectively uninterrupted.
(i know it is not how it works out if it is a shit leader)
NobodysFavorite@reddit
One of the reasons I'm a big fan of multiple screens is I can choose which one to share over a call.
SteveMacAwesome@reddit
I find people tune out pretty fast as soon as you have a terminal on the screen. If you’re asked to share your screen, I say give them what they want and continue work as usual. If people keep interrupting you, just point out that were you all in the same office you’d also not expect 100 people to be standing around your desk asking questions.
Looz-Ashae@reddit
micromanagement is a bad indicator of their leadership qualities
superdurszlak@reddit
Always have one person sitting on a call and handling the omnipresent and omninosey managers, and another actually working on the issue in the background. Always.
Like you, I cannot work under this kind of micromanaging. I get instant short circuit and diarrhea at the same time.
wobblydramallama@reddit
what's the problem with setting boundaries, saying no and that you get back with info?
gkreddita@reddit
You can ask them to take on the commander or scribe role and they won’t and they’ll leave you alone.
Brutus5000@reddit
Sorry folks I am working on highly critical production systems, where any mistake could make the situation even worse. To avoid such mistake I have to achieve maximum concentration and therefore In not available for continuous calls. I'll share updates every 2 hours.
SignoreBanana@reddit
Why are non technical leaders in your incident calls? We kick ours out.
kitsunde@reddit
Really bizarre comments on this post. Just say no, but you or someone else’s running comms need to pro-actively communicate.
I’m looking into it, I will provide the next update in 15 minutes.
I’m still looking into it, nothing new to update, I will provide another update in 15 minutes.
The root cause has been identified, a change is going in to resolve it. I will provide the next update in 30 minutes.
This is all anyone really needs, if you can’t put boundaries on people asking for things you find unreasonable and is interfering with your work then that’s entirely on you.
I don’t know what your reporting line looks like, but it’s pretty odd that a PM is in any way in charge of you during an incident. It’s not their fault for asking for something that you’re agreeable to.
lris-ran@reddit
hi
10khours@reddit
Have you tried saying "is it ok if I drop off to investgate, will post updates in the slack thread".
zayelion@reddit
Google micromanagement
Its a show of incompetence. They dont have the trust tondelegate the task, or the skill to know what to ask. All they can do is create social pressures to ensure that you are somehow engaged by staring at you.
augburto@reddit
Depending on severity of an incident it makes sense to hop on a call to just expedite communication.
Screen sharing or the actual fixing should be left to the engineers how they see fit. But just being honest, leaders are there to ask questions/updates because it’s on them to make sure someone is on top of it.
If you have solid engineers who are good about communicating you don’t have to micromanage as much. But IMO your leaders are doing their job if they don’t think action items or who is doing what is clear
Chocolate_Pickle@reddit
I've screen-shared with technical people while triaging an incident.
I can't say I've ever been asked by non-technical people.
But this does give me a vibe that these people feel like they don't have enough certainty or enough information about the situation. So it could be a (lack of) communication problem.
What are you saying in the lead-up?
notWithoutMyCabbages@reddit
Ugh ... They think they're helping
AdUnlucky9870@reddit
honestly the move is to just narrate what you're doing out loud while you work. they stop asking questions when they hear you talking through it already. still annoying but way better than the constant "what are you looking at now"
Torch99999@reddit
I'm older than screen sharing, but I do similar.
When I'm on a call doing stuff, I'll say what I'm doing out loud as I do it. Executive leadership may not understand, they generally don't, but by doing the work out loud gives them confidence that something is actually happening and we're not just twiddling our thumbs. Makes leadership less nervous, and ultimately they're the guys who sign my paycheck so I want them happy.
MapLarge614@reddit
I remember incident rooms from the old days, including a large desk in the middle and glass-walled galleries for viewers and experts on the side. Screen-shares are a piece of cake.
Categorically_@reddit
Once the non technical people ask questions about what you are doing just start teaching a la Socratic Method. Then feign ignorance when they push back and ask why what their intention was when asking you what you are doing.
snakebitin22@reddit
I just put my screen up and start giving my play-by-play whenever I join a break fix call. I already know someone is going to ask me to share, so I just do it.
It’s a great skill to know how to explain what you’re doing as you go in simple terms. It makes incident commanders and PMs happy. It makes your manager look good.
Making your manager look good makes you look good.
It’s all part of the sys engineering game.
Emotional_Plate_1501@reddit
Pls share more on sys engineering game.
snakebitin22@reddit
It’s actually pretty straightforward.
Be competent. Know what you know and what you don’t. Admit when you don’t know. Admit when you’re wrong. Listen more than you speak.
Good luck out there!
MrMichaelJames@reddit
Yup exactly this, learn to play the game and day to day is much easier.
klowny@reddit
I tell my engineers to drop and join an engineers direct responders only call/channel and give me updates as necessary over Slack, and I'll dance for the panicking peanut gallery to keep them off their backs until they get bored of me repeating the same answers. I'll even screenshare some pretty dashboards so the visual learners can be dazzled.
graduallydecember@reddit
Panicking peanut gallery is a great phrase.
pokeybill@reddit
It is also instructional for those who can keep up with what you are doing. I (EM) always have my interns and junior engineers shadow on incident response because it is something you can't really learn without just doing it.
HylanderUS@reddit
Damn, I didn't even know what you guys were talking about, I never had to share my screen with anyone during an emergency fix. Do they just watch you code or read log files? How is that supposed to be helpful?
Elctsuptb@reddit
Just switch to an 8k monitor, the text will look so small on everyone else's screen that they won't be able to read it
phatdoof@reddit
Goood one
flerchin@reddit
If you're not speaking roughly every 20s on an Inc call, someone will. So sharing your screen is often the way to allow for fewer audible update queries. Usually I get a helper to share a dashboard of the key metric I'm watching so I can focus on Return To Service. If someone asks you to do something that will slow you down, tell them "that will interfere with my ability to return to service faster."
Frenzeski@reddit
This is such a silly way to manage an incident. Updates should be every 15-30 minutes not every 20s
Flashy-Bus1663@reddit
Doesn't this kind of depend on the incident, if the incident is in a state where people can wait 15 to 30 minutes, I am not certain you need to actually be on a call for that. But if production is fully down and you are actively losing money while your users are unable to be in the system I do think it's appropriate to be asking for updates frequently. 20 seconds is likely a made-up number. More like every few minutes. Someone on this call will say something.
Frenzeski@reddit
IMO no, I’ve worked on many Severity 1 incidents and 15 minutes is the minimum time between updates. It can be shorter if something happens, but it’s rare for anything meaningful enough to happen.
The problem is when people aren’t able to yield control of the situation and let the subject matter experts do their job, they get in the way and slow things down
RadioFieldCorner@reddit (OP)
I speak when I see something or notice something worth mentioning, some people on these calls literally cannot handle silence for more than 30 seconds though.
omgimdaddy@reddit
Then you need to firmly state you cannot both fix and explain the issue at the same time. Do they want it fixed or explained first? I’ll be they answer fixed first
alinroc@reddit
I vividly remember an incident 25 years ago where I was standing at the rack console (remote access/management on these Compaq Windows servers was iffy) with the CIO at one elbow and a Sr. VP at the other and they were expecting me to narrate what I was doing, why I was doing it, and what caused the problem - while I was still in the middle of diagnosis & fixing!
I was still one of the more junior members of the team at the time, but after the dust settled I pushed for major changes in how incidents are managed - and got my wish.
klowny@reddit
I tell my engineers to drop and join an engineers direct responders only call and give me updates as necessary over Slack, and I'll dance for the panicking peanut gallery to keep them off their backs.
pjc50@reddit
Yes. You have to manage two things: the technical problem, and the emotions of the people affected by it. It's basically like trying to repair the favorite toy of a crying child.
(Sensible orgs split the calls up so that the emotional crisis can be handled by a different person)
tomqmasters@reddit
You are allowed to say no to things.
LittleLordFuckleroy1@reddit
Idk. At this point in my career I’m fortunate enough to just refuse. Not even in a mean way, just like “uh yeah sorry, I literally can’t think while presenting. So no. Or, I can, but I’m not going to be useful at all. Let’s just figure out tasks and I can get back to you with a summary.”
jamesdixson3@reddit
it depends on the situation frankly .. it can be good or bad.
I have been on many incidents over my career, both as the guy fixing it and the executive responsible. I always prefer sharing screens with the group on the call. often with several people searching for the problem or solution and switching screens between us as we find a clue or need more eyes for interpretation.
It is ultimately about the quality of the incident lead; a strong incident lead will ask helpful questions of the team and "drive" the investigation and help everyone involved in the investigation and resolution move through it. It is also good for less experienced staff to learn how to handle an incident, particularly in a high stress situation.
onefutui2e@reddit
If there's a production incident that's bad enough, we usually have an incident commander who can realistically be anyone, but ideally someone with context of the issue. They don't have to be one of the ones actively working on it; in fact, it's better that they're not.
Their primary role is to provide timely updates to stakeholders as the incident is being worked on, pull in resources as needed, and dismiss resources no longer needed. They also communicate status summaries at defined intervals. People not involved should only be talking to them. They in turn with relay any relevant information to the engineers. Done well, it frees up the team to focus their time and effort to actually figuring out the problem and fixing it because all communication goes through the incident commander and they're not being interrupted.
For long running or critical issues, we usually carve out a separate, temporary Slack channel for this where all communication comes in. The engineers huddle, and the incident commander, also in the huddle, keeps an eye on the channel to see if there's any new information while also posting updates there. Anyone is allowed and even encouraged to join, but if you're being disruptive the incident commander can dismiss you.
Note that the incident commander is empowered to be an asshole during this time. I remember one of time I had to be one and I told a VP to hop off the call (in private) because he was intimidating the engineers who weren't comfortable with him seeing their screen shares. He laughed and took it in stride.
30thnight@reddit
You can usually clear the non-technical crowd by letting people know upfront
Outside of that I’d suggest
keeping a browser profile meant specifically for presentations
run a second monitor to use as your private scratch pad
keep a checklist visible on the shared screen of your hypothesis
not being afraid to say you need to search something up or use AI
running something like this for your secrets
alinroc@reddit
See also: The RACI Matrix
StevenJOwens@reddit
My first career job, I had the senior IT guy at my desk, helping me with something, when the network went down. So he just got straight to work fixing it, on my workstation.
Somebody walked around the corner and said, "Hey, the network's down."
He said, "Yeah, I know, I'm working on it now."
Somebody else walked around the corner and said, "You know the network's down?"
He said, "Yeah, I know, I'm working on it now."
A third person walked around the corner. Before they could say anything, I told them "Yeah, he knows the network is down, he's working on it now."
Then I looked around the corner, and found five more people literally waiting in line to tell him the network was down.
I learned an important lesson that day...
alinroc@reddit
Peter Gibbons: And here's something else, Bob: I have eight different bosses right now.
Bob Slydell: I beg your pardon?
Peter Gibbons: Eight bosses.
Bob Slydell: Eight?
Peter Gibbons: Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it.
opideron@reddit
They're all feeling the same thing you feel when your power goes out and you're impatiently waiting for it to come back on. Worse, poop rolls downhill. These people hovering over you have people hovering over them, or at the very least asking/complaining why things are broken and when will they start working again.
That said, I've not had anyone ask to see my screen for proof that I'm working. What I run into is that I'm working on it, trying to set up an environment to debug and they keep on talking making it remarkably difficult for me to keep focus and keep the context in my head. So a simple thing I could do in 5-10 minutes takes me half an hour because they all want to talk with me as I tell them I'm in the middle of hunting down the problem.
drachs1978@reddit
Handling people watching your screen share while still being focused on your work is a skill you can develop in yourself. Try to stay calm and relaxed, first and foremost. Emotionally let go of any need to put on a show or cater to your audience. Learn some noncommittal phrases like, "I'm going to check the AWS stats for anomalies" you can udder while your review things.
Most importantly, give yourself permission to slow down. It takes the time it's going to take. If someone important breaks in and starts asking questions you need to answer, say something like, "Let me just take a quick note of what I'm investigating right now so I can give you my full attention". Write down your train of thought, give that person your full attention for a few minutes, then go back to work.
You can adapt to this. You can practice by doing some pair troubleshoot or debug sessions during low pressure issues.
Talk to your manager about needing to develop your skills here.
Dave4lexKing@reddit
Am I the only person that couldn’t care less? Fortunately I don’t have to go through much a performance, but I just don’t understand the reactions here. You’d think some of the commenters were subject to medieval torture.
If people wanted to watch my screen in stoney silence and be bored to death, all the power to them.
alinroc@reddit
That's the problem - they aren't silent. The people responding here have the peanut gallery throwing 5 questions per minute at them while they're trying to resolve problems.
Cool_As_Your_Dad@reddit
I HATE screen sharing and working. It's like my hamster just dies... can't find buttons etc.
alinroc@reddit
There's a reason people who present at conferences always say "don't type in live demos."
zirouk@reddit
I screen share during incidents because others can spot things I miss whilst I’m focussing on whatever I’m focussing on. It also makes my life easier because I don’t need to be personally and solely responsible for surfacing everything relevant to the incident that appeared on my screen, others can help point those things out. I’m imperfect, I’m working under pressure, I need help.
I used to hate screen sharing, but I overcame that early in my career, and life has gotten much better since.
You’re going to hate me for saying this, but screen sharing anxiety is the only explanation for what you’re describing. You’re anxious because you think you’re going to be judged. That anxiety is really real, and it’s definitely worth working on. If you overcame it, you’d be able to share your screen more freely and it’d help make you much more effective at your job, because you’d be able to collaborate and share cognitive load with others. You’d be much more professional, and it’d help you communicate with others more effectively. Overcoming this anxiety would literally level up your career.
As for practical advice: you need to sit down and honestly answer to yourself, why you’re so uncomfortable sharing your screen. When you’ve done that honestly, the answer will sound something like “I am afraid of being judged and I am incredibly uncomfortable with the idea of looking stupid, incompetent or worse in front of others” - until it sounds like that, your fragile ego is succeeding in making excuses to defend itself. You need to surrender all defences. All the walls, all the towers that your ego has erected, you need to let fall. Surrender. Hands up. You have been caught. You are a fraud. You’re not really that good. You don’t even know what you’re doing half the time but it kinda looks like something good? The truth is, nobody really knows what they’re doing. We’re all just kinda working it out as we go. But some people pretend they know what they’re doing more than others. But the worst thing we can do is pretend we know what we’re doing because we end up having something to lose, and the persona needs to hide and keep up the charade, all the freaking time and it’s exhausting. That persona is the thing that is afraid of being caught. So, surrender that persona. Give it up. Allow yourself to be vulnerable. When you are vulnerable, you are open to the elements. You’re naked, everyone can see everything. And you’ve got nothing to be ashamed of. We’re all the same. It’s from this position, that sharing your screen shouldn’t feel so scary. We’re all just thicky-thicky-dumb-dumbs trying to help each other out.
When someone points out a mistake you’ve made while sharing your screen, just tell yourself “of course I didn’t see it, I don’t really know what I’m doing, and I’m working under pressure, and I’m really grateful to have this other person who doesn’t know what they’re doing looking over my shoulder trying to help me”.
And if they try to make you feel bad, or act superior, that’s ON THEM. That’s them feeding their ugly ego, isn’t that a shame? They’re making the mistake you used to make.
Tl;dr: give up your castle, let your ego fall. Screen sharing is scary, when you have something to lose. Lose it all, and you’ve got nothing to lose, and screen sharing suddenly becomes less of an ordeal.
PS: if you could use some coaching on this, drop me a DM (it’s free, I just enjoy encouraging and empowering people with the skills they need to level up their careers and, ultimately, their lives)
AdvancedMeringue7846@reddit
Where as I was on a incident call listening to my cto manually copying applications, config and installing various framework onto the DR server because it was never setup properly.
I'd much rather a non technical cto than a developer pretending to be a cto
Able_Champion_6478@reddit
have you tried pushing back on sharing screens?
kerrizor@reddit
Sounds like an opportunity to step up and propose some Incident Management policies and training.
darkstar3333@reddit
"If I was surgeon and you had two options, what would you choose?"
1) Put you out and focus on the surgery as quickly as possible. 2) Keep you awake so I can answer your questions.
A stream of updates is fine.
false79@reddit
I think you need accept the fact the reason why everyone is on the call completely dwarfs how you are feeling in the call itself.
It sucks during the first one, especially if it was your commit. But any veteran developer has been here before.
Everyone on the call, technical or not, is there to help. That cannot be understated. Non-tech people (or tech people who not directly related to the issue) can be the extra eyes and ears when you are so laser focused on just trying to identifying the problem. They can also be the ones to QA to confirm the original issue is solved and it hasn't introduced any regression issues.
Serious-Ebb-5787@reddit
i had to explain my every click once, it was exhausting
jl2352@reddit
It comes down to trust, and we as people find trust to be very difficult when it’s over something out of our control. The incident is out of their control, it’s important, and they have to trust you. That’s hard.
Good leaders I’ve had I could literally tell them, point blank, to leave me alone to get on with it. They would. That includes some excellent non-technical leaders.
The absolute worst was a CTO. Who during a major incident, brought in a requirement we had to send our PRs to the department VPs for review. Those involved in the codebase were banned from approving a fix. This is at a small 100 people startup. This led to multi-day arguments (actual arguments) to get things shipped.
exomyth@reddit
Gives them something to look at instead of your faces
musty_mage@reddit
Because they like to pretend that they are actively contributing to the process. After all, they will brag about 'helping' in any case.
campbellm@reddit
AI will never replace the people who are, or are able to, pay for it.
musty_mage@reddit
No employee of a company pays for anything personally.
campbellm@reddit
That's why they're the first targets to be replaced.
musty_mage@reddit
Hyup. And that's why AI has to result in massive redistribution of wealth for any semblance of a democratic society to survive
campbellm@reddit
Oh, it'll do that (redistribution) for sure, just not in the direction you're (or I'm) hoping for.
musty_mage@reddit
We have (collectively) been pretty adept at simping for the rich. True that.
Instance9279@reddit
Do you think AI will replace the non technical people? God I hope it does.
musty_mage@reddit
I mean they are the ones whose output is easiest to replace with an LLM. Generally speaking it doesn't matter to the company if the LLM hallucinates a bit while producing their output. They already mostly have very little idea what they are talking about.
bilcox@reddit
The big difference is that their output can't immediately be verified by the computer, like the app working again. That's why we're singled out in the AI Boom.
Solrax@reddit
LOL good point. I've already had plenty of POs and PMs hallucinating about deadlines, who cares where the hallucinations come from?
musty_mage@reddit
Slop is slop. Doesn't matter who or what produced it
roynoise@reddit
Your first point is spot on. However, to your second point, regrettably, they are the target audience for AI companies because they want to replace us with LLMs. Not the other way around.
Though you are correct, they should be the easiest targets for replacement/redundancy. However, they are the ones with the phd in bs'ing. They'll wave their hands and keep their nice incomes while we are turned into lines on a spreadsheet.
musty_mage@reddit
Yeah and then those companies will fail. Because there is no way to quarantee that an LLM will be correct. And in technology, being correct actually matters. Usually a lot.
In non-technical work being even semi-consistently correct has never mattered, because the people doing it have never been capable of that either.
army_of_ducks_ATTACK@reddit
I would like to know how you define “technical”, because I can think of at least a few areas that aren’t compsci/cyber/software “technical” but you fucking better be correct or you’re absolutely going to be hosed.
musty_mage@reddit
I mean obviously financial/statistical/data also needs to be correct. Which is what we've already seen when people start vibe coding pipelines.
I'd maybe define anything non-technical as a role where you don't actually personally verify the facts that you present as your own. I.e. anything where you don't read the code, didn't write (or understand) the statistical method, etc. A lot of those roles are easily replaced by AI
03263@reddit
I would just share my screen and not do any work, just participate in the call. If they ask, I'll get back to this important issue when the call is compulete.
YetMoreSpaceDust@reddit
I forget everything I ever knew the minute somebody else starts looking at my screen.
tlann@reddit
The thing I hate about this is if you have to explain what you are doing, you aren't working on the problem. This is literally causing the issue to take longer to be remediated.
Far-Employ4059@reddit
reminds me of last weekend's adventure in the woods
Frenzeski@reddit
In an incident management there is typically a role of incident commander. This person out ranks everyone and is the decision maker, when I do this role my job is to protect engineers from this kind of request. The answer is no. Do you have an incident management process?
Proud_Duty8793@reddit
sounds like they're micromanaging from the comfort of their desk
redfluor@reddit
Ultimately, they're also held responsible when things go wrong, but they're in a situation where they have little actual control over the resolution, which is (understandably) an anxiety-inducing situation.
Being involved, asking questions, and watching the resolution unfold gives them a sense of control, and it helps with the anxiety.
mehtheswede@reddit
Because they are managers and can’t do what you do. I say this sincerely after 15 years in this industry.
Most are reformed agile coaches at best
engineered_academic@reddit
You want to invoke ICS where possible and designste someon who isn't the person running the incident as press officer that handles all updates between stakeholders and customers. This frees you up to focus your efforts on putting out the fire and collaborating with technical stakeholders.
Ready-Product@reddit
To be fair it depends on person, I am happy to share screen. Once I was working with a client, he was rejecting everyone after one day of work with him. Later I was assigned, I was given some work on probability. So imagine like tossing 2 coins, and he wants and probability can be changed. So I did the code, but then client asked to share the code and gave an array. And he told use the array as input run the code and show the output so that the outcome is probability he wants. Although I have done debugging and other stuff sharing the screen. This out of blue thing really caught me. But It was manageable. Nowadays when it is hybrid I feel I want someone to do peer coding.
StevenJOwens@reddit
https://www.youtube.com/watch?v=uRGljemfwUE
farzad_meow@reddit
people don’t like silence. so being vocal keeps everyone off your back
Less_Try7048@reddit
reminds me of that episode from black mirror
Professional_Mix2418@reddit
Mostly I can say that if they were allowed access to the data then they’d have it. And that I am not risking an information security incident by sharing my screen. But we have great wel rehearsed command lines and my commander quickly follows up that all those without appropriate clearance must leave.
berndverst@reddit
Some non technical people watching may be responsible for customer communications - it's better to answer their questions than having to deal with that yourself :)
DanteIsBack@reddit
I always share my screen in those situations, I got used to it, but the trick is to always have two monitors so that you can always search stuff or do some other stuff on the monitor that you aren't showing.
Delta1262@reddit
When this happens, I tend to share for a moment, and pause to ask that someone in specific make a bug ticket for this incident. When they say yes, I’ll ask if they can share their screen so “the team” can review the ticket as it’s being created so we don’t miss any details.
Generally, I’ll ask the same person who asked me to share my screen.
Advanced_Slice_4135@reddit
Just say “sorry I need to lock in and focus on this issue and will give you a report after the problem is solved, unless you want me to potentially introduce more problems and/or make this take 10 times as long to fix
andrewharkins77@reddit
They probably have clients or their boss breathing down their necks. You need to stand firm and make it clear you are still investigating.
-no_aura-@reddit
I once had a PM reach out to another internal product teams leader during an incident triage because of something he saw on my local while I was screen sharing and validating the fix we were about to push up. Had to stop what we were doing, explain that this was my local db and nothing was wrong with production data, and then ask why he was even here in the first place since all he did was convolute things and make the whole process take longer.
Drives me crazy.
BoBoBearDev@reddit
Hmmm.... Never heard of such thing. It would make sense if this is an discussion on what the defect is or a demo to show the problem is fixed. But since you are just debugging, it is way too early. I have one manager trying to learn and shadow for a few hours, but that's not to discuss thr ticket, it was just learning the overall process. Never seen your case.
okayifimust@reddit
Skill issue.
If you regularly find yourself in situations where you have to explain what you're doing as you're doing it - practice. (Or, perhaps, question the need for the zoom meeting. If you have to have 10 people on the line, they should be able to see what's going on. But do you need them?)
Practice. Best way to avoid question is to make everyone understands what you're doing. If they need to ask, you made a mistake in your presentation just prior to the question.
Like you said: What the fuck else do they think you would be doing, and why would you lie about that? If worded like that, it makes it seem like they don't trust you to do the job without being watched. How they want to check your work if they don't understand might have some academic question; but you have a much bigger issue.
Skill issue: Make sure the Mr Beast video runs on a different screen, and wear headphones so your mic doesn't pick up the audio from YouTube.
Seriously: There are situations where it makes sense for you to work an issue in a conference with 10 people. Primarily, when you need those 10 people to feed you information or support you in some other way. But if they are just there to micro manage you that is - at best - a procedural problem. More likely, one of management, trust and respect.
writebadcode@reddit
There should be separate roles assigned for the tech lead who is primarily working on resolution and another engineer who is primarily focused on communication. Ideally there would also be an incident manager who keeps this kind of chatter to a minimum.
That said, working on an incident while sharing your screen is a good skill to cultivate. I think it can really help with collaboration and communication in general and is good for your career.
jonmitz@reddit
because they want everyone on the call on the same people so the number of repeated questions is reduced. they are doing their job.
phoenix823@reddit
This is a communication issue. You should be comfortable sharing your screen so people can observe. Other people should shut up and let you do your job and only ask questions when absolutely necessary. When I was a junior it would help a lot to watch how other people approached problems.
princess_Saigena@reddit
Same here, I seriously have no idea why, 1. They are not technical enough to know what the heck is going on, 2. Everybody knows that nothing is straight forward and you need time to actually investigate.
I had a manager that used to do that and then he maybe like try to read something on the screen and say what about this, what about that. You then end up spending half the time explaining things and telling them no, then maybe once in a blue moon he would have gotten lucky and his one ‘what about this’ was actually right or helpful then he’d go on telling everyone how helpful he was and that what we do isn’t rocket science