Remote Jobs

‘On Working Remote’

Find Remote Jobs

On Working Remote, with…

Nathaniel Talbott

How Spreedly built a credit-card-vaulting service from its original subscription payment product — and did it with a distributed team.

Can you tell us about your background, what led you to start your company Spreedly, and your current role there?

I've always been fascinated by technology, and figured out in high school that writing software was going to be my bread and butter. The ability that programmers have to manipulate pure thought stuff and build castles in the sky still feels like magic. I skipped college (on purpose) and went right into industry by apprenticing at a consulting shop; when I left there a few years later I did solo freelancing, a short stint in cubicle-land, and then eventually started a consulting shop of my own (Terralien).

In 2007 I saw in my consulting work that there was a real need for better subscription management software, and Spreedly was born. Doing subscription management software ended up being really fiddly, so we re-focused the company around being a rock-solid credit card vault and multi-gateway API that's usable by any business, recurring or not.

I work on Spreedly full-time now, and serve the role of CTO. That mostly involves being the first line of interface with the business side of the house, and on steering the technical culture as we grow.

Spreedly, Payments as a Platform

I'm always curious about the process of changing direction with a product/company. Can you talk about what made you do this with Spreedly?

Whenever I read about a company "pivoting", it always sounds like this instant of clarity - "we saw this demand, decided to go after it, and saw immediate success". For us (and, I suspect, for many of the stories one reads) it was a much muddier, iterative process. We started off just saying "we're seeing a lot of people asking for something more like this, what would that look like?" So we built an initial iteration of what we called "Spreedly Core", but didn't get much traction - but was that just because people didn't know about it and/or were distracted by our still-in-the-forefront Subscriptions offering?

It literally took two years of learning, adding a new member to the team (our CEO, Justin), and finally re-launching our main site at the beginning of March to finally get the confirmation that, yes, we were right and this new direction was the place to put our focus. It's obvious now, but I can tell you there was a lot of going around and around within the team along the way. There's a lot of challenges to pivoting: what about the original product and its customers? Will this just trade one set of problems for another? Are we excited about working on what the product will become? And it takes time to work through them.

Could we have done it in a more coherent way? In hindsight yes, but in reality, I don't think so. If I'm in that position again in the future I'd tweak the process based on my experience with Spreedly, but at the end of the day it's a learning process and learning is messy and takes time.

How did Spreedly become a distributed company with a mixed-remote team? Was this a conscious decision at the outset when forming the company?

When we formed the company, two of us lived in the Raleigh area, one of us was in Chicago, and the final member of the founding team was in the UK - so operating effectively as a distributed team was a necessity from the very beginning, and we just made it work. The value was undeniable as well, since each member of the team brought skills that we wouldn't have been able to put together if we'd been constrained to the same geographic location.

Were there any administrative issues when it came to structuring a company this way — especially considering a co-founder was in another country?

