Embracing Asynchronous Communication at Gitlab | Hacker News Reader

Embracing Asynchronous Communication at Gitlab

about.gitlab.com

140 pointsyarapavan44 comments

That's really impressive and insightful.

I've been working all my career (12 years) as a remote worker (freelancer for a couple years, then employee) and poor async communication skills is by far the worst and most omnipresent problem I've seen - mainly because as nobody sees who is doing what, allowing interruptions quickly lead to everybody constantly interrupting everybody. Having Hangout or Slack constantly ringing because three people want my attention at the same time is a sure way toward madness.

The lack of async culture also often manifests that way : a manager/lead/whatever sends a grossly imprecise demand as a one-liner email ; then developers ask questions about what the hell that person is talking about ; then the first person gives a few more details (the minimum amount) and concludes with "can we have a call? It would be simpler".

I think the main problem is that many companies, while they want to try remote work as it "attracts top talents", don't have the proper culture for it, which is, ultimately, the culture of writing. Not only being able to type down the words you would have spoken, but to actually perform thinking writing - which implies to draft a few ideas, then read them, modify them, change their order, remove some, add others, and only when you're sure you've nailed the issue, hit send to share it with everyone.

The typical non-remote employee won't want to do that and prefer to throw vague ideas in the room so everybody contribute to making them clearer at the same time. I'm biased of course, but I think this is highly inefficient.

This matches up so precisely with my experience it's scary (and a little sad).

Everyone is so quick to "have a quick call" that inevitably sucks 20 minutes out of everyone's day because (and I've heard this verbatim a dozen times in the past 6 months alone) "it's too much to type out" or "it's easier than sending an email," but then wonder why nothing gets done when all the dev tasks are eighteen 20-minute segments of work instead of two 3-hour segments.

To your last graph, I think there are absolutely times where this makes sense, but "business owner has a new feature request for a large existing product" is not one of them.

Also they wonder why they all forget all the things they said in their 20 important meetings a day.

This. I try to avoid calls as much as I can, it's so much more effective to have a written transcript, whether it's in Slack, email or Jira.

It's not just that people don't know how to write. It's been my experience that many people also don't know how to read properly. If you try to make a nuanced argument, many people will read what they want to read and completely misunderstand you. Or sometimes they will complain "why are you writing so much? I don't like to read".

It’s not even that. People don’t even try to read. Ask two questions in an e-mail, and get an answer to the first question, only. Every time.

You have to adapt. Ask the single most important question as the first sentence. Don’t write a lot of text after the question either – it would only make people feel they can put off reading it, and therefore put off answering the e-mail. Don’t ask an easy question later in the same e-email (people would answer that question only, and ignore the rest of the text). And so on.

Sure, that might work for simple questions. But sometimes you really need to ask a nuanced question, and then what?

I’d ask the question first, then explain it. Possibly ask the same question again after the explanation. If the question could/would be misunderstood without the explanation, I’d change the question to instead be confusing without the explanation. But you really have to work hard at being able to explain enough things with a very short text.

> Ask the single most important question as the first sentence

Exactly. And also, NEVER ask the questions you'd like answers for on Friday afternoon. Or any afternoon in general.

If it doesn't say what it wants in the first sentence or two, I'm hitting delete, unless the email is from my boss. And I currently do not have a boss.

"but to actually perform thinking writing" <- This is well articulated, thanks for framing this in a way that is widely understandable.

We have a guide that covers top attributes of great remote hires. This will be merged into that guide soon: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

I found this video very helpful:

https://www.youtube.com/watch?v=vtIzMaLkCaM

Thank you for sharing this excellent video.

I work in academia on the “business side” in IT. Interacting with faculty is notoriously frustrating.

Around 23:00 in this video the presenter offers a rule of academia that “nothing will be accepted as knowledge or understanding until it has been challenged by someone competent to challenge it.”

I found that immediately insightful and instructive.

This is what I found too when I ran a team. I started having to manage remote employees and found out that it was vastly harder than I imagined. The whole team had to essentially train ourselves on how to handle remote workers. We did this by forcing each of us to be remote part of the time, so we could learn what worked and what didn't.

