1. 11

    I’m experimenting with something new for my new startup. I’m calling it “fractional” remote: Everybody is encouraged to work from home Wednesday through Friday. Open to better names for this too.

    So far, we’re all really enjoying the balance.

    • You get to connect with everybody Monday/Tuesday.
    • All meetings are scheduled for those two in office days, which is more than flexible enough to enable that kind of collaboration, which is often necessary.
    • You get a solid three days of productive time to do independent work.
    • Remote workers aren’t considered second-class, since everybody is a “remote” worker.
    • Fewer days commuting means that my hiring pool is a bit larger, as people can stomach a longer commute for two days rather than five.
    • You don’t miss out on important discussions because nobody is in the office when you aren’t.
    • All important communications are likely to recorded electronically, since remote communication days dominate the calendar.

    BTW, if you’re in (or near!) Seattle. I’m hiring :) Contact details in profile.

    1. 2

      Oh the irony - a seemingly remote-friendly approach, looking for people in a single city in a single country.

      I do hope your experiment works out though, so good luck!

      1. 2

        It should at least make the catchment a bit wider, though. There are some people who won’t commute to X every day, or most days, but who would do one or two days. I’ve worked with someone like that, who had a very long commute, and it was fine (though it for me it really underscored the question “so why do the rest of us have to be in here every day?”)

        1. 1

          Yeah, the Seattle-area commutes are amongst the worst I’ve ever seen, so weirdly this actually sounds like a god thing.

          I love living in a city with proper transport though.

        2. 2

          Right now, we’re pretty small. As the company grows, my intention is to also grow the geographical area we hire from.

          I still believe that face-to-face time is critically valuable. Having myself been a remote worker on distributed teams, I’ve seen first hand how it requires the right kind of people, culture, and experience to make it work effectively. There is a real human cost to not having regular face-to-face interactions. The baseline is remote-friendly practices, which I think we’re on track for. As the team grows, work becomes more clearly defined, and individuals become more specialized, the communication overhead of remote-work are reduced.

          If were didn’t do this, we could only really hire from Seattle proper. Maybe some folks who don’t mind a long commute too. But, with this policy, all of a sudden everybody on the east side of Lake Washington may be more willing to take a chance on such a job. An hour+ commute daily across the bridge is hellish, but doing it only twice per week, and probably only commuting around 10am and 3pm or so, and suddenly it’s not that bad. Same goes for cities neighboring to the north and south.

          The next step would be hiring from Portland, Oregon or Vancouver, Canada. Commute a bunch for your first few weeks, we’ll put you up in a hotel, and then reduce your commute schedule to monthly, and then eventually only commute for a week each quarter, or something like that. Once we can afford it, this option can be opened up to people who need to commute by plane too. Eventually, the “100%” remote is likely, but even then, I’d want to make sure people interact face-to-face at least several times per year.

          1. 1

            Was looking though my short comment history here and came across this post of yours.

            I’m curious, how has your “fractional” remote experience gone?

        3. 2

          that kind of collaboration, which is often necessary

          Can you write more about why in-person collaboration is often necessary? I’m a fan of the remote-only option, but I’d like to understand other perspectives.

          1. 3

            Two reasons:

            1. Face-to-face communication has higher information bandwidth than any other form of communication.

            My new business involves the marriage of legal and engineering expertise. On more than one occasion in the short lifespan of this organization, a week-long engineering confusion was resolved by physically looking over the shoulder of the paralegal assembling a binder of paperwork. In past remote work, I’ve experienced escalation from email, to IM, to phone call, to video conference, and at least once to “fuck it, I’m getting on a plane and coming over there”. In my opinion, an escalation process like that should be more common rather than less. If you want to be competitive, you shouldn’t completely eliminate your highest-bandwidth communication channel. Besides, there’s still no better collaboration tool than shared physical writing surfaces.

            1. Face-to-face communication enables bonding that soothes tensions and smooths work.

            I’ve worked on several split-office, but non-remote teams. The narrative at each was “everybody in $other_city is an idiot”, but at the end of a week long visit, “oh they’re not so bad”. I have lots of regular internet acquaintances. The only ones who have become “friends” are those I’ve run in to physically at conferences over and over again. I’ve contracted work remotely to people with or without having worked with them locally before. A month of working together locally builds the same trust as a year’s worth of remote work. As far as I can tell, these are not unique experiences.

            1. 2

              Thanks for sharing your perspective. Now, here’s more on mine.

              For me, the advantages of remote-only work all come down to maximizing inclusion.

              1. Face-to-face communication, video conferencing, and (to a lesser extent) audio convey a lot of irrelevant information that could be a distraction and even trigger unconscious biases: the person’s appearance, clothing, accent, etc. In text, a person is just their name (or possibly a pseudonym) and their words.

              2. A remote-only team, particularly using primarily text, is more inclusive of people with disabilities – blind, deaf, mobility impaired, speech impediments, etc.

              I’ll grant, though, that the ideal remote-only, text-only environment that I’m advocating here would probably feel very constrained for most people.

              Also, I’ve only experienced the remote-only option in the context of a company where most of the staff were blind (or at least visually impaired like me). So maybe it only worked for us because we were used to doing without the high-bandwidth channel of vision in the first place. And even we relied heavily on voice communication. Sometime I want to try doing a team project from start to finish with nothing more than text.

              1. 2

                I ran a remote team for a couple of years and I have to agree with @brandonbloom. As much as I prefer text communication, it just didn’t work all that well. We used Slack, email and video calls. We regularly failed to resolve things via Slack and email, whether regarding requirements or development problems. It is very hard to explain things clearly without writing a wall of text, and nobody wants to write a wall of text (or has the time to do it). Video calls and screen sharing allowed us to have a much more productive dialog.

                Contrariwise, I didn’t feel a particular need to escalate further and meet in person. For me, it was enough to spend a bit of time in person to get acquainted in the beginning, and after that video calls were enough both to carry the relationship forward and to resolve any issues.

          2. 1

            I’ve thought about giving this a try, it’s cool to know someone is already doing it! A couple of questions: does this happen only to your team or is it for the whole company? What happens when someone can’t come on a be-in-office-day?

            1. 2

              We’re a small startup still, so it’s the whole company.

              If you can’t come in the office for whatever reason, it’s no different than other flexible schedule companies where you’d either take time off, or just WFH that day to get your big delivery, or rearrange hours to deal with a personal matter, or whatever. The key difference is that a large portion of the non-productivity reasons to WFH are schedule-able, so you can just plan to have your couch or whatever delivered on a Thursday. But “life happens”, so if something unplanned comes up, that’s perfectly OK. Since electronic communication is the norm W-F, you hopefully won’t have missed too much.

            2. 1

              i’ve wished i was in this situation for a while now after experiencing both “remote only” and “no remote”.

              Remote is great when working alone. When hunkering down and actually coding, working remote is great. Brain not currently working? No problem, I’ll just take a break for 2 hours and work tonight. Or, wake up and “in the zone”, let me hack for 12 hours today with no interruptions.

              At the same time, when I was remote, not being able to have the occasional sync up in person definitely made work more difficult.

              So I think your idea is great and as long as your team is honest/responsible I think it should work out well. Would be interested in knowing how it works out.

            1. 51

              We use Confluence, like we did at my last job.

              I fucking hate Confluence.

              1. 7

                Same. It’s awful. Search is a train wreck, and it doesn’t even use wiki-markup.

                We also use something like Doxygen, except it errs out instead of generating the docs.

                1. 6

                  I’ll be the counterpoint here… Confluence sucks, but I think it sucks less than the other solutions I’ve seen. At least for certain problems, and especially when you need a resource for non-developers.

                  A sibling comment says “Search is a train wreck”. To which I say: try searching google docs. Confluence search will at least show you matches within a doc when you search, so you have a better chance of figuring out which doc is actually the one you want.

                  Confluence has the ability to embed various kinds of content in the page, which is quite nice. Google Drawings seems uniquely designed to make ugly drawings. In Confluence, I can use PlantUML or Draw.io.

                  Their new editor supports typing markdown keystrokes to do formatting. The rollout has been kind of bad, but I think the direction of the new editor is good.

                  “Spaces” can be confusing at first, but I think it will help us scale up to the organization sanely.

                  So if the problem you’re solving is “I want to document the API of this project”, Confluence is a terrible choice. If your problem is “I want a place in which all kinds of people in the organization can find docs, discussions, and decisions around various things we’re doing”, Confluence works better than the other choices I’ve seen so far.

                  1. 2

                    The sad thing with Confluence is they used to (about 5 years ago) have a method of inserting wiki markup so that wiki pages could be generated and pasted in, or if you just didn’t want to use the (frankly awful) WYSIWYG editor you didn’t have to. But they ripped that out.

                    Atlassian actually paid us a site visit to gauge opinions from everyone in the company. Pretty much everyone in the company asked for wiki markup to come back, to which they responded “huh”.

                    The API for Confluence is also pretty bad. We have some tools for generating document trees, e.g. when creating documentation for a new service we run a script which creates a tree of pages from templates, but little things like not being able to turn off “notify watchers” on an edit via the API means you can hammer people’s inboxes (which in turn makes Gmail mad).

                    I agree that it sucks, but sucks less than other solutions. Which in itself is pretty sad.

                  2. 5

                    We used to use confluence a bit, but we sort of stopped using it because, well, we also don’t love confluence.

                    1. 8

                      Confluence is awful, but having a constellation of markdown files and Google docs is even worse. One source of truth.

                      The value we got from Confluence is that it gave a place where we could keep dev stuff next to business stuff, so it was easy for people to reference things more easily and have less silo-ing.

                      My only real complaint is that integrating with Confluence via a bot is a pain in the neck–we did this to have a wiki automatically updated with product information from deploys and builds, and that was Not Fun.

                      1. 3

                        The value we got from Confluence is that it gave a place where we could keep dev stuff next to business stuff, so it was easy for people to reference things more easily and have less silo-ing.

                        Something key here is that business folks generally have little interest in editing Markdown files and using Git. Confluence and other such systems may be monstrously annoying (and they are), but they’re better than alternatives.

                        Also, it works in the other direction. Devs want constellations of Markdown, but biz likes constellations of Word documents with comments and tracking. Trust me, Confluence is a better choice.

                        1. 1

                          We dragged them halfway with Confluence, then? We just need to Zeno them to git and markdown (eventually) ;-).

                          1. 1

                            Of course, that goes both ways—I find Con(ef)fluence’s UI so utterly intolerable that I will interact with it the absolute minimum required to not get fired, which in practice means literally never. So now it’s a wiki just for the business side, which is probably better than the “NAS full of outdated Word documents” approach it probably replaced, but it still not very useful.

                            Literally any other wiki software I’ve ever seen would be preferable.

                            But I’m not sure I agree with you that having business and tech share a wiki is a good plan. Business folks love putting paperwork (e.g. “this deployment of this service was signed off on by these people”) into the wiki, which you must never ever ever ever allow, or it will immediately dilute the useful content to homeopathic proportions and make the whole thing useless. So now you either need to be draconian about allowing business folks to put stuff in, in which case they won’t use it, or it turns into a paperwork repository, in which case nobody will use it.

                          2. 1

                            Confluence is awful, but having a constellation of markdown files…

                            That’s a bit of a false dichotomy. Most wikis can provide search, history, notifications…

                          3. 4

                            We use confluence too. I really wish they never made the change to the “smart” editor that prevents users from editing plain markdown (or similar).

                            Read some of the historical tickets around that change if you’re in the mood to shed a tear.

                            In the end though, the key thing is to have one central jumping off place to get to your documentation and confluence works ok for that.

                            1. 3

                              Hear, hear. It’s a nightmare.

                              1. 2

                                I can’t add anything new here - we too use Confluence and almost everyone hates it, but as I and dangoor have mentioned in other comments, there might not be anything better.

                                One thing we did a while ago was move alert references out of Confluence to a git repo which uses mkdocs. This way if Confluence is down or there’s some network issue meaning we can’t get to it, on-call engineers can still have a local copy of all the alert references.

                                1. 1

                                  I like Confluence. It has a WYSIWYG editor that actually works. Plenty of plugins for lots of features and integrations. Recently it even gained real time collaboration.

                                1. 4
                                  1. 2

                                    Another ergodox with dvorak here. The ability to type without having to squeeze your wrists together greatly increases comfort imho. I like the straight (vertically-staggered) columns from a comfort perspective as well.

                                    1. 2

                                      On the ergodox ez and very happy with it. I built one back before the ez with clear switches but I actually prefer the brown switches in my ex.