The only way it really affected us was that we had to incorporate as a US C-Corporation instead of an S-Corporation (for various reasons we didn't want to be an LLC), since shareholders in an S-Corporation must be US citizens.

With us all being founders and none of us taking salaries when we started, payroll taxes didn't really enter into the equation. Now that we've grown and are paying salaries, we simply use a payroll company that deals with all the details of paying those who are in other states. We don't have anyone out of the US on payroll at the moment, so that's not something we've had to deal with.

…each member of the team brought skills that we wouldn't have been able to put together if we'd been constrained to the same geographic location.

Can you talk about what it's like managing a team of remote developers?

I've done it both in a contracting context (I used to run a small dev shop with remote sub-contractors) and now in the context of Spreedly, and it feels like herding cats. Which sounds awful, but it turns out it's OK so long as they're really smart cats, and I limit the herding to subtle nudges. The key has been to find self-managing people who are motivated by the work and not by a boss breathing down their neck - it turns out these people do *better* work when I get out of the way and just give them the support they need. Of course, you can find smart, self-managing folks who are willing to work in an office all the time, but it's harder and I think can actually - for some - make it more difficult for them to realize their full potential.

The biggest challenge of managing a remote work force is just getting visibility into what's going on - who's making great progress, who's stuck but hasn't told you and maybe even doesn't know it yet themselves, who's frustrated, who's slacking off because they're discouraged. It's not about trying to control behavior, but rather about being able to support the people doing the work, and making sure everyone knows or can easily find out when someone else is working on something of interest to them.

I've gone through a lot of iterations of solving the visibility problem, and I think it's something I'll be iterating in perpetuity. It's a problem that changes its shape constantly - when the company grows, when a different personality joins the team, when business necessitates a different kind of collaboration, when strategic decisions need to be made, etc. So it's not so much a once and done solution but rather a process of just finding the best thing to increase visibility right now.

At Spreedly we currently have multiple levels of communication. We use Hipchat extensively - everyone is in it most days, and we can mention anyone and know that they'll get a text or an email letting them know. We've also found great success with iDoneThis - it's laid back approach to daily status fits our current team really well, and has been a great boon to us know what in the world everyone is spending their time on. Then there's Github issues, pull requests, and the repositories themselves, which help us communicate about the work product. And we also cheat in that 75% of us are within driving distance of our office, and so there's some face time between some of us on an at least weekly basis.

This need to constantly surface the work of the company in a way that we can see it remotely is a challenge, but I also think over time it becomes a huge competitive advantage. How many folks have sat in cubicle-land and wondered what the guy in the next cube was doing, how their work fit into the bigger picture, and what they could expect in the next few weeks? Oral history has its perks, but it breaks down pretty quickly as an organization grows, and being forced to scale out company communications early on builds a culture of everyone being engaged with where the business is going.

Vaulting Credit Card Data

Coming from the other direction, are there things that remote employees can do to make the development processes as efficient as possible? Or to make employers and managers like yourself have an easier time maintaining that visibility?

Be noisy! I think remote workers can't over communicate, and need to be pro-active in making sure they're regularly being heard from. Nothing is more frustrating to managers and tuned in fellow employees than a coworker that has been struggling alone - we want to help, and we want to be involved, but if you're not forthcoming about what's going on then we can't. I actually think this is one of the clearest indicators of whether someone is a good fit for a distributed team - will they regularly communicate even when there's no physical face time?

The saddest story of all is the employee who quits because they feel isolated and alone and frustrated, and their coworkers are shocked since they never heard the first thing about any issues, even when they specifically asked how things were going. This can of course happen in a co-located team as well, but it's that much easier when everyone's distributed.

Related to finding people who are a good fit: How has this been impacted by being distributed?

We're still a small team of mostly founders, so it's a bit premature to answer this question. I will say that the founding team we have would not be together if we weren't able to work primarily remote.

As we're beginning to hire, I can say that I think we'd have a much harder time hiring the types of people we're looking for if we weren't flexible on remote work. For our first few hires we are targeting local folks, but local just means "can reasonably be in the office a day a week or so".

I do think that beyond just having a larger talent pool, employees comfortable working remotely multiple days a week is definitely a nice gating factor for us as a company just starting to grow in number of people, since it's so critical for us to find self-managing people. If you have successfully worked remotely in the past, you can probably manage yourself pretty well, and that's money in the bank for a business at our stage.

I think we'd have a much harder time hiring the types of people we're looking for if we weren't flexible on remote work.

How do you go about finding those kinds of people?

We're still hiring out of the existing networks of our founders, which both gives us a pre-vetted list and a solid initial understanding of the fit of a given prospect. As we grow, I think we'll continue to use existing networks aggressively, since it's so incredibly effective; even if each of us just knows two people who would be a great fit, our accessible talent grows exponentially over time.

The best indication of whether someone is a good fit for remote is simply whether they've ever done it before and their own impression of how it worked for them. Of course eventually we'll want to start bringing on people who've never done it before, but needing to do that is still a ways off. I've found a lot of developers have tried remote and failed, but know they failed because the company they worked for failed them (and can articulate how!), not because they weren't a good fit for remote themselves.

Any final thoughts on remote work and distributed teams?

We've had remote workers for a long time, but I believe that truly distributed teams are what's really coming of age now. Running a distributed team takes a whole different mindset from running a colocated team, but I think that mindset is going to be a huge competitive advantage in the long run. There will be growing pains, ideas will have to be adapted to each specific set of people that are implementing them, but it's totally worth it.

I'd recommend anyone interested in distributed teams run off and read Ryan Tomayko's excellent Your Team Should Work Like an Open Source Project essay, as it does a beautiful job of capturing what's really different about distributed teams, and comes from someone who's helped shape what I consider to be the largest and most effective truly distributed team to date: Github.

I'll wrap things up by saying thanks for the interview — always enjoyable to talk about these ideas; distributed teams are just getting rolling, and there's a lot still to figure out. Anyone who wants to engage with me further is welcome to email me and/or message me on app.net (my preferred social network of late).

Finally, if you or any of your readers are ever in the Raleigh/Durham area of North Carolina, I'm always up for grabbing a beer and shooting the breeze on how to effective build and run distributed teams.

We've had remote workers for a long time, but I believe that truly distributed teams are what's really coming of age now.

/ On Working Remote

Interviewed Nathaniel Talbott, CTO of Spreedly
Contact@ntalbott
Photo CreditCarl-Johan Kihlbom