3 ms·

I've thought a lot about this. I am posting this in an attempt to give an example of what's worked for 1 company, not as a "guide" or "best practices". I post t

I've thought a lot about this. I am posting this in an attempt to give an example of what's worked for 1 company, not as a "guide" or "best practices". I post this in an attempt to give people ideas on what may work for them. I operate an engineering team as a seed stage startup across 2 coasts of the US, multiple parts of APAC, and europe. We are around 13 full time with a few part timers. We started as 2 people. Our first hire was co located with us. Our next one was remote. From there we've made our hires only through referrals or our open source channel. We did YC W16 this year as ~6 people and most of us remote. We've more than doubled the team after having raised nearly 3 million. A few notes on what's worked for us: Remote first office, no one (even if there is an office in your area) is required to come in (at all). We use https://gitter.im/ https://gitter.im/ to interact with our open source community, partner companies, and team members. Half of our hiring happens on gitter as well. Some of us choose to for a separation of work and home. We don't have job postings either. We do this on purpose. We tell engineers the same thing: Show up in our open source channel. This offends some people, but has worked for us. I won't claim this scales long term, but there have been fairly large companies (~800+) that have scaled this way just fine. We've found productivity to be quite high overall. A lot less noise and very efficient communication. Part of it is self management. The hires we make tend to have that part down pretty well. I've learned to spot bottlenecks. Part of that is just by keeping an eye on a lot of channels. Proactive reaching out if there are problems helps a lot. Periodic check ins are a must. We do a weekly google hangout across 5 time zones that amounts to being a standup. For scoping engineering work, we tend to have longer projects people are working on, usually a minimum of a week. This leads to less context switching. Happy to answer questions or expand on anything that sounds interesting.

random42 10y ago
> Half of our hiring happens on gitter as well. Can you please elaborate on that?
- agibsonccc 10y ago
  It happens impromptu. I see a pull request or an interesting project someone built with us. If they stick around and seem interested in the project, I reach out via direct message and see what their goals are. I half heartedly ask them if they'd like to do this full time. If they seem interested, we setup a minor call and we talk about current projects they're working on, and what we're working on at the company. We compare notes and see if interests line up. From there it's negotiations. I've already seen their code and interacted with them for a few weeks by this point, so the interviews are painless and obvious. One thing I make sure to do is be very clear/direct that we're a business. Here's how we make money, here's who our customers tend to be.
  - random42 10y ago
    How does your interview process look like for such candidate?
    - agibsonccc 10y ago
      Usually it's a just a quick phone conversation to talk about interest. The technical interview actually happens the second you enter my open source channel and contribute code or show off something cool you built. This demonstrates a few things to me: 1. You know our codebase 2. You can build things we need 3. I've already collaborated with you 4. You're proactive and interested in solving problems we would have for you. 5. You're able to collaborate with others remotely.
      - gotrecruit 10y ago
        interesting - this seems like perhaps a "good enough" solution for the age old problem that many creative-type career often encounter these days where employers don't want to pay to hire someone before knowing if they can work, while employees don't want to work before knowing they'll be paid. your method seems to basically say, we won't hire you unless you've already done work for us, and we expect that you are self-motivated to do that work and not at our behest so you can't blame us if we don't consider your work good enough to hire you. that's actually pretty clever, although i wonder if this is something that can be applied for other companies.
dasmoth 10y ago
>>> We do a weekly google hangout across 5 time zones that amounts to being a standup. >>> For scoping engineering work, we tend to have longer projects people are working on, usually a minimum of a week. This leads to less context switching. This sounds like a pretty nice granularity -- glad to hear that it seems to be working out. Most of the trouble I have with standups is the "daily" part... Are there any downsides you've found to this kind of rhythm?
- agibsonccc 10y ago
  In the midst of this we communicate quite a bit throughout the week on what we call our "dev channel". We try to keep most communications there so other people see what's happening too. For business development we have "growth channel" that does the same thing, but for cross functional marketing and sales. The week long projects do 2 things or us - it gives us the ability to reassess if someone needs help, and it forces people to plan a little bit. Other than that, async communication throughout the week has helped a lot. That usually replaces the "walk up to desk" thing people do. The key here is you're not expected to reply right away. Of note is we do the hangout on Tuesday of the week. This means you can get your act together on monday and prepare, tuesday we have the 1 meeting and try to cluster other meetings around that (usually another hour at most) and then the rest of the week is free to get work done.

random42 10y ago

> Half of our hiring happens on gitter as well. Can you please elaborate on that?

agibsonccc 10y ago
It happens impromptu. I see a pull request or an interesting project someone built with us. If they stick around and seem interested in the project, I reach out via direct message and see what their goals are. I half heartedly ask them if they'd like to do this full time. If they seem interested, we setup a minor call and we talk about current projects they're working on, and what we're working on at the company. We compare notes and see if interests line up. From there it's negotiations. I've already seen their code and interacted with them for a few weeks by this point, so the interviews are painless and obvious. One thing I make sure to do is be very clear/direct that we're a business. Here's how we make money, here's who our customers tend to be.
- random42 10y ago
  How does your interview process look like for such candidate?
  - agibsonccc 10y ago
    Usually it's a just a quick phone conversation to talk about interest. The technical interview actually happens the second you enter my open source channel and contribute code or show off something cool you built. This demonstrates a few things to me: 1. You know our codebase 2. You can build things we need 3. I've already collaborated with you 4. You're proactive and interested in solving problems we would have for you. 5. You're able to collaborate with others remotely.
    - gotrecruit 10y ago
      interesting - this seems like perhaps a "good enough" solution for the age old problem that many creative-type career often encounter these days where employers don't want to pay to hire someone before knowing if they can work, while employees don't want to work before knowing they'll be paid. your method seems to basically say, we won't hire you unless you've already done work for us, and we expect that you are self-motivated to do that work and not at our behest so you can't blame us if we don't consider your work good enough to hire you. that's actually pretty clever, although i wonder if this is something that can be applied for other companies.

dasmoth 10y ago

>>> We do a weekly google hangout across 5 time zones that amounts to being a standup. >>> For scoping engineering work, we tend to have longer projects people are working on, usually a minimum of a week. This leads to less context switching. This sounds like a pretty nice granularity -- glad to hear that it seems to be working out. Most of the trouble I have with standups is the "daily" part... Are there any downsides you've found to this kind of rhythm?

agibsonccc 10y ago
In the midst of this we communicate quite a bit throughout the week on what we call our "dev channel". We try to keep most communications there so other people see what's happening too. For business development we have "growth channel" that does the same thing, but for cross functional marketing and sales. The week long projects do 2 things or us - it gives us the ability to reassess if someone needs help, and it forces people to plan a little bit. Other than that, async communication throughout the week has helped a lot. That usually replaces the "walk up to desk" thing people do. The key here is you're not expected to reply right away. Of note is we do the hangout on Tuesday of the week. This means you can get your act together on monday and prepare, tuesday we have the 1 meeting and try to cluster other meetings around that (usually another hour at most) and then the rest of the week is free to get work done.