As the title suggests, we are excited to share that the DEV team is now fully distributed! We’ve gone through a few iterations of how we work (office to distributed), so I thought it’d be nice to share a bit about our background and how we came to this decision.
Our Office History
Back in 2016, Ben & I were building DEV as a side project — we were working from Ben’s basement and various coffee shops in Brooklyn, NY. In parallel, Ben & Peter were working full-time on another startup with an office space in Manhattan. They worked out of a tiny room in a building in Flatiron (fun fact: theSkimm were previous tenants of that room) with a couple other team members. This is what that room looked like:
By early 2017, it became apparent that neither Ben nor I could balance full-time jobs while properly serving the DEV community. We spoke to Peter and decided to join forces and pursue DEV together as a founding team. This meant that the entire team piled into that same tiny office. Needless to say, I helped make some layout changes for the better:
From day one with the newly formed company, we discussed the idea of being remote friendly, though the concepts of what we now think of as a “distributed team” had not entered our lexicon. The DEV Community itself is a distributed ecosystem, and we wanted our team dynamics to reflect that. However, we weren’t even close to ready, and we knew that (sort of).
Our “Remote-Friendly” First Attempt
Even though we had an office, we didn’t want to be limited to NYC talent. That Spring, we added one fully-remote apprentice to the team. As with all of our apprenticeships, we got some solid contributions and were able to provide mentorship. However, we learned the difficulties of communicating with a single remote team member, especially a more junior one. We had trouble balancing the unbalanced team dynamics. It was a step in our journey and a valuable learning experience.
Becoming “Remote-Friendly”
We eventually moved into a much bigger shared office with our friends from Timber. The space was and is great, but the commute wasn’t the easiest. As a result, pretty much everyone on the team began to integrate regular “work from home” days into their routine.
This shift helped us to start understanding what it would take to become truly “remote-friendly.” We began codifying our processes to support asynchronous work and we started standardizing our communication tools and protocols. Little things can make a huge difference — such as ensuring that everyone dials in individually for a video conference, even if multiple people are in the same office. We took steps to make sure that all team members, in the office or at home, were always on an even playing field.
Becoming “Remote-First”
Over time, we became “friendlier” and friendlier to distributed work. We ended up hiring our first two fully-remote team members. Around the same time, Ben moved out of NYC, and began to regularly work from his new place in Beacon, NY. This combination served as a powerful forcing function, forcing us to turn distributed work into a core strength, and removing any remaining pressure for team members to go into our physical office.
This shift also allowed us to codify our process that all future positions would be remote-first. We began hiring from the DEV Community and proceeded to welcome 6 new team members, all of whom work primarily or completely remotely.
Today — Fully Distributed
Fast forward to today — we have officially closed down our Brooklyn office, and the DEV team is now 100% distributed. We have team members in four US states and three countries across the world.
Here are just a few reasons why we’re so excited about this development for our company:
- We get to hire top talent from all over the world
- Everyone on the team is able to structure their own schedules
- We prioritize asynchronous work and have very few meetings
- The DEV team is a stronger reflection and representation of the global DEV community
If we didn’t turn remote work into a strength, we would have never been able to leverage these powerful benefits. And we would have never been able to hire directly from the DEV Community, which we’re very excited to continue doing as we grow.
The below statement is outdated. We have closed our hiring process, but we will be opening up another hiring push in the not-too-distant future.
On that note — if distributed work sounds exciting to you, I’m happy to share that we’re hiring for a number of roles:
Application deadline is 10/24.
Come work with us!
Top comments (41)
Love this post! I wouldn't be at DEV if they weren't remote first.
I'm one of the three that works outside the US (from Italy) so if you have any questions about that fire away and if you feel you need to ask them in private, my DMs are open!
It's amazing to get to this point.
It definitely wasn't easy to transition from a fully co-located team to a fully distributed team. At the same time, it was only going to get harder and harder as we continued to grow. We are so excited to be able to work with a team made up of talented contributors from all around the world.
Quick shout-out to @zach and @binarylogic and the rest of the team at Timber for being great roommates at our most recent office.
Happy to hear about this, Jess! You guys have come far. I'm really interested in hearing your thoughts in detail about a few things:
There's so much more I want to ask, but that's it for now. I'd love to see an in-depth post that hopefully answers all of these questions and more.
Congrats on being fully remote. Cheers! 🥳👨🏻🎤
I'm also very interesting in all of the above! maybe a follow up post is in order?
Yes, please! Exactly my questions, too!
Congrats!!
Echoing some questions from other commenters, I'm curious to hear if you have tips and tricks on making async work well. How much timezone span do you have, and does that impact your workflow?
Thanks for sharing your journey to a completely distributed team! I also work remotely and I had a question about what you mean by supporting asynchronous work. Do you take a more hands off approach to time management, and track employee progress based on task completion? Or do you utilize some kind of punch in/punch out system like Toggl or Slack status to track who is online/offline and to keep up to tabs on how many hours people are working? Thanks for the write up!
I think the key part is here
This is something that most companies forget about because the remote is not about hiring the best talent but just cost. But software engineering requires people collaboration and that requires tooling which is not cheap when being distributed even among different offices. Unfortunately the original promotes of the remote and distributed office overlook this aspect, forget about the hidden cost and preparation and at the end manage to make things worse in all aspects.
Thanks for sharing.
If I was a developer I would had applied :)
Congrats, I've been doing 100% remote since 1999 and LOVE it. The largest company I started grew to 135+ people and I have no plans to do it any other way, if you know how to communicate most of the challenges fade away :)
Sad to see you go but very happy for you all!
Awesome post! Very inspiring and warm. The whole time reading I was thinking “This is so cool!” I love this platform and I really would like to work on your team. I definitely will apply. Thanks for sharing. ;-)
This is so tempting...
Do it ...