Comment by runawaybottle
5 years ago
What’s stopping it from being a no brainer at this point? This feels like one of those things where old school taxi companies just couldn’t see how fast stuff like Uber/Lyft was going devour them.
Remote work and distributed teams is basically like fate at this point. If our economy is prepared to build a whole car in different parts of the world and then ship it to the US, you better believe your little job tasks that can easily be sent in email is going to have to reckon with that.
I've gotten into remote work experiments (unplanned) and it hadn't been all rosy. The good things are huge cut on unnecessary meetings and great productivity but the bad things include much harder path to collaborate.
For example, if you are designing a very complex system requiring multiple participants then it's very very hard to communicate your ideas over video conferences - even when tech worked flawlessly. It's not because people are not able to articulate the ideas but there is a lot goes on in body language, facial expressions and quick back-and-forth exchanges over whiteboard. The high bandwidth of occupying same physical 3D space permits speedy iterations while low bandwidth constraints what you must express in given slot you are expected to express.
So, remote work doesn't work for all scenarios. It works well when everyone knows things fair bit, number of iterations during communications needed are small and number of ideas don't need huge bandwidth. It doesn't work as well otherwise. For example, early days of startup where the product is in embryonic state, everybody working remotely would not work out well. However, if product is mature and roadmap is well under control then remote team might work great.
Don't forget we've spent a lifetime learning and perfecting the use of things like body language in face-to-face meetings. You can't just switch to video conferences and expect it to be flawless without practice. But if you do it a lot, you learn when you need to verbalize things you'd rely on conveying non-verbally in a face-to-face meeting, such as when you don't quite understand something.
I supervised an entire PhD remotely many years back. We made it work, and learned as we went. Over time we got better as expressing confusion, double checking understanding, and all those sort of things where we use non-verbal clues in face-to-face meetings. It worked, but it wasn't an easy path at first. But there was an unexpected plus side - I'd learned to vocalize my doubts and confusion better, and to double-check we're on the same page. And so ever since I've found I'm more effective in face-to-face meetings.
> But there was an unexpected plus side - I'd learned to vocalize my doubts and confusion better, and to double-check we're on the same page.
That's funny but it reminds me of my relationship in the beginning. We didn't speak each other's native language fluently. Unexpectedly, harder communication had the effect of being clearer when expressing ourselves, and double-checking assumptions before reacting. It ended up very healthy.
And yet, startups have been started as fully remote. Stack Overflow, Zapier, Seeq, just off the top of my head. And there are countless of successful open source projects as well.
Personally, while I agree that the bandwidth is higher locally, I don't agree you are prevented from expressing what you wish by communicating remotely; it just takes a bit longer, which is more than compensated by the time saved on other things.
I work at a fully remote startup, after working at a mostly remote startup before.
Having an easily accessibly video conference software, committing to getting employees good headsets, and enforcing videos on/1 person per screen makes collaboration very easy.
----
The only thing that's missing is whiteboarding sessions (which seem to be more about fun than actual productivity). Instead, we typically ask a single engineer to write up a proposal doc then have everybody comment on that.
It requires a bit more lead time - write up, feedback, then finalization. However, the actual developer time is significantly less. One developer doing most of the work, with others chiming in periodically.
2 replies →
It sounds like your taking your existing workflow and trying to virtualize it, this always fails. Remote work (especially with timezone differences) requires text based asynchronous communications, just look at large successful and international OSS projects, they thrived with mailing lists and IRC and this wasn't just because of bandwidth limitations.
IME unless your a particularly good teacher then your whiteboard isn't as high bandwidth as you think anyway. In face to face meetings everyone will just smile and nod because you have to go away and dig into the details to find issues. Put it in a graphviz drawing with the accompanying text and you'll get better results.
That is just the inability of the participants to think more than talk. For example Lisp requires more thinking, or chess requires lots of thinking.
The tasks are not the hard part. Alignment is a lot easier when you’re all close. I went from a distributed team (4 offices spread between EU and US) to a team that’s all co-located. The speed and quality of alignment is miles different.
There’s stuff we outsource (easy to describe tasks), but the stuff that needs tight iteration loops is so much easier when you can just get up, walk a few meters, and talk about it.
The Linux kernel is developed remotely. I'm tiring of hearing cat food delivery startups pretend it won't work for them.
The Linux kernel is willing to sacrifice the time of individual developers on the altar of project efficiency. That works for the Linux kernel because there are a huge number of prospective developers, and on balance the project doesn't generally care if any specific developer wastes some time or duplicates some effort.
That, by itself, isn't an argument that remote work for a given company will work.
1 reply →
Linux kernel is also famous for a ton of input coming in, of which not a small percentage is discarded. It's quite an expensive model. For any 'normal' software project you have single teams responsible for single features. Not tens of teams competing who gets to create the version which gets accepted.
I'm not saying it's not a good idea to have competing delivery teams. But it's quite expensive.
The Linux kernel as a whole is developed by people who rarely see each other in person, but there are several caveats that make it hard to generalize from that.
* Individual parts of the Linux kernel are often developed by people who do work together in an office (e.g. I used to sit with a bunch at Red Hat).
* Top-level Linux folks do meet in person fairly regularly, especially at LF events.
* Collaboration via email etc. is the primary workflow for the kernel, so there's no in-office cabal that has to learn new habits (and likely will resist doing so).
I'm also tired of hearing how silly startups can't do remote, but I don't think I'd hold up the kernel as an example that they could/should emulate.
A significant part of it isn't though. For example, engineers writing a device driver for a piece of hardware are most likely sitting with each other and near the HW guys.
What is your argument? Those sound like two very different types of product development that I would expect to work very differently in nearly every conceivable way.
5 replies →
I really think that in the future people will use something like holoportation[0] to work at home or remotely across the world. Because like you say sometimes it makes sense to be present with a person to accomplish a task. It is very hard if they are trying to describe something when it would only take half a moment to visually look yourself and understand the direction the person is coming from. Holoportation looks very neat I really hope I get to try it one day. [0]:https://www.youtube.com/watch?v=7d59O6cfaM0
When I'm retiring, +/- 30 years from now, I'm going to put on my Virtual Reality glasses and never leave the house again.
1 reply →
I’m sorry if I sound harsh. The problem is not a matter of better or worse “alignment”.
It’s just poor quality planning and execution.
Your team is just improvising, figuring out as you go, what is exactly that you need to build.
It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...
> It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...
That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:
> Individuals and interactions over processes and tools
> [...]
> Responding to change over following a plan
While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks).
If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management.
[1] https://agilemanifesto.org/
1 reply →
> It’s just poor quality planning and execution.
Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.
You get 11 weeks until Demo Day. If you spend it learning how to plan better you've already lost.
1 reply →
Training new employees is still quite a bit lower friction with on-premise work. This obviously depends on the kind of work you do, but in my case the work is sufficiently eclectic that even very smart and experienced people tend to take a long time until they have a good level of understanding of the problem domain.
That doesn't mean I'm against remote work, by the way, we do a lot of it. But we need to be realistic about its limitations.
Easy, you have a mandatory 2 week in office period for training and then move to off site. Whichever employee that will be training you will also come train you. The company can even pay for a coworking space that's in between or closer to trainer so they don't need to migrate for the training.
Training a junior dev is going to take a bit more than two weeks.
I'm convinced that remote work is something that works only for some people and some kinds of tasks. Anything that requires a lot of coordination sucks doing remote.
2 replies →
This will never work but if you can do it more power to you. Two weeks is totally insufficient. Then again training is a sucker's game. When they get good, I can just hire them, and not pay anything into training.
Remote work can be very effective but it's not for everyone, or at least not all the time.
We have a liberal remote working policy to the point where one of our team works from home almost all the time, whilst at the other end of the spectrum there are people who prefer to be in the office almost all the time, and then everything in between.
I fall somewhere in the middle. A day a week from home, particularly one with few or no meetings, can enable me to get a huge amount done. But I live alone so, whilst I am an introvert, I am not a misanthrope and need to ensure I get enough social contact.
Multiple consecutive days working from home can leave me feeling quite depressed and demotivated. I certainly wouldn't want to do it all the time.
I guess some people are more fit for remote work than others. I certainly miss day to day interaction with people, too.
I've had to do remote probably half dozen days in past couple of years. Here are some things I've observed:
1) As someone who do not regularly work from home, simply I'm not equipped well enough. I don't have extra monitors sitting around at home to hook up my laptop to give myself multiple monitors, for example, so I'm forced to work in a suboptimal setting.
2) Meetings can get tricky (Note: I also do language interpretation) I have mitigated this by hooking up my recording gear, which actually worked pretty decent.
3) Where there are clear objective for the day, it is relatively easy to handle. For anything other like supporting people who managed to show up at work remotely, was certainly harder part.
4) Everything becomes distractions. Something as simple as getting a cup of coffee. In other word I have to make one myself (or go out and get one myself) where at office I would have access to one close by or walk short distance to buy one.
I would probably sustain... maybe a week of remote at the most. Maybe regular remote workers have designed their life to work with it but certainly not for me. (Again, this also depending on the nature of tasks I need to get done.)
Except I don't have a suite of class A glassware, a dewar, liquid nitrogen, and semi-infinite fridge space at home nor have the infrastructure to provide them to all my people
I do miss that stuff.
Well for one, video calls don't really work, even with excellent internet connection. A lot of time is spent just trying to understand what the other person is saying and asking them to repeat or get closer to the mic, or mute themselves because we keep hearing their background noise.
Most importantly, distractions from family members and lack of a boss looking over your shoulder means most people's productivity will be perhaps 20% of normal.
> Well for one, video calls don't really work, even with excellent internet connection
I felt this way for a very long time. Then I switched jobs and realized (1) there are some very good video conferencing tools that work even on 1 bar of LTE (2) a small investment in a camera/headset/microphone goes a long ways.
Most family members can learn to not disurb -- but I do agree that young children are a problem.
Call quality is easy to solve with decent hardware, a quiet office and proper muting (I see this work all the time with 10 to 100 person meetings.)
Yeah, and there is definitely a huge need for tooling remote-first teams, other than yet another chat clients.
We use your standard common video conferencing and screen sharing apps (Skype can do this, but I’m sure there are better options) if we need a quick chat or need to pair program. People just ping each other and agree on a time to sync up (usually immediately if possible , otherwise after your standard human bullshit like ‘grabbing some lunch first’). Its felt pretty natural, but since we are a fully distributed team, we had no choice but to get over the conceptual hang ups of not physically being near the other person.
But I agree, better tools that integrate communication with project management is going to be a good space to try to build something in.
Certain things are just a lot easier when you are together. I have never had as constructive discussions online as I have had when gathered in a room with a whiteboard.
What kind of professional work lines up with the assembly line paradigm?
Ironically am sitting here waiting for some upstream fixes from a team on the other side of the planet before I can even start my work this week, it was meant to be done a few days ago. Perhaps some things are more assembly line than you might imagine.
Well, I don't work remotely but I am waiting on a task to be completed by another team for about a week now. It's something that can't possibly take more than one hour or so to be completed, and I even talked to them in person before submitting the task. That didn't change a thing about their deadlines.
When this happen do you literally just hang out waiting for that? Or do you work on other miscellaneous stuff in the mean time?
1 reply →
Web development
What kind? Wordpress, or large platform with many different features serving traffic at non-trivial scale (not necessarily google scale, but a few tens of or a hundred thousand requests per second)?
1 reply →
For remote work, pretty much anything that's not done on an actual assembly line.