An Inside Look with Codeship: John Sheehan, CEO of Runscope

John Sheehan is co-founder and CEO of Runscope, a software company that builds testing, debugging, and collaboration tools for API integrations. We had the chance to sit down with John and talk about his background as a developer evangelist, the challenges of APIs, and building a tolerance for rejection.

An Inside Look with Codeship is a regular series providing an insider's perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they've been, where they're going, and what we could all be doing together. You can read all Inside Look interviews here.

Hi John! How did you come to found Runscope?

The idea for Runscope started in 2010, although I didn't really realize it at the time. I started out working for Twilio in 2010 as a Developer Evangelist.

I worked remotely for the first year or so and spent that year running around the country doing developer evangelism for Twilio. After that I moved to San Francisco and started working closely with my co-founder, Frank, who started at Twilio shortly after I did but had been working on the API team. Because I was helping developers use the API, and Frank was building it, we worked together to figure out what the best experience should be for Twilio customers.

Most of the developers I interacted with were in those first few minutes when they were starting out, and there are a certain set of common problems you run into during the first few moments you use an API. However, the really interesting problems that crop up tend to be down the road once you've become really dependent on an API, and it's a mission critical part of your application's user experience.

I started to help customers with the major and minor problems of using an API through support tickets and working with customers as they got past that initial onboarding phase. I left there and when to IFTTT after that. IFTTT is based entirely on API integrations. Every day, I dealt with a new API or a new integration and kept running into the same problems over and over again. And they were very similar to the problems that Twilio customers would run into once they had scaled up their usage and become really dependent on this third-party API.

There was a lack of visibility with these API calls that were going back and forth between all of our internal and external services. In order to understand the issues we were running into, we needed a lot more visibility into the API calls themselves, not just how our code was handling them.

I started thinking about these visibility problems, started talking about them with Frank. We got excited about a couple of potential product ideas, and then we decided to try to make a company out of it. At the time, we didn't really know exactly what we were going to build or how it was going to work, but we knew we wanted to bring more visibility to API performance problems.

We started out in January of 2013, raised a seed round shortly thereafter, and started building the products. But that's essentially the road that led us to starting the company.

Was there a surprising roadblock or challenge that popped up right away when you started working on API problems?

The biggest challenge was that it wasn't something we could bootstrap on our own and sustain ourselves for very long. We had a big vision, ultimately, for what we wanted to do even if we didn't know the specifics, and we knew that was going to take time. The first challenge was getting the funding in order to be able to start the company and hire some people and start tackling some of that vision.

Ultimately, I probably had 50 or 60 different investor meetings before we got a term sheet to actually get going. We were probably three weeks away from giving up on it and just stopping altogether. Going for that long without a paycheck is not necessarily a very easy thing to do in San Francisco.

Once that started to resolve itself, we got an MVP out really fast. We started letting people in just a few weeks after we started really working on it seriously. And then it sort of steamrolled from there.

Did you find that transition challenging, moving from evangelist to founder, or were they similar skill sets?

Being an evangelist was probably one of the best career decisions I've made to prepare me to be a founder. The good developer evangelists and advocates have their hands on a lot of different things. You might be working with potential partners, so you're practicing your business development skills. You're doing a lot of writing and communicating and talking, so your public speaking gets better. You work with a lot of customers before they buy, so you end up developing sales skills. I think it gives you a broad range of skills that are really applicable to starting a company.

Pitching is something that you end up doing as a founder way more than I expected. Not just investors but pitching candidates and pitching customers and pitching partnerships. You're selling that vision over and over again. And that's very similar to what you're doing as a developer evangelist. You're pitching a vision for how people can be more successful using your products.

I still like to think of myself as being a developer even if it was never my primary goal. I always had other things that I wanted to accomplish that code just happened to help with. I think that developer skills are probably just as applicable to being a founder. My job is to make sure all our teams are headed in the right direction, everyone understands what the priorities are, and they have the resources and information they need to act on those priorities.

The interfaces between those teams felt very similar to assembling the interfaces between pieces of software. Every component has its own requirements, its own communication style, and its own scaling needs. I may not build as much software now, but I'm trying, wherever it makes sense, to apply some of those same skills to building the team.

A lot of thought goes into the build of a team. Is there anything that makes the development environment and culture at Runscope different from other places?

Very early on, when it was just Frank and me, one of the things I told him was, "Hey, I really like APIs, I don't really like dealing with databases. I don't want to ever have to make a database call. I'd like to only have to work with different APIs."