It's sad really. I worked at another company where there were a few remote workers that all ended up getting fired for performance reasons. When I pointed out that it seems that all remote workers have performance problems and maybe it isn't them, management looked at me like I was fool, and clearly if the remote workers just "worked harder" it wouldn't be an issue.

I like your description. I've complained that my current company likes to throw people at problems, instead of solutions. Sounds like writing might be the root issue. Documentation is not a priority, and if there is documentation; nobody reads it. This means any emergency has to have half a dozen "experts" on a meeting to resolve the issue. It's very frustrating.

Video creation to communicate status in some cases! That would take more time to consume than text. Times the number of people consuming.

But standup is in Slack.

It seems like there's something unspoken here (pun intended). What are the organizational reasons for the different modes? Are some kinds of communication discouraged, thus forced to be in recorded videos?

We use video at GitLab. Lots of it embedded in our remote management course through Coursera, for example: https://www.coursera.org/learn/remote-team-management

We also have GitLab Unfiltered, where you'll find some tutorials, recordings of sync meetings, etc. https://www.youtube.com/playlist?list=PL05JrBw4t0Kq7QUX-Ux5f...

We have an Efficiency sub-value called 'Write Things Down' which helps to explain this: https://about.gitlab.com/handbook/values/#write-things-down

Video has some pros (extra visual context, more engaging, more human) and cons (longer to consume, harder to search, typically creates double work having to record + document textually). Each company will likely view mediums slightly differently.

I did not know you had these courses in Coursera. Great to know, I’ve signed up!

My personal experience at GitLab:

There's plenty of videos, but the really cool thing is that basically everything has a transcript, or meeting notes, or an agenda. And I think this hits a really nice middle ground that works for different types of people.

Personally I am very fast at reading/writing, and I focus better and understand better when reading, so I skip most of the videos and calls and just read them instead. But for some people they really enjoy the video side of things, and that's cool too. Most of our meetings/calls are optional and it works well to cater to both types of people. Our source of truth is ultimately what's written down (i.e. in an issue) and how we get to that point is flexible.

I really like it.

I think a good middle ground here is audio, with transcriptions.

I'm making a chat application for this called heysync, which is similar to slack or IRC, but with embeddable auto-transcribed audio messages as a primary feature. You can type messages out as normal, or send audio, and people on your team can scan/read it, and decide to listen, or listen by default. It's more human than text, way less stressful than sync video meetings, and enables asynchronous conversations over several days or across timezones.

I'm nearly done building a first version, so if anyone would like to hear more or try it soon, there's a website and mailing list signup at: https://heysync.chat

imessage has audio snippets built in, this sounds a lot like that.

have you had any of your friends/family try it out yet?

Thanks for asking -- we've played around with it a bit! Mostly as tests as features get implemented, e.g. live-playing incoming audio, or playing forward through multiple messages at a time, but it's kind of addictive so we've ended up just chatting sometimes too.

Heysync definitely shares concepts with iMessage's audio snippets (or WhatsApp's, Signal's, etc.), but automatic transcriptions let you decide to read or listen at will.

It's also different in that it's got features similar to IRC or a slack-like, so channels and DMs, markdown and code highlighting support, and soon enough reactions, threads, bots, etc. Beyond that, I'm also working on adding built-in support for "structured" meetings, like daily standups, because that seems to be a major use case.

Fantastic. Bookmarked, and about to share w execs at my current consulting gig. (I've been doing web-related work since 1998, with more than half my working days remote, and this is among the best resources I've encountered.)

Awesome, thanks for sharing!

Consider this draconian set of micromanagement rules, combined with GitLab’s deeply unfair way of recalibrating salary based on where you live (even if you already work there, creating value for the company in a way that reflects your current salary, it will still get adjusted if you relocate, regardless of whether the value you add stays the same).

GitLab sounds like a truly awful place to work.

Considering that every company in the world sets salary based on where you live, is there even an argument here?

I just took a remote job that indexed to Bay Salaries and does not take into account where I live.

Maybe that won’t last forever, but it exists.

I think if tech work really all becomes super distributed , the companies will still be competing no matter where you live.

