Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab's Guide to All-Remote

about.gitlab.com

Post reply on HN
Print view View original

231–240 of 254 posts

Re: Gitlab's Guide to All-Remote

#231

Post by WJW »

yakshaving_jgt wrote: post #22
keiferski wrote: post #14

Earlier quoted context omitted.

Salaries are in large part determined by local factors: cost of rent, food, gas/public transport, tax rates, etc. There is no "universal" salary for a particular position. Developers in San Francisco are not paid 3x of those in Des Moines because their skills are 3x better. Their salaries are higher because living in SF is more expensive. If the cost of living in SF were lower, the salaries would be lower, too. If an…

Wouldn't that be a good thing though? Isn't that an important part of Capitalism? Competition?

Good for who though? It's certainly not good for the people competing. Check out Peter Thiel wanting to be the monopolist: https://www.wsj.com/articles/peter-thiel-competition-is-for-...

Re: Gitlab's Guide to All-Remote

#232

Post by danielvlopes2 »

We've received a ton of questions on how to manage teams remotely this week as well. We decided to make our eBook on "Managing Remote Teams" free, to help ease the transition for teams moving to WFH.

This 60+ pages book is the result of months of research and interviews with successful remote companies (it’s usually a part of our paid product). We collected tips on pretty much everything, from onboarding to communication best-practices, to tools you should consider.

https://knowyourteam.com/m/managing_remote_teams

Re: Gitlab's Guide to All-Remote

#233

Post by pfranz »

motohagiography wrote: post #212

Regarding the principles: >> 3. Writing down and recording knowledge over verbal explanations. 4. Written down processes over on-the-job training. 5. Public sharing of information over need-to-know access. 6. Opening up every document for editing by anyone over top-down control of documents. 7. Asynchronous communication over synchronous communication. These remote work principles have the direct, or side effect of b…

> I see this today, where I make an email request, and the person follows up with a phone call, then misrepresents what was agreed to on the phone to others.

I know this misses your point, but both at work and outside I've gotten into the practice of emailing immediately after a phone call with a summary of the phone call. It's kind of a lawyerly thing to do, but it's a contemporaneous documentation of the phone call you can point to later.

Re: Gitlab's Guide to All-Remote

#234

Post by waste_monk »

hobofan wrote: post #112
rdsubhas wrote: post #100

How do people whiteboard remotely? This is a big problem for many development teams. Sometimes you just want to open a blank whiteboard and scribble some boxes and brainstorm or troubleshoot some things. The whiteboard is an inseparable part of nearly every meeting. And no, remote "canvas" whiteboards don't work. They end up looking like this: https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNf... . Is there…

I actually found remote whiteboards to work quite well when used with a proper pen tablet (like a Wacom Intous). Downside of that is of course increased cost, as equipping everyone with one of those isn't that cheap. It also takes some time to get used to using those, but for permanent remote situations this is about as close as you will get to in-person whiteboards. A less sophisticated variant that works well for a…

>Downside of that is of course increased cost, as equipping everyone with one of those isn't that cheap

