“We live and die as a company by our resilience, the professional and competent image we put out.”

Sam Stagg | VP of Engineering at Pusher

Interview by Thomas Peham

September 22, 2015

Photos by Pusher

Sam Stagg has over 10 years of experience in enterprise-scale software development.

As the VP of Engineering at Pusher he is responsible for bringing real-time features to web applications.

Or, in Sam’s words: “I’m the cat herder for a growing team of seven cross-disciplinary developers.”

Share this interview:


Thanks for your time, Sam! Could you please describe yourself?

I'm Sam Stagg. I'm VP of engineering at Pusher. I come from a developer background, but more recently I’ve gotten more involved in project management. I very occasionally get my hands dirty coding.

What does a typical day in the life of Sam Stagg look like?

My day involves going into the office around the same time as everyone else, whenever that might be. I generally do some recruitment stuff in the morning, then I review a few things that have happened overnight, like important tickets. We generally have a daily stand-up at around 12:00 which only takes a few minutes. After lunch it’s all about working on some processes and catching up with people.

I try to set aside at least half an hour for everyone in the team at least once a week, and a bit more if they're new hires. Every two weeks, on our iteration planning day, I also have some planning sessions.

You joined Pusher a couple of months ago. Can you share a bit about the hiring process and what made you decide to start at Pusher as VP of Engineering?

I think if there's one standardised thing about the way we do our interviews, it’s that we try to give people an impression of what they'll actually be doing here.

I don’t do that much coding anymore, so my interview process involved meeting the whole engineering team and getting to know them a little.

I had a bit of time with each of the team members. I talked to them about how they feel about the job, about the things they've been doing, whether they're enjoying life here, what could make things better, and what they expect from having a VP of Engineering.

The most interesting thing for me, and probably the reason why I ended up joining, was that everyone said they loved working here.

What I heard was really positive.

One of the other reasons to join was that Pusher is a growing company, which is making a profit and then reinvesting that profit into growing as a business.

I thought it would be a really interesting opportunity to get into it at the right level, just when the company needs someone like me to come on board to really help out and help scale up from being a startup.

It's been a really cool opportunity. I jumped right into it, basically.

How many people are currently working at Pusher?

In the whole organization there's about 25. In the engineering team there are 8 people.

You already got a nice customer base, including companies like Mailchimp, GitHub and Financial Times. Can you share some challenges when working with such established clients?

We live and die as a company by our resilience, the professional and competent image we put out.

We're providing quite an important part of people's web application infrastructure. What we find with our customers is, that we actually become a more and more important part of their web application as time goes on because they start to trust us.

Part of our job is to maintain and keep that trust. It's quite astounding to me, personally, that we’ve gotten to the stage where we have these major enterprises who really trust us to do quite an important thing for them.

We've managed to do that with not exactly the biggest engineering team.

We've done that by focusing on quality, reliability and security. We basically have to make sure we're always on our toes and always making sure that we're doing what customers want us to. That can be quite a challenge.

When you have a small team, you have to really focus on what you're doing each time.

Coming back to you as a person, has there been any moment in your childhood when technology really clicked for you?

I don't know. I've always been very mathematically minded, and computer science and programming offered the perfect real world application of mathematical principles. It really speaks to the way my brain works.

For a child and teenager it’s really satisfying to see that you have the power to make technology do whatever you want. I think that's probably a quite common feeling for a lot of people who get into development; The ability to actually control something in a really defined way.

Obviously, it's frustrating as well when you can't solve a problem. Certainly, for me, it was a really pleasant experience to be able to understand how something worked from start to finish.

I obviously played a lot of games as a kid. The first time you code your own game, you think, “Wow, I've really made something awesome!”

I was lucky enough to end up working in games for a few years at the start of my career. You learn that how you thought games were made is not at all how it works in the real world. That in itself is already interesting. Then you start thinking about how large teams get from an idea to something that's playable.

When talking with developers, people often say that it’s better to go out and get some hands-on experience rather than going to university. Would you agree with that?

I wouldn't want to put either above the other. I've worked with excellent developers from all sorts of backgrounds: People who never went to university, people who dropped out of university, people who completed university, and people who did post-graduate as well.

I think it has to be an individual choice. No one should feel pressured into having to do one thing or the other in order to benefit their career.