So we started out building everything API-driven from the beginning. Small services that did a single piece of work, that were easy to maintain, that could be scaled and evolved independently. Now in 2015, this is known as microservices. We really got started with that two and a half years ago by accident.

On the people side, it's actually helped us scale our teams a lot faster, not just the software. That's allowed our teams to work more independently and not necessarily have as much coordination between teams for any given fix or feature. It gives developers the freedom to work on something in a way that lets them be more productive without being blocked by other members of the team that are working on a conflicting feature.

We built up an internal deployment tool that allows us really to deploy in one click or, if there's a mistake, to easily roll back. Again, minimizing the footprint for any given problem to make it easier to undo mistakes. This tool has been so successful that we actually, on average now, deploy to production about 25 times a day across the organization. We did something like 8,000 deploys in 2014.

These process improvements and making problems smaller and making it so that teams can be smaller but move faster have really allowed us to scale the product more quickly and scale the number of features we offer but also scale how quickly teams are shipping software.

What do you do to invest in your team's education and growth?

We frame everything within the company under people, product, profit. We want to hire and retain great people; they will build good products, and ultimately we will profit from that. So because we have people first in that equation, we do a lot to develop people internally.

We do some of the standard things, tech talks, mentoring, and teaching internally. We're looking to do more ongoing teaching and mentoring and actually starting to work that into our formal salary formula. Our salary formula is something that we do that's a little bit different than a lot of other companies. We want people to have a clear path from where they are now to where they want their career to go and for that development to happen within the company.

Building personal and career growth into the salary formula lets us recognize things that maybe don't show up in dollars and cents somewhere.

Are there ways that you and your team give back to the development community?

We benefited a lot from the community, and we want to be an equal contributor to it, not just a taker. So, we saw some sites that the community was using a lot but weren’t well maintained or supported for one reason or another -- cost, time, what have you. So we reached out to their maintainers.

In some cases, we've acquired the site, and we actually operate it now. In other cases, we just do simple sponsorship where we take over the hosting fees and let the person focus on actually adding value to the site, instead of having to worry about operating it or finding money to run it.

We did this for Hurl.it, RequestB.in, and httpbin, and we've put some unobtrusive branding on them that simply says, "Hey, if you have API problems, come to Runscope. But the tool's still here, and it still works the way you expect, and it's freely available to you, and we'll take care of all the hosting and maintenance and making sure that it's up and running."

It started out with just a couple different sites; now it's blossomed into a thing we call the Runscope Community Projects. These community projects are essentially our way to support the community with free tools that help them solve a single API problem while also raising awareness about what Runscope is and what we're here to do.

I'm really happy with how that's worked out, mostly because we get a lot of compliments that they're really useful tools. That's the number one thing that we want. We want those tools to exist and be available for people, period.

But it's also turned out to work really well for the company, too. We find about a third of our signups have had some interaction with our community sites before signing up. It’s a really unique model where we get to serve both sides. We're not really interested in forcing our product on people. We want people to find it and find value in it on their own. It’s been a really good middle road for achieving that balance.

What do you think is the biggest problem or challenge facing our industry as a whole? Anything that keeps you up at night?

We have a really heavy focus on diversity, and we've been lucky to attract a diverse set of people. Our engineering team is one third women right now. We're really happy with that, but we want it to be 50-50, across the entire company. And that's a really hard challenge, not just for us but for the industry. In particular, we've had a hard time finding women for leadership positions or women with more senior experience. A big part of that is they're leaving the industry before they get to that level.

So we're going to keep trying our hardest to make sure that we're reaching out wherever we can to do that, but I want to make sure that from top to bottom, our company is balanced in all aspects of diversity. Not just gender.

We want to make sure that we're providing an environment that's conducive to that. I think it's a sad state of our industry that this is so difficult, and if we can do anything at all to change it, we're going to.

If you could go back in time, what advice would you have liked to give yourself?

Prior to starting the company, I think the biggest advice I would tell myself is get really, really comfortable with rejection.

You think once you're done raising money, that’s it. You think, ”Hey, I got rejected 49 times, but one person did not reject me, and therefore we got the funding.” You think you're done with the rejection. Then you find a really great candidate, and you get all the way to making an offer, and you get rejected. It stings. Or you get really far down the path with a prospective customer, and they go with a competitor. I'm never okay with it, but I think it's taken a long time to become more tolerant of the rejection.

Startups are 99 percent being told no. If you're impatient like me, that does not always feel like progress. So, try to get comfortable with rejection as early as possible.

I think you can't build anything great without getting told no.

I hope that's the case because we've been told no an awful lot!

Thanks, John!