I bought a Huion drawing tablet (H610) which was relatively cheap and works well enough for most cases. No screen on the tablet itself, but you quickly get used to drawing while looking at the screen (there is a sort of halo surrounding where the pointer should be, so you're not using it blind). I can see it working quite nicely for whiteboarding.

Re: Gitlab's Guide to All-Remote

#235

Post by wpietri »

minipci1321 wrote: post #28
wpietri wrote: post #2

I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion.…

> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. This is not an implication by all means. Low-skilled not very well incentivized junior team (let's call it so in absence of better terms) needs more/most "in-person collaboration". Team of experts to whom the goals and the overall vision have been conveyed, who knows how to put it to practice, will give th…

That's one thing that can happen, but it's not the only thing.

What you're describing is a push model. Somebody on high creates a vision and assigns goals. Workers are just seen turning that into outputs. It's a common way to work, especially in "known problem/known solution" projects, but it has its flaws. See Cutler on "feature factories", for example. Or Blank's "Four Steps to the Epiphany".

But what if the solution or perhaps the problem is unknown? Push systems don't work. Instead, I favor cross-functional teams that pursue outcomes (as opposed to outputs). In that context, the vision is a living thing, created collaboratively, as is the plan. Problems are explored, and solutions discovered. The speed at which a team can learn and test solutions is limited by communications latency.

And of course experts aren't born that way. Even if you're in a "known problem/known solution" space, sustainable companies need to find ways to turn novices into experts. Again, that's about learning, which does not work well in high-latency environments.

Re: Gitlab's Guide to All-Remote

#236

Post by wpietri »

vaylian wrote: post #71
wpietri wrote: post #2

I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion.…

> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion. But even when you work in the same building you still have to find a time slot that fits for a meeting. Of course, you can also drop by the other's office and hope to find them ready for a chat, but there'…

> But even when you work in the same building you still have to find a time slot that fits for a meeting.

That is definitely not the only way to work. A cross-functional team sitting together and focused on outcomes can be much more organic than that. Think of the writer's room for a show, for example. That can sound weird, but Devin's "Artful Making" does a good job explaining the parallels between knowledge work and how theater/TV/movie people work.

Re: Gitlab's Guide to All-Remote

#237

Post by Thorentis »

sweeneyrod wrote: post #141
Thorentis wrote: post #114

Earlier quoted context omitted.

Ouch, even within Australia they have large discrepancies between capital cities. One of the reasons why remote work appealed to me, was that I was hoping to escape the unfair wage difference between cities. The fact GitLab maintains it despite not having to pay for real estate in the city you work from is totally unreasonable. Same work, same pay. I'll never apply for them.

Is it unreasonable for a random Indian company not to pay the same wages as one in SF (assuming the work is the same)? What about if both companies are consultancies doing projects for Gitlab? If differences in those cases are fine, why is there a sudden change if the employees of the above companies start working for Gitlab directly rather than through a proxy?

I'm not sure what comparison you're making sorry.

But I think that if GitLab is able to pay somebody in the US one wage for work, and they hire somebody equally qualified in Australia that will be producing the same work, they should be paid the same. Well, it's up to GitLab to decide what they're paid, they shouldn't be forced to pay them the same, but I wouldn't work for a company that didn't.

I'm also surprised GitLab are away to get away with it with all the fuss made recently about discrimination. Is this a form of geographical discrimination in terms of unequal pay?

Re: Gitlab's Guide to All-Remote

#238

Post by wpietri »

mic47 wrote: post #125
wpietri wrote: post #2

I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion.…

> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. First, it's high latency, not extremely high latency. Second, it has huge advantages: 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too. Everyone get more done. 2.) With asynchronous communication, you are not interrupted by communication, you can d…

It sounds like you're focused on maximizing output. I'm more interested in maximizing outcome.

As to high vs extremely high, I'm not sure arguing over relative terms is useful. But just so it's clear what I mean:

If I'm working in a team room with colleagues, my average latency between request and response is, say 15 seconds. But in globally distributed remote work situations, a much longer lag is not uncommon. E.g., when I was working with European colleagues, it was typical to get a response the next working day. That's about 5000 times longer, which seems pretty extreme to me.

Re: Gitlab's Guide to All-Remote

#239

Post by philshem »

ukyrgf wrote: post #205
philshem wrote: post #52

Earlier quoted context omitted.

I use the "push to kindle" browser extension for online content, which seems to work fine for this page: https://pushtokindle.fivefilters.org/send.php?url=https%3A%2... The content is sent to the Kindle via the email service: https://www.amazon.com/gp/sendtokindle/email Depending on your Kindle settings, you may have to set the FROM address in the push-to-kindle page.

If you just go up one category you'd see you don't need a third party tool: https://www.amazon.com/gp/sendtokindle

I had searched the Firefox Add-on catalog and the official tool has never shown up:

https://addons.mozilla.org/en-US/firefox/search/?platform=wi...

Interestingly, the link from Amazon, clicked through your link, is dead

https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/

Re: Gitlab's Guide to All-Remote

#240

Post by sleepychu »

sweeneyrod wrote: post #138
sleepychu wrote: post #44

Earlier quoted context omitted.

> Salaries are in large part determined by local factors Salaries should be a function of value produced amortized across the convenience and reliability of a predictable salary for the employee. Where I am sitting has no bearing whatsoever on the value produced and it is the primary thing that prevents me from pursing a job at gitlab. Also this argument ignores the side benefits having an enormous salary offers you.…

If you're refusing to pursue a job at Gitlab because it would pay less then the market rate where you live then the issue isn't that their salaries vary geographically but just that they don't pay enough in your area. If you you object even though they pay higher than your local market rate then you have a weird aversion to money that I don't see a reason for anyone else to care about.

I currently live in a major city but have plans to move to a lower cost rural area. If I did that while I was working at Gitlab they would slash my salary and reap my cost saving, do you think I would be generating less value for them in exchange?
Post reply on HN