I loved my time in university. What you get from going to university is a foundation and the basics of computer science. However, I can't really say I use what I learned there massively in my career. So, I can also understand how people might want to choose a non-university path.

There's such a demand for strong, good software engineers that, as long as you're good, your background shouldn't be as important and it should be much more about you and the things you've done than about any specific requirement.

I don't like the job specs that say you must have a certain degree. It's never a good way of filtering applicants, because you'll miss some really, really awesome people who just happen to have a slightly different background.

Can you share some tools you and your colleagues are using on a daily basis at Pusher?

We have a bunch of in-house tools that we've written ourselves. GitHub is where we keep all of the things we're actually working on in the engineering team. We use GitHub Issues to track each piece of work. We also use a layer on top of GitHub Issues, which we've built ourselves. It’s essentially a very simple kanban board for tracking how we're doing on those issues as we work through them.

We use Sentry for alerting and monitoring. We have Nagios and a whole bunch of other workflow management tools as well.

Essentially,we want to make sure we're tracking our issues and feature requests as they come in so that we can fit them into our wider strategic planning process for the business.

We also use an internal tool called Gaggle, which basically replaces mailing lists. It's a searchable permanent record of emails sent with certain subjects. It's not saving every single email that was ever sent in the company, but anyone who wants to share things can share them to Gaggle, and then that becomes a searchable repository of things. Finally, we use Confluence as well as as our Wiki software.

We're constantly reevaluating the tools we use. I don't think we're particularly married to any of them, but a few of them are quite useful and would be hard to get rid of.

Are you also using GitHub Issues for feature requests and stuff like that?

We're not really keen on having a massive backlog of issues that we're never going to deal with, and feature requests can often turn into that, because they often don't get implemented in the same way they were originally suggested.

The heart of our strategy for dealing with feature requests is essentially Gaggle, our internal communications tool. You can submit feature requests to that any time.

At our Roadmap Week, which takes place quarterly, we take the strategic direction of the company and discuss what we are going to be looking at over the next few months. We then reconcile that with the feature requests we've received in the previous quarter or further back.

Then we take a week as a company, planning what we're going to be doing. We end up with a high-level strategic document which is going to lead us through the next quarter. Then, we break that down into individual tickets.

That sounds like a great workflow, from planning the strategy and vision to executing it.

Yeah, it seems to work very well for us. I think what's good about it is that it forces us to agree on a direction before we've made too many big decisions.

Is there any advice you would give your 14-year-old self?

I'd say, just go with your gut feeling. There's always another corner to turn, and you never know what's around it, and that's quite exciting. Embrace that rather than worrying too much about the future and the past.

Pusher is bringing real-time features to the browser. What do you think about the future of the browser and which role will it play (also compared to native apps)?

I think it's going to be pretty fundamental and it's never going to go away. But the devices world is rapidly overtaking the browser world.

That has some big implications for us. Firstly, it means we have to make our know-how in developing natively as good as our know-how in developing for the browser, which is something that we're very focused on right now.

Then, there's a big question about persistence of connection. Real time, historically, has required a persistent connection to an endpoint, which is quite straightforward if you're on a browser.

Devices, however, aren't connected to the internet all the time. People are going through tunnels, they're going through reception black spots, so we have to think a lot about how to create a seamless experience for our customers and users who are on those devices.

That's a really big challenge for us, and it's something that we're still working on with our customers, as well as internally.

I think the browser is going to be around for a while. But, instead of being the only way, it's going to one of a whole world of many different ways of accessing the internet.

Why are you passionate about building software?

I suppose it really is very similar to our mission as a company. Software makes the lives of people (in our case developers) easier. What's so great across the entire software market is that you can make lives easier in a variety of areas.

Whatever realm of life you're in, your life is almost certainly being made a lot more interesting and a lot more straightforward by the application of software. On the other hand, there’s probably other pieces of software making your life even more complicated.

The real power of it is the ability it gives each person to maximize their own individual potential and really make everything more straightforward and simple for them, so they can spend the time doing the things they want to do. That's kind of what Pusher is about as well.

Thanks so much for your time Sam!

Follow Sam and Pusher on Twitter!

Share this interview:

Check the other interviews

Get Access to Further Bug Tracking Resources & Interviews