Remote work requires communicating more, but less frequently
ben.balter.com
ben.balter.com
This whole thing seems to be what people struggle with about remote work. Communication is way, way more important, and being an effective communicator doubly so. There's nobody's desk to go stop by, so noting things down and making sure we understand each-other is vital to accomplishing anything.
Reading through old mailing-lists (and even older e-mails from the same company, but from seven years ago) shows a markedly different communication style - you could pretty much take the last two e-mails in a thread and paste them into a memo that would neatly encompass all of the scope.
Not so today--there's a constant chattering of people who just can't prioritise or discuss more than a couple of topics in tow.
I too have colleagues who reflexively ask for a meeting in response to any email longer than a few lines, even though the issue is clearly communicated and obviously requires someone to read it and build a proper response. The ease with which we can all "jump on a call" has contributed to this. Yes, of course we've all seen email chains which go back and forth without progress but that's not a reason to assume every message will end up there.
I hate that term and concept "jump on a call". I often find that people don't prepare enough before the call, which defeats the purpose of the call.
Oh, yes. So much this. Except, I think it's fair to say it's managers and bosses who have this tendency, not so much colleagues.
I have spent many of these calls effectively just reading what I wrote in the email in the first place. Complete waste of my time.
The loss of focus definitely accelerated with the rise of chat.
In my view, it was GMail with its top-posting proportional-font-only interface that killed email and mailing lists.
You forgot the part where the call is scheduled for next week even though today is Wednesday. And any attempt to discuss further in text is met with "let's leave that for the call".
Chat/email is solely for semi-live discussions ("is this a bug ? how do you do X ? where's the doc ?") and decision making ("can we release this feature this friday ?")
Anything else that requires bullet points, graphs and/or more than 5 min of thinking goes into a Notion page where the team comments and argues the topic. Sometimes the Notion page will even start with Slack snippets for context, as the topic just happened to require a more constructed discussion. The magic of it is that people switch mode and write complete, coherent arguments if they're on a page, vs small the chatty style they have on Slack.
People use the same thread to speak about unrelated to the thread topics which makes those communications impossible to find.
I’ve introduced and use basecamp with my team. It’s genius is in collecting things into projects, and in intentionally resisting complexity. Frictionless flowing focused communication - with everything in its right place, providing just enough information in activity feeds etc.
It’s for high trust teams who are trying to find all needed info to get their work done, and delivers.
Truly signal over noise.
I am a total fanboy after trying a bunch of systems trying to be too clever, track time, create Gantt charts etc.
And the first two of those are largely due to the uncontrolled effects of the Internet, i.e. the web and social media, on people, of course.
Edit: wording
Hopping on a quick 5min zoom is frictionless at home. Walking aaaaalll the way over to someone’s desk and disrupting the entire office with your conversation, or god forbid finding a free conference room, is way harder. So you smear the meeting on slack across a 1 hour back-and-forth pingpong instead of doing a quick 5min sync.
https://www.bbc.com/worklife/article/20180718-open-offices-m...
Private offices solve this problem of course. Wfh is the easiest way to get that.
I'm finding this to be one of the key drawbacks of remote work - some decisions require cross team trust and I've yet to see anything besides more frequent ad-hoc conversations that builds it. The problem is that the most trust building conversations tend to be "off-topic" conversations that just don't happen organically in a remote environment. I as an individual can try and make these happen but I can't force the org to do so.
If anyone feels like they have a solution I'd love to hear it (we're already doing quarterly off-sites, it's not enough)
It may FEEL like it because those people chatting get energy from it. But it doesn't. If you need energy from people like this it's 100% a good idea. Go nuts. Personally I think people over index on this because they have no idea how to structure async team comms.
– Videos – Longform content – Team agreements to respond to things async without x-hours – Team collaboration spaces – Good sprint ceremonies like refinement – Team QA-type exercises
Ad hoc conversations also contribute immensely to what I call "comms debt". The jolt of energy you get from water cooler talk last 3 minutes, and excluded anyone not in direct proximity. If the best idea was in the head of somebody 3 rooms away you have no way of knowing it. Add dozens of these micro-interactions throughout the day and it's a recipe for comms breakdown and kliqish behaviour.
I see this a lot in User Research. Let's "get out of the building" and talk to people. A good idea in practice, but without actual goals or hypothesis product leaders mistake the first 5 opinions they collected as fact — often cherry picking sound bytes that fit right in with their own biases (and I've seen this A LOT in older leaders). This is mistaken as research. But they love it because it has that face to face energy. The feeling makes it right, regardless of the evidence.
Trust in a team is based on good communication — and an agreement on what you expect from it. If someone posts a video to Slack do people respond? Do you have ceremonies to build togetherness and understanding? All of these things are somewhat easier when you just have to deal with Zoom logistics.
Anyone who has to clean up and index the deluge of Design Sprint whiteboard stickies knows what I'm talking about. Put that shit in Miro, thanks.
I need to build trust between between 6 EMs spread over three different directors and 2 vps + some very senior engineers. I need to do this so that we can solve one of the larger problems the business is facing. Most of these people have no good reason to talk to each other (or me) regularly. Without trust, one or more of these people will likely torpedo the proposal in order to avoid tying themselves to other teams and people they don't know.
Pre-covid the solution to this problem was (mostly) chatting over lunch. You'd get the right people talking, seed the idea, and build up to a proposal that everyone could agree to drive forward. IME this whole style of consensus building is dead in a remote world because async communication is too low bandwidth for trust building.
This makes it really hard to take good organizational bets, you have to wait till you have a mountain of data and customer feedback before you can sell big projects. The quality of the company's output really noticeably declines from this.
Except that Pre-Covid, those [6 EMs spread over three different directors and 2 vps + some very senior engineers] were already probably not at the same office.
They were spread across three states, two countries, and one was a consultant from India.
This was my experience with any company bigger than about 40 people, anyways.
If you are not doing deep work, it's no biggie.
I also would schedule 1on1 meetings to 'catch-up' (not too many of them, but ...)
Don't get me wrong, meeting some of these people in person is great, but I have several great relationships at work where we've never met in person
Your reward for being willing is exactly this spontaneity that is missing from remote work. I have seen it work again and again...!
I have come to realize the best path forward is likely pair programming/working meetings (remotely) because writing things down and repeatedly referencing them doesn’t stick
Both have helped, still not perfect but its better.
Communication requires enforcement too: I had people in my team that kept saying that they weren't told about x,y,and z. If those are repeated behaviours( they usually are), they need to be managed accordingly so people would start take it seriously.
I'm also finding that the best path forward is to pair frequently- because a lot of people just don't read. Also, it's important to note that with writing things down for people, referencing is just as important as the content. If something is written in a slack conversation- they are unlikely to go searching back months for it- when they could just ask you again! When something is documented in a structured and easily memorable manner however...
Ever been in a situation where you asked someone for something you need done, they said yes verbally, it didn't get done, and now everyone is looking at you for the reason why it isn't done?
It’s annoying, wastes a lot of time and people keep doing it because they’re still stuck in office mode when they should be following IRC rules (don’t ask to ask)
I regularly find myself clock-watching until the next time I can talk to someone because everyone is always busy - there are no water coolers or coffee breaks to stitch in between.
Even if you create the virtual coffee break and have a chat with people, often we're pushed to abandon it - presumably because it's flipped from an opportunistic (oh, we're all of the phone, let's go grab a coffee) to a scheduled event which a) gets dropped and b) doesn't naturally recur.
I work to make money, not to fill someone's social void. You'll be happier if you explore the root cause of your issue and get a little more comfortable with yourself.
I really think you're overassuming your knowledge of the person you're responding to.
Or more fairly, probably the inverse; plenty of WFHers wouldn’t be so derisive, we just don’t hear from them
I’m pro-WFH and have WFH-d since 2009 but I’d love to go to the office more, if the office were nice and in the right place.
I’m not yearning for social interaction because I need a friend. I’ve got friends and they’re not at my job.
I’m yearning for the variety of different communication methods I have in a physical domain with the added bonus that I can change the environment I’m in to accommodate different tasks.
"Just socialize outside of work!" seems to be everyone's go-to response, totally missing how much time is taken up by the 8+ hours of the workday, and how much ambient socialization has been lost with that time now spent remote.
Sure, remote is more convenient for "deep work", but I honestly never had issues with that in-office: If I had my headphones on, people didn't bother me. If I had questions, I'd take them off and look around to see if anyone else was "surfaced" to talk to, or ping someone on slack. In the meantime I could kill time chatting with my team or going for a walk around the building--when I would inevitably find someone else from another team who was taking a break, and I could either ask them or just chat.
Now it's just me, in my apartment, all day, except for maybe standup. The only reliable face-to-face human interaction I have is my partner when they come home from work--and they're usually exhausted and ready to go to bed in an hour.
Work absolutely used to be a significant portion of socialization--just like going to classes used to be, in college or secondary school. We've absolutely lost that.
You're working remote, not necessarily working from home. The world is your office now.
For particularly meeting heavy days I have experienced no shame going on a daytrip while on those calls. It's nobody's business how you do your job remotely anyway. Get some coding in while stopped somewhere. Yes this means I have to make up for lost time in the day with all the interruptions. No I can't just put away the laptop at 5pm because I still have stuff to do (usually done by 8pm), but it's worth it. If Sarah from accounting is allowed to flex time to pick up her kids from soccer practice, I'm allowed to shoot the shit with random people I meet while getting gas or trying a new restaurant. There's your new watercooler. Go to the beach or something. If your partner is driving you around, even better. Use the laptop like its namesake suggests.
Not exactly a "digital nomad" lifestyle, but it's such a mood boost to mix light travel with working hours. It's a win for everyone if productivity goes up from these little things.
That's plain unhealthy.
> Quality work requires deep concentration over long stretches of time, not tapping on a shoulder at random intervals. Both IRL and virtually.
This has little to do with socializing or not.
Not trying to start a big debate over the whole issue, but just sharing that I felt very similarly to you ("massively affecting my mental health") and that it was solved by doing the obvious: going back to the office.
No amount of socializing outside of work or hobbies or 1:1s during the workday sufficed for me.
Being 100% remote for several years was terrible for my mental health. As to why... well, a lot of it was precisely because I'm introverted.
As an introvert, it's a lot more draining to do the explicit communication required to work remote effectively. Maybe 10% of people can work effectively over written comms. As a lead, I had to schedule zoom calls and make explicit face to face time to make any of it work. In an office setting, this happens more naturally and is a lot easier.
On top of that, I found at a 100% remote company it seems more common for people issues to happen. When you are only interacting over text most of the time, misunderstandings seem to happen more often.
I found it very draining to fix these issues. It was much harder than if we had been in an office together, where we could just have a quick chat and fix sensitive topics. It's also more obvious in an office setting when this stuff happens and so you can sort it faster.
I try to keep it alive by posting interesting articles, updates and tools and things like that and that sometimes drums up some conversation but it's rare that my teammates do the same thing.
I'm not sure if I'm more passionate about tech, more extroverted, more obsessed with improving processes or just less busy than them. It's been like this at multiple companies I've been at so it's not unique to my current team. And I'm clearly the outlier.
I just try to not take it personally and keep going. I feel like I post really cool things, especially new tools/repos/projects that benefit everyone to the void sometimes.
It's a lot of work to read articles when people post them or evaluate a tool. It's even more work to form an interesting opinion about it and discuss it.
I enjoy researching things on my own time, but I find it stressful to add to my workload at work, especially when it's not related to the other work I'm already doing.
It's none of these things. I am the same way but we are the minority.
In fairness I've been fully remote for 10 years but I see friends during the day for coffees, lunch, exercise. And then multiple sports clubs in the evenings
But work is 40-50 hours of my week. That's a HUGE portion of my life. Almost half my waking hours are at work. (7x16=112 waking hours a week. 35-45% of it at work).
Not taking time to socialize during that period is draining as hell for me. I guess what I'm trying to say is you're way overestimating the percentage of people who can go to work and just... work. Most people need the socialization.
You'll have no commitment to come everyday, have people to talk to, and still hopefully be close enough to home to get back anytime you need pure calm or a full dedicated environment.
To note, for many people WFH means their family is around one door away, which makes it a widely different experience from people living alone.
I really hope what shakes out is some places are all in on the office and some are all in on remote. None of this dithering crap that came post 2020
Try to exercise a lot during the day, it helps.
Accordingly, during the pandemic I think it was mostly the less experienced engineers suffering from low productivity and lack of confidence (which feed into each other).
Even pair-programming with my fellow juniors was both more productive and more educational than a rubber duck[1].
I had the opportunity to sit down to dinner with some very junior devs at a family gathering, recently, and to hear of their isolation due to remote-work broke my heart. They simply have no idea what they're missing.
I know mentorship is important and spend quite a bit of time on it everywhere I work, including with pairing. But the costs to many senior people’s productivity are very real and can’t be stated lightly. Remote work has been a godsend, previously I would do my best work behind a closed office door, in the back of a company bus, or after hours at home and it’s like having unlimited access to that zone.
Even now I find it incredibly off-putting to have somebody looking over my shoulder when I'm trying to work, to the point that I basically just can't. People have asked to watch me do something, and my response is that you can either watch me, or I can do it, but not both. It's like Heisenberg Uncertainty for work output.
> trying to verbally communicate something that would be better done in writing/code
> somebody looking over my shoulder
At the risk of sounding flippant, none of these activities comprise pair programming. What's better written should be, and the simplest way might be "can I just show you?" or, from a particularly well-atuned pair, "would you mind showing me?"
"Waiting for someone else to type," in my experience, is either a good opportunity to finish a bit of thinking that'd I'd put off moments prior, or else premeditate on our next move. Sometimes, however, the typing is, as you alluded to, an attempt to communicate something, in which case watching them type is roughly equivalent to listening to a person in conversation, and therefore an opportunity to learn, catch bugs, etc. In other words, when I am pair-programming I am never waiting qua idling.
And, lastly, I completely agree that "somebody looking over my shoulder" is an unnerving condition to code under. As purely ergonomic concern, "over one's shoulder" is not a healthy position from which to operate a computer. ;)
But, seriously, it's not pair programming if you're not on equal footing (seating?), with equal access to mouse, keyboard, and monitor. Don't stand for someone standing behind you!
I am sorry for the unpleasant experiences you've had. As a practitioner, I would not have subjected you to them. I am, frankly, vicariously irritated with whomever did.
Also the way I tend to code is never linear in a way that anybody else could follow. I write something, edit it, throw it away, put it back, rename it, hack out something I _know_ is buggy so I can see how it looks, and basically "thrash" my way to a solution that I like. That makes it essentially impossible for anybody to follow in real time, and having them try to point out errors would be counterproductive. In the later stages someone could help polish it, but even then I think it'd mostly be a waste of time.
That's before we even get to things like dealing with interruptions, or answering other questions quickly. Ideally interruptions don't happen, but in practice they do, and I don't want to be wasting someone else's time.
There's a lot I liked about XP, but I still think that (for some people) it's just a great way to make two devs produce the output of one intern.
It's certainly not.
Sounds like my dream job.
Junior engineers need help as the same rate they did before. They still need to ask for help. Remote work lets it:
- happen asynchronously & synchronously
- creates visibility of asking for help
- reduces this weird shame around it
- allows us to correct bad answers
- allows people to learn from others with the same questions
- self manages by capacity because the people with time are the ones that can answer questions
- produces an awesome collection of analytics: how many & what questions are being asked by who, Who is answering questions and about what?
Remote work is a communication and cultural change that a lot of teams have done poorly. I think most teams decided when the pandemic hit: "oh we'll use teams or slack. That's enough" and never thought more about it.What kinds of things did you think about to transition to where you are? How did that transition happen?
You can and should still have those 10 second conversations. We've got Slack huddles, screen sharing, VSCode Live Share for more complex pairing... the tools are really good now.
That said, I tend to agree, a remote culture that doesn't respect the need for teaching and mentoring is going to be bad at it.
I had more problems with junior developers who think they're senior developers (some experience, high-confidence) bc they don't ask for help when they should.
Then I give them a ticket and say "if you get stuck, let me know"
For the first little while, I am super responsive with them and answer everything immediately and eagerly.
After a while, I start to wait about 5-10 minutes before I respond to questions. Usually they figure out the answers before I even get back to them in these cases, and then I get to praise them for it.
I stumbled on it by chance when I failed to make it to a client meeting with one junior dev I was leading. He was counting on my presence to support him, we had already discussed it before. But I got caught up last minute and he decided to go alone. And I know it was hard for him, but everything went fine. And from then on he was a lot more confident in his day to day.
Weeks, even. It took me a while to come to terms with the fact that this is the majority of my value to an org now. Not so much in my IC abilities, but in the ability to save endless amounts of time for lesser experienced folks.
So interactions with the project team is fully remote.
I am sure even pre-covid many MNCs might have a similar structure with members spread across different location. Though coming to office, but project work happens remotely. Also have juniors joining the team.
It might be difficult for juniors to get started. But not impossible to handle.
The problem with “difficult but not impossible” is that it requires special personality types to handle it.
Some people can do it, but now you have a secondary problem in that you need to find a way to filter those people in the hiring pipeline. You also have a risk of hiring people who can’t handle it and having to cut them and re-hire.
This is why most “difficult but not impossible” conditions are reserved for special exceptions but aren’t useful for general policies.
I agree, and I don't see a problem with it.
> [...], but aren’t useful for general policies.
offices are just optimizing for the loudest and more social people, this is a consequence of managers tending to be like that, I don't think that approach is useful for general policies neither.
but wait, that means changing cultural and such, that's not easy is the response I often get to this, to which I say preemptively:
That I would agree with, because the US business cultural is surprisingly stiff to changing things that would have favorable impact to workers, but that is IMO a different and separate discussion to the fact that this is a readily solvable problem.
"Give guidance before" is about as good a "just don't make mistakes."
"Hey, I need you to take a look at #154, don't worry about the issues Jeff is mentioning, we just need you to fix the error in the form and write a test. If you run into any frontend issues, work with Mike, I already let him know you might be coming to him.
This is basic manager, Sr. Developer stuff.
Yes. This "get it done as fast as humanly possible whether or not you actually understand what you're doing" is the most detrimental attitude toward beginning software developers I can think of. "Going down a rabbit hole" is a dismissive way of saying "actually figure out what the computer is doing" which is what actually makes you valuable to the team. If you just wanted somebody who can type in what they're told to type in, you're wasting a lot of money hiring computer science graduates.
In office, remote, whichever - I've been ignored. It took a while to learn to ask questions.
People will help, but "the squeaky wheel gets the grease", and all. There's movement [or an attempt] implied with this.
The locality doesn't matter, effective communication can exist in either.
It's possible to foster a remote environment where Juniors do ask questions - I've worked in several. As such, I'm skeptical of this 'Think of the Juniors' concern. It's manageable.
It's also worth pointing out, Junior and Senior aren't diametrically opposed. It's relative and nebulous depending on context.
I'm a Senior Architect, but know very little about the specifics of our network devices - for example. I'm Junior to our 'Network Engineering' team, making an Ouroboros of Seniority
Recognizing where strengths are helps greatly. Productive environments have their Seniors evangelizing this awareness
The top comment is saying how to manage it. TFA isn’t saying no remote work, it’s saying less frequent communication. That doesn’t work in all cases. Struggling for hours without getting much done or understanding more isn’t effective for productivity or learning by definition. These cases can often be prevented with quick questions. “Send me an email, I check it every Monday and Thursday” doesn’t support that.
This can be prevented without (net) more involvement... with better use of those existing sessions, perhaps splitting them.
The definitions on that aren't clear - the comments around seem to expect the worst, absent employers abound.
I expect a fairly guided mission, with reports on findings. Questions both ways, Socratic or not.
Don't necessarily blame the developer - there's a _lot_ of pressure from the PHB that doesn't understand the difference between HTML and Linux to "get it done right now" and they think (for no reason) that nagging somebody else to do it for you is the most efficient way to do that.
But on the other hand, I think that value comes from more than the persistence alone: it depends a lot on what you hope to get out of it. And I also say this from experience. Banging my head to “make it work” has almost always been an enormous waste of time and effort, but to “learn how/why it works [or not]” has been the exact opposite.
Learning to do things properly by banging your head against the wall is great. But only if you feel like you have the leeway to figure out how to do things properly. Without that leeway, you need the space to ask for help.
I would have loved to have been working in an environment where I could work with the system maintainers to fix their docs collaboratively but alas it was more of an "I'm busy go away" type environment.
I think this type of dysfunction was fairly common during lockdown WFH.
I've been in an environment like this, and it really burned me out.
People broke docs faster than I could fix them, and it was an accepted part of the development process.
My conclusion was that fixing the docs was simply a waste of time. My resulting despair for the software and the company surely destroyed my productivity. (I'm not saying this is a valid excuse; just an explanation.)
What did you do instead? It’s certainly frustrating to have people breaking docs that you fixed. But what else is there. You just figured it out on your own and left the docs broken?
Sure, reinventing the wheel every time is a valuable experience, but it's not efficient to relearn how to do things every time.
This is like letting toddlers struggle to learn how to tie shoes themselves, sure they will eventually figure it out, but it's better to just teach people have to do the basics, and let people bang their heads against hard problems.
Junior engineers aren't toddlers. Hopefully they're a lot more competent. Nobody hires toddlers to do work.
Here's my analogy: if you want to learn how to ride a bike, you've got to take off the training wheels, and sometimes that means falling over.
Agree, though sometimes the hours of head banging will benefit greatly to the skills of said junior.
That aside, everyone should be encouraged to ask to company's developer forum (slack channel). That way, if the senior that's responsible to train the junior is busy, other less busy senior can help.
You can solve this, and many organizations have. It does mean re-thinking expectations around onboarding and the role of mentorship in the company though
Some of them are very independently-motivated and self-contained, but inexperience means they are still prone to rabbit holes. Others really will sit on their hands until explicitly told what to do, which doesn't mean they're bad or lazy, just that they require tight feedback loops.
In both cases, it seems like quicker feedback cycles do more good than harm.
Building an environment where junior engineers learn how to find things out on their own and when they need to ask questions is a company culture thing and has very little to do with remote vs in-office.
This is why I more or less never go and "do my own research" before asking questions for hobby projects. I've gotten stuck in too many research rabbit holes and (hopefully) have learned my lesson. Ask first, then get mired in irrelevant details if the response to my bizarrely unique question is crickets.
Also this is trivially solved through checking on the person twice a day and doing call reviews, thus making it at most a few hours.
Actually, this is a regular part of successful remote team building.
Meanwhile making the junior approach unannounced is counterproductive. I for one would rather have my interruptions at least scheduled if they can't be avoided.
People still ping me frequently for a "quick chat" which is rarely quick, tho.
Also not reaching out when getting totally stuck is a bad thing, but again unrelated?
> There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk
Also just not getting that, hitting the call button (or a real phone call) was always quicker and easier than walking two floors down to another room just to find the person not at its desk. Where is the hurdle?
Really, just not getting it ;) What's to be solved? I see it may be a problem or hurdle for some, but for others the bigger hurdle is the opposite way. Don't extrapolate, generalize and state it like fact, because that is imo not true for everybody and may be the other way round.
There was more friction to asking quick questions, compared to being in office. This may not be the case any longer at all companies, as it's possible that some of them solved this with new communication practices.
Sometimes people are just frustrated and spinning their wheels, or doing work that turns out to be pointless because they failed to understand something which would have been clarified by a short conversation.
If someone hasn't pushed something in a week or two, that's a good time for their mentor to initiate a conversation and see where they're at and when they think they will push something.
Anything else is micromanagement by a company that has hired someone without giving them any amount of runway to actually work and learn the space they're in. You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking. Let's not pretend the micromanagement cultures where "fear of rabbit holes" exists are not already doing this.
Are you saying the mentor should actually go and check the browsing history of one their engineers to verify whether they've actually done "correct work" or what are you trying to say exactly? This sounds to me like micromanagement of the highest order.
Instead of properly adapting the onboarding and mentoring to the remote setting let's romanticize the good old ways that imho sucked.
Let's cherrypick and pretend everything is fine. We went from offices to cubicles to open space and nobody stopped to think if it was a good idea. Wr transformed the office from a place where work actually is done to a placr where we "socialize". Work? Do that on your own time.
But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience.
The best mentoring results for me as the mentee and for me as a mentor have been when we're sitting next to each other. The mentor can visually tell when the mentee is stuck, and mentee can tell when the mentor isn't focusing on anything important and is more willing to ask for help.
No matter how many times you tell junior engineers to ping you at the first sign of trouble, they're not going to do it. They're going to toil for way longer than needed, unless you're sitting right next to each other.
I have to say as a counter point though that I've had a lot more trouble with coworkers coming to my physical desk for questions that they could have Googled than with Junior getting stuck for extended period of time remotely. It's all a matter of culture and relationships.
They won't do that every single time. At some point they'll realize that asking for help isn't an issue.
Part of learning to be a sw developer is learning how to go about your work. Learning when to ask for help. If someone is doing this for you, you'll never going to learn.
Part of being a senior engineer is to use the mentorship skills you developed along the way and make judgements about how much struggle is right. Every new person should have a more senior partner with whom they can ask the dumb questions and not be made to feel dumb.
There are whole college degree programs designed to teach this, in fact.
It's clear which juniors are motivated and will make the most of the mentorship and which ones are not. Some are just there for the check and you cannot compromise your senior and higher talent on people who don't want to learn and grow and just want the prestige and check of a high-tech job. It's the same situation with someone who is drowning not listening to orders and taking down their rescuer with them too.
If a junior needs someone to sit next to them because they toil for way longer than needed on clear simple requirements and goals, this may not be the field for them. I never needed anyone right next to me that couldn't have been a direct message or a brief remote call to clarify something specific, clear, and to the point. You're describing a reality where the people who don't do are just trying to take as much time for themselves as possible to hide the fact that they don't want to think.
We've used day long zoom windows or slack huddles. Keep muted until you want to say something. Slack is the same thing, just send a message.
And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented.
I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
It’s great you value work life balance, but junior engineers suffered a lot (to different degrees), and you being on edge that remote work might be taken away from you is nothing compared to what I went through and haven’t recovered from.
We’re allowed to love our work and the people we do it with, that’s my ideal, just a because you hate it doesn’t mean everyone should
But... the pandemic also broke me. Bad. I wasn't at all prepared for life trapped inside where my only interaction with human beings I knew was via video. There were like four months in early 2021 where I only had about four interactions with flesh and blood humans whose name I knew (like, not some entirely random person)... one of them was the guy who lived in a nearby park whom I normally avoid as it is so difficult to end conversations. I gained a ton of weight and at one point--end of 2020--I had given myself some kind of weird anemia (I think from lack of B12 in my stupid closed-in diet).
Like: I am someone for whom his entire life normalized remote work and who thrived in such an environment and yet the pandemic was so hard I still haven't really recovered... thinking about it makes me cry. (And like, yes: I could have better managed my lifestyle or better handled the loneliness. Whatever. That is also true for you, and I at least am not judging you for that.) It is one thing to not work in an office--you can work from anywhere! and there are a ton of people who you can get to spend time with--and it is entirely another thing to work explicitly from a small room in your home day in and day out for a year without human contact.
I thereby want to posit that maybe--just maybe--the issue isn't working remotely but being forced to stay at home and at times even fear going to the supermarket. There were periods during this thing when people were even afraid to meet up outside, and so human contact for white collar professionals outside of relationships was pretty much just verboten. The world was in a shitty place, and you shouldn't judge working remote based on the experiences you had during a pandemic without even trying to control for the existence of a pandemic as part of your analysis.
You’re right, I do still think there is value working in person, but remote work by itself isn’t what caused this, even if it’s still what happened.
Hindsight has made all this more clear, but imo loneliness is a silent killer around the world today, and covid threw jet fuel on the fire.
Don't misunderstand me, I'm not romanticising the marriage of one's social life to one's workplace, nor overlooking the ways this "we are more than a company, we're family" rhetoric benefits employers at the expense of their employees' outside lives and broader well-rounded and fulfilment. But I think asking people to separate them in an extreme way is just as untenable.
Working remotely I found myself constantly wasting time trying to figure things out on my own because I don't know if people are even online/active (spread out across the globe, another issue common with remote), if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)
If you want juniors to learn anything in a reasonable amount of time you have to give a bit of a shit and invest more time solely towards that especially in remote environments, seems that people just expect juniors to take the lead and force their way in though which isn't my style at all and if there isn't a common agreement and people are all just doing their thing it can come off as presumptuous to be bugging people left and right for the first months. Yes part of the problem is company culture not properly adapting to the environment, but I also haven't seen any change in the way we deal with communication since the Corona and of course seniors don't care because they got their job security.
> if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)
Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well.
Its not your fault, at all. Its the company. Its not inherent to remote work though
Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask.
Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.
Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.
There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change.
Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”.
Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.
That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time.
So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.
Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?
* Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is.
* Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas.
The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.
To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.
People have been complaining about this development since forever. I'm not sure who that 'nobody' in your sentence is?
Mark Zuckerberg might be a true believer in open plan offices (judging by his public comments). But your average Fortune 500 company might only be into it for the savings in office space expenditure to be had from cramming people tighter. And some companies, like SAP (at least when I did an internship with them ages ago), still have offices (shared amongst eg 4 people) instead of going open plan.
Yeah, there might be some impacts to junior engineers. But if it improves the efficiency of your more expensive senior devs, isn't it worth it?
And just because your team has a problem with onboarding and mentoring junior devs in a remote environment doesn't mean A) Everyone has the same problem, B) you can't fix that problem yourself. Self improvement is the name of the game here anyway
Before the pandemic, I usually got up to make coffee, to ask for help or to make consensus with my fellow coworkers (other devs or even UX people, a few stairs away). I usually walked from work from time to time to clear up my mind. Now I barely move. I live in a small apartment. The fridge is 3 meters away from me.
Back then, I could somehow manage my weight by applying some casual restrictions, like eating fewer carbs and eat mostly lean cuts of meat. Now I need to apply some zen monk level of self control if I want to not gain more weight. And losing it is terribly hard.
Having a strong social life outside of work insulates you form this
Working from home means I make healthy lunches for me. It's a lot easier to eat right when you have a full kitchen and pantry at your disposal.
Wasn't as great as fresh food but at least I made sure it was healthy.
I can cook but I appreciated not having to think about it, and the food was great.
It’s kinda nuts the lengths people to go put down those who simply hate working at home 40 hours a week.
Maybe there are more granular and data-driven conclusions, I'm just someone who sees the benefit of communicating information over vast distances aka the web and appreciate that it's something we can do nowadays.
A message, SMS, phone call, a group call, a skype call or whatever can clear things up right quick.
Plenty times I'll send someone an email because I don't want to engage with someone and the time frame of their reply can be minutes or days. That's fine.
WFH/remote is all about trust from an employer and motivation by an employee.
You're entirely free to communicate as much as you need to whether you're physically present or not. The work gets done or it does not.
I don't really understand the confusion about this.
That type of blog post is typical from so-called thought leaders that want to assert themselves as experts on the latest trendy subject.
In real life, everything is a shade of grey but of course it makes for less of a clickbaity headline to acknowledge that.
Also, the author is a lawyer/mba and doesn't have a single experience in engineering.
The population before Covid were often highly experienced, disciplined, and proven workers.
The population after Covid, was well, everyone who worked with a laptop.
Not everyone is cut for working remotely.
In addition, there’s a difference between 1 out 20 people working remotely full time and 20 out of 20.
In my experience the companies that struggle with remote work are the ones the manage via attendance. One company drove me insane with random “Hows it going” messages throughout the day so I just left for another company and let them know why on the way out.
Managers that have enough domain expertise to manage via outcomes however thrive in remote environments. But, this is harder to do than taking headcount.
Remote working environments require different approaches than in person or hybrid. Change is hard and all that.
But this is ideal right? Their culture is asking "how's it going" throughout the day and it's not a culture you wanted to be part of so you left.
Asking "how's it going?" throughout the day isn't objectively good or bad – it's just not for everyone.
Most of the time, this simple innocent question is an introduction to a work related question. It is, and has always been for me, a massive waste of time. You lose your focus, you stop working while waiting for the coworker to decide whether or not he will ask you the real question in the next 10 minutes.
I approximately lose 1 hour every day due to this behavior and it's really annoying.
You may not like it, but the idea that’s objectively bad is your opinion not a fact.
What’s wrong with a company’s employees deciding they like checking in with each other and not having it tied to a specific task?
We spent 3 years in pandemic mode working from home for everyone. We've all figured it out by now. Go into the office if you'd like, but don't force everyone back to it.
When they’re in the office 3 things work to prevent that:
1) yes they are supervised. More senior devs and also management can keep an eye on them
2) They’re more likely to just randomly ask a question or ponder aloud than they are to write something in slack, so it’s more likely someone can catch them going off the rails and re-direct
3) They’re more plugged into what everyone else is doing, so more likely to keep “coming up for air” and keeping their mind focused on the main goal and not the rabbit hole.
Again, these are perfectly fine junior devs with perfectly fine skills, and even their tendency to get enthusiastically lost is just more junior dev stuff.
But they don’t know how to work remotely, they’re not self aware enough to know they need to learn, they don’t take the feedback on it very well either (again see “it’s only because management wants butts in seats”)
So the options for this are mandate them to the office or eventually fire them for being more dead weight remotely than they’re worth.
tbf, if you meant the full workforce it's never going to be 100%, there's so many jobs that require physical presence out of necessity.
There's maybe some jobs where you could also argue it's required.
Emergency surgery, police, paramedics, electricity grid maintenance, plenty jobs where there's simply no WFH angle.
I'd totally agree that personality types would also clash from WFH, so it's definitely not the definitive solution, but it works for a lot of people.
Not that those were great, by they are incredibly prevalent in an office setting and there was never enough industry wide pushback to these interruptions to really put a dent in them. Remote work has allowed workers to put some boundaries up around this and made their "tax" much easier to feel and quantify by workers in general.
This is where I have found in a nut shell is why communication breaks down without re-wiring it from the ground up and ingraining the new remote work into the culture of the company. You can't just lift and shift the methods from one modality to the other
* Occasionally I'll get a good conversation with a teammate or manager about something technical, but the frequency has not gone up. The technical conversations are still scheduled on a calendar and happen at the same frequency. I really haven't experienced many people stopping at my desk and I think I've only stopped at the junior engineers desk to check in.
* Socializing at work has not been my strong suit. I am pretty introverted when it comes to strangers (e.g. anyone who has not been introduced to me). I find the socializing to be more energy draining.
* I walk to work. I like that typically. The walk can be... disturbing to say the least since I walk through downtown Seattle.
* A lot of people in the office prefer to speak to each other in languages other than english. Everyone on my team (my manager + all my coworkers on my team) prefer speaking something other than english and do so unless I'm involved in the conversation. This surprised me and at times I find it frustrating because I wish I could know what they're chatting about when it's technical (certain keywords I can pickup on since they're the name of internal things).
* working in office 4 days a week has given me something to really look forward to each week, and that's the WFH day.
* I don't think my productivity has gone up. Some days it's definitely worse. Now there's an obligation to go sit and eat with others for 30min-1hr a day. Previously, I'd just bring my lunch to my desk and continue to work.
I don't think my experience is the norm. But I certainly miss the pure WFH days.
Your case is the obvious one: if most people speak Finnish but you only require English of your hires, sooner or later you will have people unfairly excluded from the social part of the office. Even if you’re in Helsinki, you need to either require that work conversations be in English, or make obtaining Finnish fluency an official part of the job. The latter being the much harder route.
However, in real life this requires a more enlightened C-suite than you probably have (cf. butts-in-seats order), so you might consider carving out an hour a day to quietly learn whatever language is being spoken by the rest of the team. It’s probably easier than Finnish and it could help your career!
It's also not just my team. I see other tables at lunch and other teams having conversations in what I assume is the same language. I have a hard time differentiating based on sound.
But correspondingly more valuable if you end up learning a little!
If you're based in the US, this is just extremely rude.
I just want one single place that is actual 2019 normal. None of this BS hotdesk crap.
This is the only real difference: that any individual can wield the power of one-to-many communication. We all have a voice now.
Calls and DMs exist solely to ensure what's in writing is understood. Same as it was in the physical office for meetings.
in 20-30 years i'll be worm food. not going to waste anymore time rotting in an office. f---k no.
People fail to understand that rotting in an office is not the type of memory you want when life flashes in front of your eyes on your death bed.
Imagine sitting there, and all you see is a bunch of scrum meetings and planning sessions followed by scuttlebutt with someone your dread gossiping about someone you don't even know, thinking they are your friends.
"relying on constant, synchronous, and often interrupt-driven interactions"
"Async work allows for more reflection, research, and synthesis"
"Those working async can and should take the time to think, learn, and synthesize before sharing their ideas, opinions, or solutions"
"form of communication for the purpose, audience, and context"
"use writing for documenting, explaining, or persuading; use video for demonstrating, teaching, or storytelling; use chat for coordinating, clarifying, or socializing"
"Write clearly, concisely, and comprehensively"
"using simple language, short sentences, and clear structure"
"provide enough detail, context, and evidence to support their points, answer potential questions, and avoid ambiguity."
"Record videos with empathy, enthusiasm, and engagement"
"using eye contact, facial expressions, and voice modulation"
"keep their videos short, focused, and interactive, using visuals, examples, and questions"
"Communicate proactively, regularly, and asynchronously"
"communicate their goals, plans, and updates without waiting for prompts, requests, or deadlines"
"communicate their availability, boundaries, and preferences"
"using synchronous communication only for urgent, complex, or sensitive matters"
Recently joined a new company that is remote first with a fair amount of juniors in it. It's rather difficult since they often lack guidance and start rabbit-holing in the wrong direction before eventually failing or producing a very non-ideal solution.
For us a pure asynchronous comms workflow simply doesn't work well yet, this may change w/ more seniority.
I found that having weekly (or even bi-weekly) 1:1's with my colleagues and pair/cowork dramatically lowers communication barriers and boosts productivity through the roof (albeit at the expense of 2 people working on the same project).
Major issues can surface when colleagues don't communicate at all other than just pull requests / issues / standups / design docs (whatever you call them). It can cause people to perceive others are 'faceless entities'. This can range from building completely misaligned solutions to even sparking interpersonal conflict.
(full disclosure, we're building a platform that integrates with Zoom to visualize all these rooms, and who is in them, so people can hop into the rooms where people currently are, and know when someone isn't available before joining, etc. would love to interview you for user research if you're up for it)
In practice, it is the complete opposite with context switching on steroids brought to you by Slack channels.
- If you have a deep technical problem that you already understand a lot of the context for, and you can explain it like an expert Stack Overflow user, then use writing to ask someone who might be able to help you.
- If you're a newbie to this context, don't know what you're dealing with, and there's no documentation that you can understand, write a much shorter message focusing on the immediate issue and ask if it might be most efficient jump on a call, ideally with screen share.
- If you're somewhere in between, do your best to set up the problem in writing, but don't overthink it or assume too much about what your helper needs to know. Again ask if a call with screen share might be more efficient.
Basically, always use writing to start, but adjust the length of the message based on your ability to set up the problem for your helper. And if it's urgent, hopefully there's some way you can ping or notify the person.
More generally, the more you can predict about how the conversation should go, what details are needed by the other person, the better it is to use writing. The less you can predict, the better it is to use a synchronous medium, such as in-person conversation or a call with screen share.
And if you find yourself always needing synchronous media, I would suggest that you try to do more to retain and document knowledge in writing, so that you're not always going back to square one every time you need to solve a problem. After a few months working in some area, it should be increasingly possible to ask expert questions in writing.
Instead of booking a 30 minute meeting, that only has maybe 10-15 minutes of work talk and 5-10 of personal talk, we might instant message for 15-20 mins spread across a whole day.
Or if things get complicated in the first few minutes we'll just have an adhoc call for 5 mins, then IM whatever details we thought of after hanging up. That 5 minute call is similar to swinging by someone's desk.
Some people still insist on booking the 30 minute meeting, and that can make sense when you have several people or some "meetings are my job" people are involved (upper management, marketing, sales, etc).
It seems like about the same amount of work talk either way, but usually less personal talk. Introverts love that, extroverts are missing out.
It also varies by person. Some people are too vague in their typed messages so it's better to talk on the phone. Other people have really thick accents and English may be a second language, so a detailed IM conversation can actually be more efficient than talking on the phone for both parties.
Work isn’t much different. My team leaves zoom standup open all day, we break into conversations all the time. It both (a) keeps everyone engaged and (b) removes blockers fast.
That said, we setup side “rooms” we can move in and out of. There is also the option not to be accessible, but it’s typical to be available
(full disclosure, we're building a platform that integrates with Zoom to visualize all these rooms, and who is in them, so people can hop into the rooms where people currently are, and know when someone isn't available before joining, etc. would love to interview you for user research if you're up for it)
To answer your question — many years
Sometimes you need lots of small synchronous communications and sometimes you need and fewer large asynchronous communications.
Large asynchronous communications work when everyone already knows what they're doing. They work at a company which has already figured out its business model, built out its necessary expertise, and saturated its market, where everyone's a senior engineer. Like, I don't know, GitHub, where the OP works as a Director of Engineering.
Frequent synchronous communications allow for tight coordination in the face of business risk. This is the startup world, the "we're-still-figuring-out-what-we're-doing", "maybe-this-will-work-maybe-not" area of the company stability spectrum. Also this is the area where junior devs are with their careers, so this model is best for them, too.
This reminds me of parameters that can be used to tune garbage collection. Collectors can either be tuned for throughput, or availability, but not both. Throughput optimization translates to long stop-the-world GC pauses, where availability translates to more frequent, but smaller pauses so the application is available to take traffic.
It also reminds me of a soccer player trying to control a soccer ball. Getting the ball down the field (throughput) is often via a single really hard kick. It's fine if control is reduced, it's throughput that is needed when the ball is too far away from the goal. Conversely, controlling the ball downfield requires lots and lots of tiny touches of the foot.
One final comment: asynchronous works great for open source, so why not business? In short: business has a deadline, (hobbyist-run) open source often does not. This being the case, it's fine if the communication takes a little longer. But in a time-critical project, synchronous communication is still our friend.
Hold your horses. Your constant synchronous communication reduces the aggregate throughput by increasing context switching, which incurs dead time for the interrupted parties as they refocus on their task. A better way is to reserve synchronous communication for urgent requests, and time block (batch) or async the rest.
Written daily updates in slack followed by 45 minute stand up.
I already try to overcommunicate, but it does not stem the interruptions and it’s certainly not asynchronous.
Frequent “how’s it going” an hour after stand up, and before and after the 1:1.
How do I push back?
- Direct feedback to the manager about your needing space to work and their disruptive behavior.
- Same feedback to their manager.
- Look for new jobs.
There’s no way to solve this that avoids direct feedback and the possibility of confrontation.
In the spirit of incremental improvement, what’s the smallest action that you’d recommend that I can take?
Many different ways of dealing with it,
- from not responding at all (I do this often when people just ”ping” without stating their business),
- to asking what the matter is and if its urgent otherwise lets discuss it (a good while) later when I have time (I do this often too, my job is programming and requires focus time)
- to just saying that you are busy right now
Just a few ideas, find the guts to experiment and learn
I actually rarely bring up these kind of issues with managers, I find its mostly about signaling and breaking the loop that annoying people thrive on. Learn to subtly draw a line, repeatedly if you must, without being confrontational
If you say "hey, I'm the middle of working on X. Can't this wait until we have our 1:1?" do you think that wouldn't be well received?
Also, maybe give them some information on how expensive context switching is.
This has actually been difficult for some people to get used to, since they much preferred synchronous communication (calls) or drip feeding information (what they need, spread over multiple messages, starting out with a simple "hey").
I actually made a site a while back to elaborate on how to make others do context switching a bit less often, maybe it's helpful to some here: https://quick-answers.kronis.dev/
(the other guides that I found online about this had a bit of a mocking tone)
Of course, there are also times when you do need a bit of synchronous communication too, which is also fine.
For example, low latency this is ok: “do you want to go to dinner or a movie?” Movie. ”Do you want to see Barbie or Oppenheimer?” Oppenheimer. “Do you want to go at 6:00, 7:00, or 8:00?” 8:00.
Instead for high latency, this will cut down on a lot of dead time in back and forth: “Do you want to dinner or see a movie? If you want dinner do you prefer to go to Il Capricio (Italian) or Sushi Go 55? I can make reservations at 6, 6:30, or 7. If you’d rather see a movie, do you want to see Barbie or Oppenheimer? Barbie is at 6:15, 7:20, and 8:15. Oppenheimer is at 6:00, 7:00, and 8:00.” Let’s do Oppenheimer at 8
It’s more work up front and any unchosen paths are “wasted effort”, but for work there’s usually value in fully exploring the alternate paths anyway.
Somehow I’ve become more comfortable just proposing a complete plan, but also explicitly calling out the fact that it is actually totally up for discussion. So instead I’ll say something like:
Want to see Oppenheimer at 5:30 on Sunday (n.b. I pulled that time completely out of my ass just to get the ball rolling, any time this weekend is fine on my end, and Barbie also looks good).
Somehow it just feels more natural to me, I don’t know why. I like that it presents the person with a default-path, but also leaves everything up for discussion if necessary.
Async work can, and often should, happen in the office is well. Synchronous work is often required in remote work.
A big stumbling block for remote work is the belief that remote means you shouldn’t have to interact with other people much. Some people like that idea, while for others it’s a big problem. Juniors especially struggle when their contact with other team members is forcibly reduced to narrow windows or very delayed responses to everything. Juniors shouldn’t be reaching for help at the first signs of struggle, of course, but some of the async work zealots push the concept so far that juniors are expected to be almost solo developers.
As someone who has successfully worked remote for years, I worry about all of these ideologic prescriptions for how remote work must look. Most of the remote work failures and return to office mandates I’ve heard about in local companies have their roots in unrealistic ideas about remote work, both from the company side and the employee side. Having done this for years I think it’s important that people are still available for ad-hoc collaboration and conversation in company chat, within reason. Remote fails quickly when people take it as an invitation to isolate themselves and check e-mail or Slack once or twice per day.
The only exceptions might be work that is highly repetitive and truly isolated, like an employee who can take an endless queue of similar tickets from Jira and do isolated work on the same tasks over and over again. Most engineering R&D work doesn’t look this isolated, though, so the model fails when forced on more traditional software development.
I’ve also experienced the opposite extreme, where managers go remote and feel obligated to schedule meetings all day long. I had a short-lived remote job where my calendar was over 50% recurring meetings before even scheduling time to discuss work with peers that week. Predictably, nothing got done at that company and they are reluctant to let anyone work remote now.
Curious: what does your current team / company do to enable the real-time ad-hoc conversations that need to happen? Are there conventions or tools that have helped?
(full disclosure, we're building a platform that integrates with Calendar, Zoom, and Slack to try to solve this problem and let people turn to one another in real-time, without interrupting heads-down time. Would love to interview you for user research if you're up for it)
I do not think this means more communication. It means less time spent communicating and more time spent working on your area. What on earth are you all working on that requires constant communication?
Problem is that most people aren't good at written communication. They're passable, but not good. This means the communication isn't actually "richer" it's just longer.
The rise of remote has led to so many wasted hours (for the author and readers) due to RFCs and proposals that just never had the chance of going anywhere, because the people that could help don't have time to figure out what the author is actually asking for or trying to get done.
Then people whine about how no one is listening to their great ideas.
After 2 years, this was when I knew that this particular manager was struggling with the same problems in the local working unit and that leadership at the VP-level (externally hired) was totally inaccessible to help make critical decisions.
It's a tough job market, but I'm looking more ferociously than ever as of this week.
- Write a set of concise, clear, well-structured discussion notes ahead of a meeting
- Give all attendees time to pre-read the notes and flag the specific points requiring deeper discussion
- Once face-to-face, discuss ONLY those flagged topics. Don't waste the opportunity for high-bandwidth communication on the notes/topics that aren't contentious.
(full disclosure, we're building a platform that integrates with Calendar, Zoom, and Slack to try to solve this problem and let people turn to one another in real-time, without interrupting heads-down time. Would love to interview you for user research if you're up for it)
(full disclosure, we're building a platform that integrates with Calendar / Zoom / Slack to visualize who is available, who's in a mtg, and who is in Focus Mode - the idea being to help people turn to one another in real-time, but without distracting people who need to focus. Would love to interview you for user research if you're up for it)