Remote Work and Productivity


#1

Are there any remote workers in here? Let’s talk about our experiences working remotely or even preferences in working remotely or in the office. Do you think you are more productive in the office than working at home or in a coffee shop?

Would be interested to know if there are CEO’s out there who would prefer their employees to be in the office, and know why they would prefer it that way.


#2

I’ll just share my experience here working remotely from France for Reverb in 2011 - 2013.

I was employee #1 there, so really, it was just Greg Bell and myself to start with. We had worked together for 2 years already so we knew what to expect from one another - he especially knew what to expect from me. :wink: Having 15-30 minutes catch up everyday and communicating async via Email + GDocs + Github was pretty efficient.

One year later, the team grew to 4 engineers in Vancouver, 2 remote in the US and 3 remote in France. Chris Edward was our project manager and he did a terrific job at coordinating all that and making sure that there were well defined tasks in the backlog ready to pickup by engineers.

We were really efficient in my opinion. Most communication was async, there would be almost no interruption and we would make the most out of our 15min stand-ups: 9am in YVR and 6pm in France. Github obviously played a key role there to enable good async communication. I believe that the time difference played to our advantage as it was “forcing” async communication to happen. I believe that we were using HipChat at the time, but with only half the team available at a time, no decision would be made over chat.

Now, one thing I’d like to highlight is that there is a wide variety of “remote” work:

  • working from home from time to time
  • working remotely (all the time) in the same timezone
  • working remotely in a different timezone

Also, in my opinion remote is great if you try to keep synchronous communication at a minimum. That enables people to focus and async communication (like this forum! :slight_smile: ) favors deep communication.
Having a “remote-first” setup really helps. If only a couple of people are remote, they’re likely to miss on a lot of IRL communication and calling in a meeting room is never a good experience.
Finally, we still need face to face conversations to brainstorm and sync. Having recurring stand-ups and planning meetings really help there.
Oh, and while I can really miss brainstorming on a whiteboard I find that working on a shared GDoc while chatting over an audio call to be pretty efficient.

:green_heart:


#3

Hey! :wave:

I can share my experience working remotely at Buffer - we’re a globally distributed team (i.e. every person works remotely) and we span almost every timezone, from Europe, East coast, West coast, Australia, Singapore, Sri Lanka. We are also “remote only”, which I believe is a bit easier that having some remote and some co-located folks because everything happens online by default.

I personally find I am very productive when I can choose the environment that suits me best, which is usually home (for calls) or a coffee shop with headphones (for focus work) and the times that suit me best (usually around 7am start to 4pm finish, with a solid break in the middle).

At Buffer, some people do find that an office environment is better, and choose to work a fixed schedule like 9-5 at a co-working space such as We Work. They find the rhythm of others in the co-working space helps them stay focussed and productive. For people who are more extroverted or get distracted at home that could be a good option.

The hardest thing I find about remote work is that I tend to work too much - not that I don’t get things done. With my work being physically at home, it’s easy to blur the line from work and home and not switch off at a reasonable time, which hurts my long-run productivity. Also, sometimes I can lose track of time and not take breaks as I don’t see coworkers go grab lunch for example.

Specific things I do to counteract this are I schedule exercise classes either at 12:00 (for a “lunch” break) or at 16:00/17:00 depending on when I started, to create a “hard stop”. I also tag team with other Buffer folks to say goodbye and we create “sign-off” accountability for each other.

Productivity wise I find it very effective for Buffer, especially for engineering, because interruptions and distractions are so minimized and people get a lot of heads down focus time.

Huge +1 to @pcreux’s point

try to keep synchronous communication at a minimum

We also find that with flexible schedules and varying timezones, you get the most benefits and least coordination problems when you lean toward asynchronous communication :slight_smile:

