3 ms·
My best experiences working remotely—both during the pandemic and with folks in other locations before that—has been with research-oriented work. The reason? We
by tikhonj 3y ago
My best experiences working remotely—both during the pandemic and with folks in other locations before that—has been with research-oriented work. The reason? We had the time and space to work and communicate the way that made sense to us. We had plenty of shared pair/group sessions to work out design ideas and experiments, iterate on the system, debug trickier issues... etc. Everything else we could do well asynchronously. Since this was longer-term, more speculative work, we didn't have to worry about tickets or product/management breathing down our necks every day.
On the other hand, the projects that suffered the most were the ones where folks had less scope and autonomy. If you can't unilaterally make decisions for anything that spans more than a day, and you're forced into some ticket-oriented process where everyone has "their" task to do, communication naturally suffers. If you're all in the office, there's a bit more slack to talk quickly and informally outside your immediate silo; remotely, this takes more intentionality, so the friction imposed by your culture and process has an outsize effect.
So my conclusion has been, pretty much, the opposite: remote works better when people have real scope, independence and autonomy. If engineers and small teams can make decisions over longer time-frames, they'll have the space to adapt and work effectively. They might need somebody to set the example or foster the right habits, but it's fundamentally healthy and effective. The frictions with remote work come up when it's thrust against a less flexible culture that makes it harder for folks to adapt.
- majormajor 3y agoI think you're using different phrasing to describe the same effect. Autonomy and the org knowing what it wants to do/needs to do go hand in hand. In your long-term speculative research oriented work, you had autonomy because you knew what you were working on - not what it was in terms of tickets per se, but it sounds like you knew your scope and your objectives. At 10+ person org sizes, most people can't have long-term scope and autonomy if the management don't know what it wants/needs, since they're just going to change their mind in a week or two. Once those decisions are made you can start delegating responsibility for execution. The easy thing to do is to blame this all on poor management, but I think that's too pat. I think figuring out the best way to use a team of 20, 100, 1000 engineers to accomplish business goals is just an incredibly hard problem... and one that's often an ongoing, Sisyphean task, where high-bandwidth, low-latency communications are incredibly useful.
- extr 3y agoI agree. Research is ideal for remote work, since you are effectively your own manager and by definition there is no specific vision that needs to be worked toward - you are discovering that vision yourself. It's the literal ivory tower. In my experience if you give non-R&D engineers and small teams total autonomy they will all end up building great solutions to problems that are slightly different than the problem you actually needed solved. > I think figuring out the best way to use a team of 20, 100, 1000 engineers to accomplish business goals is just an incredibly hard problem... Agreed, don't mean to downplay how difficult good management is. I think the key thing I've realized is that in a remote environment, bad management is so much more obvious and detrimental to the employee and organization. In office, if your manager doesn't communicate vision/objectives well you can always tap the shoulder of the guy next to you, or discretely pick your skip's brain in the break room. The rest of the organization can pick up the slack. But that's much harder remotely.