Lessons Learned from the Book “Effective Remote Work”
phauer.com
phauer.com
> And a little ‘How are you feeling?' goes a long way.
> “When leaders make time for fun, it gives permission for others too”
Is it just me, or are others also annoyed when work is mixed with forced socialization? I don't need to have fun or get personal therapy at work. It's just work. I would rather get it done quickly and efficiently and then have more time to have fun with my family or non-work friends.
If you work in a team in any capacity then you need to have a strong baseline of trust in order to work effectively.
Trust is the building block that all effective team performance stacks on top of (see 5 dysfunctions of a team).
You don't just get trust for free, you have to build it by creating moments like this where people can demonstrate vulnerability around each other.
This is bullshit. I trust my accountant because he's competent and honest, not because he's been vulnerable in my presence. What you're describing is unprofessional.
The last thing I want to know about (or experience from) my co-workers is anything personal or intimate, unless it's relevant to the job.
If I want to know my coworker better that's my choice, but otherwise it's somewhere between irrelevant and unwanted.
1. Will I trust this person to do their job competently?
2. Would I trust this person not to defect in a prisoners dilemma situation?
The second is what you need the personal connection for. There are two ways to work on a project, to make sure it has the highest chance of success, or to make sure when it fails you don't look like your to blame.
#2 is needed so that both parties take a chance on each other and don't optimize for throwing the other under the bus.
People should be able to trust their coworkers on ways that the GP didn't capture. But those do not include adversarial situations. (And honestly, "Hey, how was your weekend?" can as easily add or remove all kinds of trust. None of this is simple.)
It depends on the company. Quiet a few have this inverted (management is there to cause them). Basically every company that lays off workers that underperform according to KPI cause them by design, which is almost every multinational company.
Many of the managers I've worked with spend as much if not more time thinking about CYA/metrics/etc... than accomplishing the tasks they're given. And the ones that don't spend a lot of time developing relationships instead.
When those products/projects inevitably don't deliver on some expectation, someone is going to ask why? It is pretty important when that happens the answer isn't "jamesbarney is an idiot".
Here's a subtle betrayal that can happen, it comes raise time, you've been busting your ass on something that is really beneficial for the project but doesn't help any of your KPIs. Is your boss going to go to bat for you pr are they just going to tell you how important your KPIs are and wish you better the luck next year.
Do you work for the mob?
What's your philosophy on developing people in teams? I'm sure it's not just to 'hate' people into good performance. If you take a long view on people, you have to create a space where people are comfortable admitting their shortcomings.
I've never had to build/maintain a team from a management perspective. But from my own experiences the people I've learned the most from were competent themselves, good teachers (IE they explain their reasoning and ask leading questions to help understanding) and approachable. So if I was asking too much or stuff I needed to do myself, instead of dressing my down in front of the team they'd privately say "I know we're throwing a lot at you, but time is becoming an issue on our end. I'd recommend talking to [manager] and asking for a some time to research this subject with a wiki page as a deliverable." (this is a non-hypothetical form when I was a newbie). Semi-compulsory social interactions were never a factor.
Also the person I had in mind when writing my post was actually very experienced. Affable, but totally incompetent with no interest in learning.
My expectations are relative to experience.
- Juniors need a lot of help and won't be independently solving complex problems. Every review they submit will need some guidance and it will probably be about basic things like "this function does 3 things and over uses global variables." If they're learning then they're doing it right.
- Mid level developers should be independent contributors for everything except higher level design or very technical work. Mistakes will be present but more rarely and relating to harder subjects. Mistakes I'd expect from a mid level dev would be more along the lines of not knowing that signed integer overflow is undefined in C, passing a pointer in a not quite safe way, ect.
- Senior level developers should need little technical guidance and their reviews should be almost all QA. Since they have a deep understanding of their field they can refer to documentation and datasheets more readily and when they need help they usually know what to ask. In general they should be answering a lot more than they're asking.
I'm talking about trust in a sense of - if I give you some feedback on something e.g.
"Hey I noticed that in our Zoom meetings you've had your camera off recently - we have a team working agreement that we try to keep cameras on in meetings to make remote work more tolerable. It makes me worried that you're checked out"
If there is a baseline level of trust in the relationship, that means the recipient trusts that I have their best interests at heart, and I am trying to help them through feedback, not attack them. The giver of the feedback trusts that the message will be well received.
Having this kind of trust encourages feedback, which leads growth. If you don't have this trust, everyone follows the path of least resistance of not giving feedback.
I think that especially in remote work, peer to peer feedback is such an important avenue for professional growth. Especially when a manager has 8 reports and doesn't really know what's going on.
Perhaps you disagree on the importance of feedback. But if not, then perhaps you disagree on the importance of trust in giving feedback. If so I'm curious as to whether you always find it easy to give and receive it regardless of who you're talking to?
I'm having a horrible period in my home life. My wife and I are getting ready for a divorce, my mother is sick, my child can't stand his own father. The house is always a mess and so am I. I can barely look at myself in the mirror without crying so I can't stand the idea of colleagues looking at me in a webcam.
This is hyperbole. But how would you respond in a 'trusting' environment to this?
I've had periods of my own life where I've been through tough stuff that has affected my ability to do my job - I guess I feel lucky to have had managers and colleagues who I've been able to talk to fairly candidly in these situations. In all cases I've had signal that they were grateful I shared.
In answer to your question - I would imagine a more realistic conversation might go:
"Hey I noticed X thing, what's up?" "Yeah, I'm having some trouble in my personal life I haven't been myself" "Anything you want to talk about?" "It's complicated to be honest" "Ok well take the time you need and let me know if you need anything".
That's from manager->report. Between colleagues at the same level I guess this scenario could be a bit more complex to navigate. One trivial example I can think of though is in the company I worked at during the pandemic - many moments on team meetings or 1:1 calls where people opened up about their experience of lockdown and how painful it was to be stuck inside in a shoebox of a flat in London. These moments bring people together
I also recognise that peoples' feelings on these matters are hugely cultural - I think huge chunks of the dialogue that happens in the HN comments is just people with different cultural frames of reference talking at cross purposes, but the anonymous feel of the comments section blurs this and makes it feel like everyone works at a FAANG in silicon valley.
Thanks for the answer. There’s two points this realistic conversation make me think of: one would be that this would put a little crosshair on me (or larger depending on the socio-cultural aspect you mentioned) and ultimately it would end up in the same counterfactual scenario you proposed. I can’t realistically take as much time as I need to fix the situation and will end up ultimately passing it or breaking down.
Thanks again for answering, but I’m still struggling to understand bringing personal baggage in a work scenario where deep friendship is not involved.
That's likely not even the intention... but, something well meaning can go wildly wrong - particularly when someone is stressed
Confusing care for supervision in a way, interesting internalized response I'm chewing on
Not every company is an ideal organization where demonstrating vulnerability is going to lead to a positive outcome. Fast growing orgs are often stuck with bad actors because hiring a replacement is difficult, in some cases virtually impossible. You will be stuck in a political game before you are even aware of it and forced to work with people who hate you because you worked for a FAANG or whatever tickles them.
A lot of my colleagues in other industries often complain about the political nature of their work, and the impossibility of giving feedback to certain people in certain positions. I always assumed this was a tech/non-tech divide - or a small/large company divide. I still think those are good heuristics to be honest, but you're right about the "bad actor" dimension. I think that's why it's so important to have a well-embedded company culture, it functions as an immune system against bad actors and trust/feedback are huge parts of that immune system.
Yes I work with software, no I don't expect everything to be a computer game or "cute".
Yeah, but when starting a new project affords almost none. Should it remain like that for years?
I hate the "corporate fun" exercises as much as the next guy but without something to build trust most teams flounder.
Japananese/South Korean salaryman drinking culture (or any after work drinks culture) works well at this coz alcohol naturally makes people vulnerable. It obviously has its own problems.
Even if you could somehow sprinkle social fertilizer on your team and make them all besties with a sick ropes course in Provo, it is immoral to expect it. Your employees' relationships are their business, not yours.
On the other hand, I've heard remote/distributed people very vocally object to being asked to travel to a team meeting once or twice a year on the grounds that they work 9-5 (or whatever) and that's it.
Intra-team relationships are different to inter-team relationships.
This point is so important and so commonly missed in the context of remote (or indeed, any) work.
Less glib: I've always found the technical part of work to be by far the easiest part of my job. The computers do what they're told and when they argue with me, it's deterministic, unambiguous and consistent (at least from its perspective anyway).
People are a lot more complicated, and they seldom know what they want, what to build, whether they know enough to recognize what to build, whether they know they know enough to recognize what to build, etc. they have feelings that can be hurt, friends who they want to defend, opponents they want to see suppressed. I could go on.
Maybe I've somehow only worked in dreadful, dramatic hellscapes, and I wouldn't necessarily disagree with you? But also I think politics is what happens when more than 3 people want to work together, and so it's an inherent aspect of work.
Sorry, this has been a bit rambling. My point is that, while sure you don't need to do bowling night every week, I do find that a zoom call with your teammates every other week with no agenda other than to chat is ridiculously effective.
And sometimes your best work can happen after you both accidentally give and receive therapy while at work. Everyone is the main character of their own story and knowing how even the work part of all those individual main stories connect can be really useful insight.
Not at all. If anything, you are being very stoic about it from my perspective, but then maybe I only had my initial share of hellscapes ( and each new one is getting worse ). Things are getting more complicated in systems and company hierarchy. It is not always understood ( or well documented ) how those systems interact ( or even supposed to interact in theory ). Without careful navigation it is easy to miss something important, because of office politics.
edit: adding missing not
My guess is that management pushes this for loyalty. If all you do is work and get paid you're likely to exit the first year they don't give you a competitive raise. If you're part of a family then you'll stay and even trust the ceo when he says that no layoffs are coming.
I also don't like forced socialization but like the possibility of socialization being there, as a way to build team cohesion, disengage from work, etc.
This, however, doesn't mean that everyone uses these features correctly.
I feel like most downvotes are used to simply disagree though.
Sure, communities change, but it seems whenever I try to get folks onboard with "don't downvote to disagree" I get pushback from some admin, founder, senior community member that downvoting to disagree is Just Fine.
Edit: my preference is that, as you say, downvoting should be used for comments that don't add to the discussion.
I see a lot of honest opinions and questions downvoted, and this turns threads into echo chambers.
I can't imagine why this could possibly get downvoted.
Interesting! I didn't know there was both flagging and downvoting. I'd assume flagging works like reporting on Reddit.
If I'm at some meeting about an architectural decision, I don't want to socialize, I want us to get to the point. If people want to hang out after that, that's fine. But that's not what that meeting is for.
That's so much of you life that you may as well try to make it fun. How you make it fun depends from person to person, but socializing with coworkers is definitely on the list for many people (especially extroverts). Introverts may have other ideas, like learning new exciting stuff, but IMHO, if all you think of work is "get it done quickly so I can do something else", I think you are missing something. It doesn't mean you should live for work, but if it takes, say, 20% of your "good time off" to improve 80% of your time at work, I think it is definitely worth it.
Beyond the occasional stop-through if I'm in the area, I don't derive much value from being there in person. I submit that sharing your desktop and talking into someone's headset is actually more intimate than sitting around the conference table or viewing a screen in a cubicle.
Where I work currently there's 99.9% emphasis on output, and .1% on conversation. As a result, I have zero sense of team, zero sense of trust.
That's fine when working on small things by yourself, but it doesn't scale. Teams are necessary to solve larger more complex problems. I suppose it all depends on your career aspirations.
Most of the team just don’t want the hassle of leaving the house.
My conclusion is that people don't want to engage with retrospective items that aren't first-order helpful. "Doing X solves problem Y for person ME right now" type things. Office hours smooth communication, but that in and of itself doesn't fix a problem -- it paves the road to fix other problems.
On point 2, about use of asynchronous communications - it probably is implied, but one key part of this is making sure that everyone in the team understands and observes the rule that you are expected to be asynchronously available most of the time, and should go dark only when it's absolutely necessary for your work. One thing I found helpful with distributed teams is making a status available on asynchronous channels called "Ping me on the hour" which is a way of saying, "I'm heads down, don't interrupt unless the world is ending, but I surface if necessary every top of hour."
"during core working hours".
See other point about establishing boundaries between work and personal life.
It is helpful to establish expected contact/response timings, such as:
- email - async. checked a few times/day. turn off notifications
- slack/chat - async. notify of direct messages & high priority channels, other items checked periodically
- phone/voice/video calls - synchronous. only for things that justify immediate interruption. Will respond with at least a "What's up?/In a meeting/etc." unless completely unavailable.As a result, our in-person work situations have never been so quiet (outside of lockdowns). The value of in-person is thereby seemingly perceptibly lessened. Are we losing or recouping the value of that serendipitous spark of collaboration that executives wax poetic over? (Was it ever a thing?)
It's why I'm a large proponent of remote work - outside of lunch and meetings, my work experience compared to one of those (IMO bleak) environments is largely unchanged.
Working in an exciting and lively office is the ideal in my opinion, but it's hard to stumble into those - I feel like these days by definition the people who make an office a great place are the same people with the ability to control their experience i.e. choose remote work. The ones who make offices bleak are the same people who force others/ must be forced to go in to be productive haha
(The downside to that arrangement for me, since I was responsible for the entire group, was that a work day spanned the entirety of the hours I was will to be awake. One soon learned to be brutal about blocking out non-work hours during your local usual business hours so you could accomodate the 5 and 6:00 AM calls that required people from Eastern and Western Europe, and the 8 and 9:00PM calls that got Asia, Singapore and Australia on board. We tried to keep individual teams from being constituted from more than 2 continents just to keep some sanity in people's lives).
Remote work has finally made it possible for me to be better at synchronous collaboration with others (edit: changed from "pair program"). Rather than being forced to work in a distracting open office, I finally have a private office.
In the past, conversations about code tended to only happen asynchronously during code review, but now we are having them while work is in progress and for code review and it is a lot more productive for us than asynchronous. When you do a synchronous code review, you still need to put in review comments so that others can understand what is going on asynchronously. These comments won't be the full conversation- instead they will be a summary- sometimes you will end up omitting useful details, but it reduces the text overload of asynchronous.
In the past being in an open office environment meant that collaborating with someone always risked being rude- disrupting others with our conversation. This would sometimes be handled by using a meeting room, but this still isn’t as good as just both of us communicating from our offices.
For synchronous remote work It’s crucial to still work with people in similar time zones.
I'm pretty sure that by default remote work with a low level of face time leads to lower levels of psychological safety.
I've tried it a few times and it's like trying to read the same physical book at the same time with someone who's a lot slower or faster reader.
> Every meeting should create an artifact (ideally, a shared document or at least a record).
I have come across this sentiment often but there is no point in creating new artifacts just to record a meeting. What if the meeting was useless and nothing came out of it? Please do not create a document for this meeting. Such records only create an illusion that you are not leaving out those who could not attend the meeting, but creates mountains of documents or records which would be impossible to navigate in order to draw any conclusion later on.
When you schedule a meeting, you create a wiki page named like "2023-01-02 Fooproj UX Meeting with Marketing", and include the URL in the calendar invite.
If there's a written agenda, it goes into the wiki page, in whatever state it's in. If someone is typing notes during the meeting, it goes into the wiki page, in whatever state it's in. Someone might screenshare the wiki page during all or part of the meeting. If there's a meeting video recording or videoconf/calendar SaaS page, the URL gets put in the wiki page. Anything bout that meeting that does get captured somewhere, can be gotten to from that one wiki page, so info not lost.
If no info at all ends up being captured around the meeting, then the wiki page might only ever be a title. But even then, it's still something to wikilink to (like `[2023-01-02 Fooproj UX Meeting with Marketing]`), when referring to the meeting, such as citations in design documents and project plans.
(Note: This works if you have a policy of "everything goes into the code repo or the wiki". But if you're thinking of the wiki as yet another of countless SaaSes where people are dumping write-only stuff that no one will ever find, then adding to that mess won't seem useful.)
These are the kinds of wiki pages I come across when I'm searching for docs that are actually useful. I dont think anybody reads them.
That isn't to say that there aren't other documentation artefacts that should be created as a result of the meeting (JIRA tickets, a wiki page explaining a particular feature), but they shouldn't ever take the form of "2021 June 23 meeting with marketing".
The latter has avoided countless hours of bikeshedding, or so I'd like to believe.
I might be a huge cynic, but that seems to me to be the #1 reason to create a post-mortem document to explore how to avoid another meeting that was a waste of time like that.
If the meeting was useless because the participants weren't prepared, make a note to hand out preparatory notes beforehand. If the meeting was useless because everybody shouted over each other, make a note for more moderation. If the meeting was useless because no one had political power to follow up on any decisions, cancel the meeting altogether.
Having a meeting that goes nowhere and then taking no time to publicly settle on actions as a consequence seems incredibly neglectful to me.
edit: I don't think every meeting needs its own document though. If there's a meeting, it needs to be associated with some document(s) in some way which will change as a result. If it isn't, it should be cancelled, imo.
But if you have a meeting and nothing about it was written down, who knows what was decided if it's not written down?
1) Every meeting must have an agenda and any material linked must be read before attending. You're wasting everyone's time by reading the material during the meeting.
2) Every meeting must create an artefact, otherwise you're just chatting with coworkers.
For non-sensitive meetings, we record to otter and then edit the transcript using highlights, marking to dos, etc. We’ve got an otter folder structure that mimics our other folder structures. We most commonly do this for document review meetings (I work for an NGO. We write a lot of grants.) This takes time but it creates good notes, allows everyone to be a participant in the meeting.
We have other meetings — like weekly target review meetings — that use Asana as the basis for capturing notes. This works well for things that are really tactical.
Unfortunately, the drive to "collaboration" has sprung up again in our senior ranks, who I think felt uncomfortable not being able to lay eyes on heads. Once again the remote folks are peripheral, literally. A lot of time and bandwidth is now wasted on arguing why it's necessary to arbitrarily be in the office one or three days per week, especially for people working independently on projects. Almost every leadership town hall has employees questioning why they agian have t sit in traffic and hunt for workspace while the closest colleague—the one they do real collaboration with—is actually a thousand miles away.