So you won’t get Bay Area FAANG salary for working remote from some smaller Midwestern city at a FAANG, but you will get a lot more than you would at the tech jobs headquartered in your city. Kind of a win win for employee and tech company

I have never had a company adjust me down, based on where I live!

I mean, wtf is it to them if I choose to commute 2hrs each way to and from work to save money? Why should they dock me for how I spend money that I earn?

> wtf is it to them if I choose to commute 2hrs each way to and from work

No one is docking people for living farther away and commuting into the office. The salary adjustments are for people who live in areas with different costs of living.

The lower costs of living in the suburbs are one of the many reasons people commute so far.

So, by the same logic, they should be payed less.

Your salary is roughly equal to what you're willing to take to perform the role. If you move between cities with different costs of living, that number may change.

Don't think of it as "adjusting down" (since it goes both ways). Think of it as a different supply/demand curve. At least they're transparent about it, although I suspect some ICs get bumped up or down based on their performance.

If you're a remote working who has been living and contributing from NYC for 5 years, what is the justification for a company giving you a pay cut because you move to Kansas? Your contributions remain the same. The responsibilities remain the same. The costs incurred by the company remain the same. You may even keep the same hours by adjusting your working hours in the new time zone.

I don't see a justifiable reason for it either direction. Living in an expensive city is a choice, now more than ever with more and more tech-focused companies moving their devs fully remote.

It's not about costs, it's about supply and demand. If you move to a lower cost/tax region the amount of money you're willing to take to do the same job is lower.

You can say "no" to a paycut. And they can say "no" to keeping you employed at the same rate. Eventually you'll settle on an equilibrium - the intersection of the supply/demand curves.

It’s not about supply and demand - that makes no sense. That only makes sense if the company’s alternative is to hire a new employee at the Kansas City wage rate - but that option was never on the table. The choice is between retaining an existing employee that you’ve been happy to pay a current NYC wage.

If you could have hired a Kansas City employee to do the same job for less pay, that would have already been reflected in the previous salary negotiations when you instead decided it was worth it to pay more to hire the NYC person.

That person choosing to live in a different location has no effect on anything - everything that led you to the original choice to pay them a higher wage remains true.

People are generally talking about working in different time zones, but proximity to work is one of the best predictors for job satisfaction and turnover.

You're talking past each other.

Where someone is located in the world is irrelevant to the value they are producing for the company, so what justification does a company have to adjust a remote employee's salary if they move?

I just gave a reason. Turnover and job satisfaction is good enough of a reason for some companies to pay proximity-based subsidies for rent. When we start talking about different time zones, then the reasons start piling up.

Every company in the world does not adjust your salary if you move after having been hired.

Forcing salary adjustment for relocation after the employee works for you is totally different. There’s no “market wage” at that point - there’s no such thing as “another candidate already with X years of internal experience” working at your current wage. The person’s current wage is, by definition, the market wage. Reducing it to match a competitive rate for new hires in that geographical region does not make sense, you’re telling someone paid market wage (for them, for the value they currently provide you, which is not a function of their location) to suddenly take a pay cut because a theoretical new hire from that region (who is not a substitutable alternative for this person) might take a lower wage.

Your objection makes no sense.

Market wage is not only a function of value someone provides but also of their alternative opportunities, which are a function of location.

Salaries are not often a function of an individual’s alternative opportunities. For example, salaries are extremely durable even in economic downturns. A person might have children and become “locked in” to a job because of sudden family financial obligations, decreasing their ability to job search, pass interviews, or take a risky move. Yet that doesn’t lead their employer to suddenly cut their salary because an external life factor such as family status (which is no different in kind from geo location) changes the landscape of opportunities they could consider.

What you are describing is a part of what is sometimes called "wage stickiness". It is, as is pretty obvious today, frequent but not 100% universal phenomenon.

I too have been put off by Gitlabs endless handbook.

It seems like every interaction has a script or a page to follow. Why even be a human at that point?

Calling it micromanagement is unfair, I think. To me, it looked like a guide, not a set of hard rules.

Because middle-management-types I'm sure will understand that nuance and enforce the rules in a non arbitrary or capricious way. /s

Reply on news.ycombinator.com