Some specific tools/methods we use right now are:

  • We use Discourse, Dropbox Paper, Flow (project management) and old fashioned email for async communications

  • We try to restrict the use of Slack for friendly chatter or if it definitely is urgent (like a service is down) rather than the default place where decisions are made synchronously. We expect Slack replies to a DM or a mention by the end of the other person’s workday so it is not an interrupting ping where the person is expected to respond immediately. I think it’s important to normalize that it’s ok to turn Slack off.

  • For brainstorming we also use video call + a Dropbox paper doc or Figma for sketching out diagrams and it works pretty well.

  • We do 1:1s over Zoom (video call) every week for usually an hour. Sometimes (if cell data is not an issue) we do a walk and talk using bluetooth headphones which is a fun change.

  • Most teams have 2x weekly syncs, a Monday “kickoff and planning” and a Friday “celebration” - which is more aimed at being friends. Some teams choose to do daily standups in addition but that’s less common.

  • Devs will often throw out a zoom link informally into Slack if someone is looking to pair code (e.g. I’m having a hard time on x, if anyone knows about it or is up to rubber duck I’m hanging out in [link] or "hey [name] if you’re around I’m planning to work on X after lunch, you’re welcome to pair). Calls are really high-bandwidth and great for sharing context and for building relationships.

While remote work does have a lot of productivity benefits, things like brainstorming, cross-team collaboration, and building relationships are a bit harder. We have IRL meetups with the full team (71 folks) every year and small team retreats in addition. These are great to “fill up” the trust & ideas tank in a good way.

This is all constantly a work in progress and evolving, I’m eager to hear and learn from other’s experience with allTheThings remote work! :sunny:


#4

We used to have this thing called “Agile”. I’m not willing to say that what we call “Agile” on average today is the Agile that we had from around 2000 to around 2005.

The Agile that I’m talking about is the stuff that comes before Scrum. If you don’t know whether your Agile is in fact Scrum going under the name “Agile”, then you are very likely operating under Scrum.

If you come from a successful Extreme Programming (XP) background, with many years and many projects worth of experience, it’s unlikely that you would opt-in for remote work, remote workers, or remote teams.

There are basic, physical realities of work, worker, and workflow coordination that guarentee that the conditions created by disconnected, cooperative workers can never be as effective as collocated, tightly-coordinated, and tightly coupled workflows and workers.

The reason that I observe that remote work is so tolerated since the end of the last decade is that a whole generation of developers have never experienced just how much more effective software work was before XP was de-emphasized by the methodology pablum of Scrum.

So, given two average teams, one remote and one collocated, nether is likely to out-perform the other. But the very nature of the physics of work systems practically guarantees that an above average team that is co-located will out-perform an above average team that is remote.

But if you’ve never seen (or been on) a high-performance, collocated, XP team, then it’s likely that the basis of comparison for the remote-vs-not-remote question does not include teams that are above average.

This is one of those human things that we can lump under “lost art”.

We used to know how to be much more effective than we are now. And in a single generation (or two) of developers coming into the industry post-Agile (where Agile == XP), the knowledge of how to be above average is largely lost.

This difference is painfully clear in the very way that we look at the question of remote-vs-not-remote.

If you hear the question as “How does it affect my personal productivity”, then it’s very likely that you have neither experienced nor studied as a basic requirement for your day-to-day job work systems. If you hear the question as “How does it affect the whole organization’s productivity”, then you’ve probably got a sufficient background in work systems to know that your individual productivity is largely irrelevant due to local optima effects, and that all issues of personal productivity implicitly take a back seat to holistic productivity.

In fact, in the body of knowledge that encompasses work systems, personal productivity is rarely even referred to as productivity. It’s typical technical name is efficiency. And efficiency is something to be wary of due to the unintended consequences of local optima effects that come hand-in-hand with efficiency.

So, your personal productivity is known in the work systems world as efficiency, and efficiency is not inherently seen as a positive thing (and is always treated to extra scrutiny).

Some more noise about this subject: https://vimeo.com/12948119 :blush:

-Scott


#5

I would like to add to this that the reason we often prefer to work from home is that it’s comforting (or comfortable).

This is something we optimize for when the work itself is not sufficiently comforting.

On a deeper level, it suggests that the work (or the work environment or work system) is something that we’re trying to escape.

While remote work might feel good and feel preferable, we have to surgically explore why it is that the collocated workspace isn’t as awesome as the workspace at home.

If your work at the “office” (or whatever) was just simply kick-ass, and the accomplishment was so fulfilling and so rewarding that you’d never even think of working at home, and you couldn’t achieve at that level by being remote… then would you want to work from home?

Being on an XP team was like that… You wouldn’t think of working from home because the things that could be accomplished by being tightly-coordinated were way better than any of the benefits of working remote.

PS: I’m writing this from my workspace from home, where I work almost every day. And given a choice between working from home with a merely-average project and team, then I’d opt for working at home. But the moment I get a chance to work with people who understand the basics and the principles of coordinated work, I dump the home workspace and run full speed to where ever it is that the team does its collocated work. I want that way more than I want mere comfort.


#6

Thank you for this lengthy post @sbellware.

Re: Scrum and Xtreme Programming.

I see Scrum as process to manage software development projects. It’s inspired by “Agile” principles as it favors collaboration, iterations (sprints), incremental development and releases. It shapes the way the project is managed - it doesn’t have much to do with how developers work together.

Xtreme Programming on the other hand focuses on the practice of software development – how developers work together. It encourages very close collaboration between developers via pair programming, test driven development, simple design etc.

I believe that the two could go together. You could have an efficient team that would manage their project with a flavour of scrum and apply XP practices to develop the software. Am I missing something?

Collocated teams are more efficient

I definitely agree that being collocated makes collaboration easier and more efficient. Talking with someone in real life with a whiteboard is indeed on of the richest and efficient way to collaborate.

Now, if you don’t have good rule in place, then being in the office can be a great source of distractions and interruptions. A lot of people say that they are more efficient when working remotely as they’re less likely to be interrupted by coworkers. I’ve also seen teams becoming more efficient when they started to have remote developers as it forced them to improve their software development process to make it work.

Back to the lost art of XP, I’d love to hear more about your experience @sbellware . What are the practices that are/were making XP teams more effective?


#7

Thank you all for a very detailed replies. I am currently working remotely and I find that although I do believe the highest productivity of work I’ve had was working in the office with a very small team, working asynchronous remote can also have a good rate of productivity. And the only reason why I can say that is since I am asynchronous, the team that I work with are forced to have detailed documentation on all tickets. I find that it wasn’t just me who benefited onto this habit, but the whole team as well. If the ticket is not ready to be worked on, it shouldn’t be on the backlog.

Asynchronous roundups at the end of the day helped us to pick up where someone left of. I’m currently working from Australia so I do like to leave a small note to the team on what I’ve worked on, so they can review it before I start on the next day. Likewise, I can review their work or even continue where they left of when possible.

While I miss having physical conversations with my team, being remote also forced me to be thorough with my documentation. I tend to write a longer note and detailed descriptions on my github pull requests. It also forced me to learn on my own and read documentations more before asking for help which I think is good as a developer.


#8

Forcing functions are good - but only as temporary rehabilitation measures. If we rely on them permanently, we never recover from the injury that causes us to use forcing function crutches to begin with. And if our improvement effort end there, then the total capacity we have for improvement is always limited to that particular level.

The right and clear answers for all of this rest neither in Scrum nor in XP, but in Kaizen. And while it’s possible to arrive at Kaizen from XP, Scrum’s apparent insistence on process orthodoxy makes the emergence of a Kaizen culture almost impossible.

It’s great that forcing functions lead to improvements, but the next step after a forcing function is the investigation of why the forcing function is needed to begin with, and what should have been done to make it unnecessary to begin with, and what can still be done to make it unnecessary so that the flesh of the team’s body doesn’t become yet more distorted to make accommodations for the presence of a permanent crutch.


#9

This is the subject of far more knowledge transfer that can be accommodated by a message board post, and a prohibitive time commitment to turn experience into serialized text, but nonetheless…

XP teams are more effective because they understood the holistic side of development, and how development unfolds over time.

The focus of XP teams is the reality that productivity erodes over time due to moment-by-moment iotas of design decisions that weren’t quite right.

It’s about reducing the batch size of quality assurance down to the most microscopic elements of software development work.

And that batch size is indeed moment-by-moment. Meaning: It cannot be scheduled in advance. If you wait to address these things later at a pre-determined time, say, an end-of-day sync-up, the stakeholders will no longer be in-context enough to address the design issues.

When you increase the communications and knowledge transfer batch sizes to the sizes required by the async communications of remote teams, then the design problems do not get fixed. Rather, the become the foundations for the amplification of the problems by building more mistaken design on mistaken design foundations.

XP teams know software. They know software design. They know software process. They understand how future productivity degradation is being created right now in each and every moment by developers who are failing to see the cellular-level mistakes they are making that become the cancer that the whole body is doomed to suffer.

XP is about software. If you don’t really have a grasp of what that means, then you can’t leverage it to your advantage.

I can’t merely put fingers to keyboard to transfer ability at this level. XP isn’t the basics. It’s a basic training program for something far more advanced than the mere practice exercises and mechanical practices of XP.

The ultimate reason why XP teams are more effective is that they want to be more effective, and they don’t allow anything to get in the way of that. They forgo the luxuries and conveniences that many more mediocre teams indulge to the point of entitlement.

But I can’t just give you specific mechanical practices and suggest with a straight face that they’ll make any difference. They’d just as likely turn into cargo-culting, the way that TDD was mechanically cargo-culted in Rails but very rarely was even minimally achieved in Rails.

XP has no easy answers. It’s not just something that can be handed over in text the way that more material concerns can be, like tools, frameworks, patterns, and more trivial methods like Scrum. Only the easy stuff can be transferred from person to person materially. But the really effective stuff has to be gotten by hand by the individual, building on the more concrete and tangible stuff that has been transferred materially.

You don’t get into the major leagues by reading about it. You get there by not seeing direct, moment-by-moment participation and in-person training camp as an inconvenience, but as an honor and as an opportunity for breakthroughs.

You can’t schedule breakthroughs. XP is about being present at the moment that is about to lead to a breakthrough. You can’t be present for that if you’re merely on the other end of an always-on video conference. The amount of interaction required to turn the raw materials of breakthrough into de facto breakthrough is vastly-more than the stark limitations of telecom technology.

You can read about all of the practices of XP in Kent Beck’s short books on the subject. But you still won’t have done more that gather up the raw materials of XP into your mind. Putting it into action is a whole other level of effort and commitment. And if the convenience and comfort of working from home are more important than the breakthroughs that remove the problems standing in the way of our efforts, then all the reading in the world won’t make a bit of difference.

XP teams are effective because they reject the entitlement to complacency. They accept no level of tolerance for flaws - knowing that their compound effects are why software projects become so disheartening that we’d rather just stay home and work from there.

The specifics of XP are irrelevant, though. It’s not a work system that works at a level low enough that merely telling others about practices can change the outcomes.

No one needs me to tell them about XP. You either want it, or you don’t. And if you want it, then you’ll get on it - just like I did, just like every other XPer did.

The reason that you don’t hear much about XP is that it’s only a scant minority of developers who are predisposed to being relentless against flaws. And with the rise of async communication and batch transfer semantics inherent in the work methods being adopted by contemporary teams, we’re headed in the opposite direction to XP at an increasingly faster rate.

XP is not a culture of lowering the bar to the point that you’ve already achieved it. XP is a culture of constantly raising the bar. It’s not for everyone - merely by virtue of the mathematics of population distribution this can be seen.

So… I’m hesitant to get into any more detail. It’s an arduous journey to teach XP, and it’s not something volunteered for without evidence of serious commitment.

The only practice I’d say that developers should learn is TDD - especially developers who feel they’ve already learned it just by going through the mechanical motions of merely writing tests before writing code.


#10

One quick post scriptum to this:

We’re supposed to be always getting better. Not just getting better at using some material tool, but getting better at being humans. We’re supposed to be conquering our very human limitations so that they don’t get in the way of our software work, and so that the limitations of our software work aren’t getting in the way of our co-workers’ ability to make improvements in their work that are the result of the hard work they’re doing on themselves.

If we find that working moment-by-moment, hand-in-hand with our team mates is less effective than being left along at home to work on our own, they that is the weakness we’re supposed to be willing to accept, and then be willing to work on.

The maximum effectiveness comes from being maximally available to breakthrough. Anything within us that seeks to interfere with that is something that gets slated for more work on the self, until the breakthrough comes and we’re no longer limited by it.

I, personally, am naturally inclined to the indulgence of working from home, but I’m trained to not indulge that inclination. I’m not the line-level grunt who’s griping and groaning about the basic circumstances of the shitty work. I’m the special operations fighter who refuses to accept the status quo as a means to exploit it for yet further self-indulgence.

I’m not sure that the whole software job market can be filled with special operators. But I’m glad to get the chance to work on teams of special operators.

I’m always looking for teams of people who know that doing the maximum is always the way our of the shit, and I avoid teams that - through a perverted understanding of industrial process and industrial maturity - are always trying to figure out how to do the minimum.

I can usually build a team of special operators out of folks who came through XP, and who indeed gave the world Agile Software Development, and then moved beyond it. And I can build a team from people who would have been good at XP back when it was available on the open market.

All it takes is a will to see what’s beyond the current limitation to doing even more than what we’re doing now. Without that, things like XP will never be more than the kind of cargo-culted twaddle that DHH describes for the Ruby community here: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html.