Fork me on GitHub
#jobs-discuss
<
2017-02-09
>
carocad14:02:00

out of curiosity: why are there so many companies against remote jobs? Is it because of legal stuff or more like “we dont want to deal with it” kind of thing?

nilrecurring14:02:44

@carocad if you have all the people in one place you can “check” what they do (as a manager)

nilrecurring14:02:28

I mean that you can physically see it, and this gives the illusion of control

nilrecurring14:02:40

Also, it’s much easier to trap people into meetings

nilrecurring14:02:53

For the same reason

carocad14:02:57

@nilrecurring lol. Though I always thought that if you are a company hiring Clojure developer, you would be a bit more open minded. Specially since the Clojure team itself is distributed.

carocad14:02:22

My point being that if you actually have to check everytime that everyone is doing “something” then you already have the wrong people for the job, right?

nilrecurring14:02:19

Agreed, but still this stems from process in companies due to having hired the wrong people for the job sometimes.

nilrecurring14:02:31

But for Clojure teams it may be a different reason: since they are usually small teams, having all the people in one place gives you a much higher communication bandwidth (as you can talk with each other at any time and coordinate, etc.)

nilrecurring14:02:15

Remote communication is a huge overhead. It may be reduced with some effort, but it’s really not like being in the same place all together (yet).

nilrecurring14:02:29

(Source: I worked remotely for years. Now I’m back in an office.)

thomas14:02:58

@nilrecurring I agree with the fact that remote comms are an overhead...

thomas14:02:23

but by allowing remote you can get other developers.. and thus increase the diversity of you team...

thomas14:02:33

and that is worth something as well IMO

nilrecurring14:02:52

I totally agree

thomas14:02:59

we can't all live in the same place for starters.

thomas14:02:25

I tried for years to get a job in London, remoting 2 to 3 days a week....

thomas14:02:37

no company I talked to was up for it 😞

nilrecurring14:02:46

Office and remote are two different ways of working, and they have different tradeoffs

carocad14:02:51

@nilrecurring I agree that being in the same place eases communication but, at least in my case, I also saw an increase in premature decisions due to that speed 😕

thomas14:02:56

(I used to live about 2h south of London)

thomas14:02:04

but I suspect quite a few companies don't see it that way...

nilrecurring14:02:44

That’s why my first answer to carocad was ranty about people wanting to have control 🙂

nilrecurring14:02:53

I think that remote working is the best thing, if the company is remote-first

nilrecurring14:02:23

So there are processes in place to handle communication and flow properly, and the remote worker is not “the exception"

socksy14:02:19

it can be also simply because a company is just not set up properly for remote. You can't have one person remote and the rest on site without the whole company being geared up for it, and for the most part most companies haven't got their process sorted for that. E.G. for some time at my last place a physical scrum board was updated every day, and there was no easy way to "call-in" for a stand-up.

nilrecurring14:02:05

socksy yep, that’s my point as well ^

socksy14:02:34

ah yes, i started typing before you sent that last message :)

thomas14:02:01

yes.. as someone mentioned it (somewhere). in a company with 1 remote worker everyone is remote.

jiri.knesl18:02:59

you can choose. Everything is written online and you can be remote. Or you can have physical kanban board, personal meetings, discuss product during lunch in a pub and so on. When you are in the second mode it's very hard to change to mode one. It isn't big difference between 10 people working remote and 9 people working in office and 1 person online. It is big difference 10 people in office and 9 in office and 1 remote.

sveri19:02:50

Write everything down is an advice I have seen in different forms, no matter if a business is remote only or onsite only. I think its a good advice in general. My team (9 people) writes down everything. Usually we discuss it as the whole team and write the results into the wiki. Or we form small teams to tackle problems (2 - 3 guys) who then write down the results. It works pretty well, after a holiday of 2 or 3 weeks I usually only ask if something very special happened and that question is more targeted at the social stuff, not related to our technical process. And mos of the time nothing special happened and I can just take a look at the task board and keep on going on.

tjg21:02:59

Interesting part where he conveyed what VC attitudes were like: > Ok, you tick all our boxes, except for this remote thing. That's new. And we just can't take the risk. We just pattern match. You don't fit the pattern. You might make it work, but we're one of the best funds; we'll pick another one, we have only that many board seats we can take.

nullptr21:02:28

"We want you to be innovative and game changing, and do everything just like everyone who came before you." :thinking_face:

fellshard22:02:57

It's the kind of thing that might be better as a team-level decision instead of a corporate-level decision. However, usually team structure seems to be mandated from the top down, sadly. Peopleware is a great reference for a more robust take on team formation; the agile movement itself is, under theory, more focused on this as well - allowing teams to select their own pragmatic processes as needed to solve problems. With respect to remote teams, the biggest constraint is on communication. In that case, your team can come up with practices or processes that alleviate communication strain. In some sense, highly autonomous subteams (CSP?) would greatly reduce risk; the difficult part is figuring out how to reasonably partition work so it doesn't separate into multiple full teams, each working on their own codebase. Or maybe that ends up being desirable. A project with solely remote workers will more likely need to delegate autonomous decisions to individuals - More assumptions made, more experimentation, more willingness to try crazy things - which also means more lost effort, and looser feedback loops. Tradeoffs, as always.