Ep. #10, Community Confidence with James Tamplin of Covid Act Now

Patrick: Awesome. James, thanks so much for coming on the podcast today.

This is the first one we've done in person since this podcast launched during Covid.

So, very excited to have you in our dining room hanging out, talking about developer stuff.

James: I'm excited to be here. Thank you for having me.

Patrick: Can we start out just by sharing a little bit about who you are, and what you're working on?

James: Absolutely. I'm a Brit originally and I moved to the States when I was a teenager.

I moved to Silicon Valley and tried to start a company that failed.

Then another two, and they failed. Then a company called Firebase, which ended up going pretty well.

I sold that to Google and left Google a few years ago and took a sabbatical, I came out of sabbatical during Covid, and I've been working on a project called Covid Act Now, which is data that is at the US county and US state level for how Covid is going in your area.

Patrick: So, our audience is primarily developer community builders, developer tools afficionados.

I think everybody would be really keen to hear a little bit more about your origin story with Firebase, you mentioned you had several companies before that and I know there was some, maybe, false starts with you and Andrew.

Not with you and Andrew as a team, but with products . I'd be curious to hear, what was the insight that led to Firebase?

What was that "A-ha" moment that really helped you all turn the corner there?

James: Absolutely. You allude to Andrew Lee, Andrew is my four time co-founder and high school friend.

So, the specific insight that led to Firebase, we had-- It was interesting.

Company number 2 was a social network, and we realized that we really wanted real time conversations in the social network, and Facebook had just released their chat software.

So we created, company number 3 was a chat product.

It was "Facebook style chat for any website,"that was the tagline of that product.

It was called Involve, and with Involve we had a small set of large customers who were doing very strange things with this chat software.

Like, our gaming customers were sending game state through the software and hiding the actual chat, sending character positions and things like that. We were like, "What are you doing? This is the chat software. This isn't a distributed real time messaging system." Then a light bulb goes off like, "Oh." It was at the intersection of a few different trends.

Trend number 1 was that phones and browsers were getting substantially more powerful in 2010-2011 time frame, and all of a sudden you had front end engineers who could build whole experiences.

And enabling those front end engineers to do that without needing back engineers was a big win, then the second was the real time component that Firebase is famous for.

You had Google Docs and maybe Twitter, and there were a couple of companies around that time that were actually doing real time.

Allowing the democratization of that, instead of being a Silicon Valley tech team, you just call it an API and we synchronize your data across devices.

It was really powerful, so the insight there was that people are hacking around the system.

Asking ourselves, "What were they actually trying to get done?"

That was focused on building great experiences, and focusing on delivering real time experiences to customers was just substantially more delightful and natural.

The "Pull-to-refresh should die" was one of the early--.

Do you even remember the days of pull to refresh? It seems like an eon ago.

Patrick: Was that sentiment, "Pull-to-refresh should die," was that an official tagline?

James: Vikram, who is our first employee, we called him "The chief naming officer" because he would just come up with all these pithy taglines.

One of the ones he had was, "Do you have data? Does it change? You'll love Firebase."

The one, the "Pull-to-refresh should die" was, I think, one of his gems.

But it was never an official thing, it was just something I would occasionally drop at a hackathon or a reference, or something. Or at investor pitches.

Patrick: Of course. When would you say the developer community became part of the story, or the focus of Firebase?

James: Initially. It was day one.

And I think that was because of our previous three companies.

We had assumed that we were the smartest people in the room, or not even in the room because it was just the two of us, but that we were smart and we could figure out what people wanted, so we'd build it and they'd come. A classic startup mistake.

But after you do three years of bootstrapping and you're $20 grand in credit card debt each, you re-incentivize pretty strongly to change your ways.

So we were like, "OK. We're not going to--" I was actually really hesitant to take a fourth at bat.

It was like, third time's a charm and we didn't get a third time, so I don't know about this fourth time thing.

But neither of us wanted to give up, and both of us were extremely loyal to each other, so we forged ahead.

But we really had a maniacal focus on delivering to the market what it wanted, and that right from day one was assembling a group of great software engineers and staying in really close touch with them.

Like, having super short iteration cycles on how we were revving the product.

That initial core kernel of a group that we were using for those things became the basis of our community.

Patrick: It sounds like the community was born out of early product design partners and champions. Is that the case?

James: Yeah, that's precisely the case.

The community was-- Especially with developer tools you're climbing a credibility ladder, and initially when you start a company you have no credibility.

All you have is some social relationships that you can weasel some people into with pizza and beer and the existing social capital that you have, so we did exactly that.

We had a little coworking space over by the Caltrain station in San Francisco, and we'd have these people, who were just initially our friends, combine.

We'd put them on video camera one on one, and then we'd occasionally get them together and as a group and show them what we were up to.

They got to know each other and they got to know us and what we were building, and they got to feel a sense of ownership over it.

We kept it pretty small, I think we started building in September 2011 and we didn't launch until April 2012.

Those 8 months-ish, 7-8 months was really just a small group of people that we revved and iterated with until they got really excited by the product that we were delivering.

They also, They got to know the fellow alpha customers, and as I said earlier, they felt a deep sense of ownership.

When humans feel-- This is what you see with people joining movements or companies or whatever it happens to be, once you feel a deep sense of ownership there is this care that emerges.

I've often thought that he or she who cares most wins, I guess.

"Wins" in a market sense, but more philosophically like the parent who cares about their child will raise a child that is well-adjusted and successful.

But this notion of caring, I think, was a unique insight. Caring via a sense of agency or a sense of ownership over what the company was creating was a big deal for us.

Patrick: Thinking back to that time, back in the early days, what would you say were some tactics or some techniques for engendering that care or providing that agency to those early community members?

James: I think, first of all, it's demonstrating that their voice actually matters and demonstrating that they have some degree of agency.

That's easy to do in the initial early stages, as I said, we had 7-8 months of just 20ish people.

Those 20 people all really felt like they owned some part of the product, that the feedback that they gave showed up in the API surface area or how we talked about it or how it functions when they do it, things like that.

So I'd say that agency is part of it, second is you're going to need to have some sense of mutual value creation.

You need to help your developers or your customers really achieve the goals that they want to accomplish.

There's the famous startup cliche about helping people do something 10 times as easily, or 10 times as good. Firebase did exactly that, and I think once they saw just how much easier it was making their professional lives in the software engineering field or their personal lives for their hobby projects, just how much easier it was making it, they started to feel ownership and care.

You just get this emotional resonance with products that you really come to love or find utility in, and it's about you but it's also about sharing it with the people around you.

We'd have developers talking to their friends about instead of standing up your notes over with Socket .io and then dealing with scaling issues and then having to do some sync libraries and hacking at all together-- "Just use Firebase."

That sense of care was engendered from those things as well.

Patrick: It sounds like building confidence with their community that their input will be heard and implemented, it goes a long way towards building that credibility early on.

James: Absolutely.

Patrick: One of the questions we get a lot is, "How do we grow our community?"

One of the things we say often is, "Maybe focus less about growing it and focus more on retaining and going deeper with the people you have engaged already."

It sounds like you've had a lot of success with that early on, with just going deep with those first 20 or so, in non-scaled fashion.

James: It's certainly a game of quality over quantity, at least in the early days.

More startup cliches are "It's better to have a few people love you than a bunch of people just kind of like you."

Those 20 people turned into just massive champions for us when we launched the product.

They were the ones commenting on Hacker News, they were the ones posting their sample projects.

They were the ones who when we had large companies thinking about using us, that we sent two for referrals.

They were the ones that we had the press talk to, those are the ones that when we had our launch party they presented on stage.

They were more than willing to, because we had invested not just in making them successful but we had opened up a group of people that they had spent many hours with, and we helped them along the way in a very personal manner.

It's somewhat unscalable to have your developer relations people or your initial early startup employees fully manage the community, you can't just all of a sudden turn on the taps one day.

I think you do need some smaller initial kernel, because when new people would show up on Stack Overflow, we'd have a group.

That was dating ourselves now, but Slack did not yet exist.

We had a Google Group where we would manage most communications, and in the early days we were busy just dealing with the fallout from the public launch and scaling up and everything, and new people would come along and check out the product.

Those initial 20 people would be in there answering questions and helping the newbies, and I think that was a testament to just how portent they were to the original product.

Patrick: Thinking about the community as it scaled up beyond maybe the reach of those initial early adopters, how did you think about community at a larger scale?

From a programming standpoint, or goals and metrics standpoint, how did you take those lessons from the early stages and apply them as you grew?

James: That's a good question. Pre-Google we didn't hire any marketing-- So, just some context.

Our company started in September 2011 and we sold to Google 3 and a bit years later.

It was November 2014 that moved our offices over to Google.

In that original 3 and a bit years, we didn't hire any marketing people.

They were just straight up developer relations and different flavors of DevRel. That was our community management and our marketing team.

In terms of how we actually ran the community, it was a lot of in-person events and it was a lot of relationship building, not just between us and community members but between the community members and each other.

So, once a week we'd have people come by and give presentations to the team about what they were up to.

Multiple people, so they'd get to meet each other and they'd get to meet our team.

We have many in-person events at our office, which was right downtown San Francisco.

That was really useful, and it's funny because it's a good amount of time ago, so I'm having trouble figuring out how from a metrics perspective we measured it.

We measured registered developers, certainly.

We measured standards and support metrics when people did write in, and we were always really good about turnaround time and things like that.

We certainly kept track of "This is how many people we have on the Google Group," and things like that.

But I think it was more just the ethos of really treating our developers well and helping them succeed.

Patrick: So early on, you built a culture of agency and care among your early adopters, your "Champions," if you will.

How did that culture expand and scale as you added more team members and headcount and grew the community?

What were the cultural cores that you were able to instill, maybe, that that helped it grow in the way you'd like to see it grow?

James: We had a number of structural elements that we implemented that I think imbued into the new team members, both the team members who join the Firebase team and the community members who-- Or, users who started using Firebase.

There were, I think, a few probably interesting ones to mention, the first of which is we had what was called the Firebase Voice, we had authored a document that had the tenets of how we speak to each other, but also how we speak to our community as well.

It was helpful, knowledgeable and low ego, I think, were the three tenets that we had.

When those would get violated, or when somebody wouldn't live up to that--

Either a community member speaking to another community member or a team member speaking to the community like Andrew or I would, to try and level set and guide how we represented ourselves publicly.

I think that was one, another is just how we built product.

Per the early days and engendering that care, we attempted to continue that as we scaled, so for every new feature that we put out we had what we called "Product or developer feedback sessions."We'd actually bring in members of the community into our office and we'd sit down with that tooling and show them the new features and have them write code against it, so it kept that tie with the community going.

It's like usability testing, but we'd make the engineers, or--

We didn't have product managers for a long time, but we would make the engineers sit down and really interact with the community so that they were getting the front line view.

I think we played around with it, we did a monthly newsletter and we really put a lot of care into the blog posts we publish and the talks that we would give and things like that.

Patrick: Who actually wrote the Firebase Voice document?

James: That was a combination of me and a chap called Kato, who still leads Firebase support to this day.

Kato was actually one of our-- We hired several of our community members, and Kato is-- One day he just showed up on Stack Overflow and started answering all of these Firebase questions.

Like, "Who is this guy? Doesn't he have a real job?" And he did.

He was building a startup on Firebase, and fortunately we were able to bring him into the fold.

He's just a gem and really carries the banner now that Andrew and I have left of how we should be treating our users.

Patrick: I want to go back a little bit in the conversation, you mentioned that you hired a DevRel team and didn't hire any traditional marketers.

It seems like that was a time where growth hacking or growth marketing was on the rise.

What was the criteria for that decision to not hire any marketers, and to focus on DevRel shake folks during those days?

James: I think the strategy makes a big difference.

We were attempting to get everyone using Firebase, we had the belief that "This is our software that was going to be built."

And that every front end engineer in the world should just be using this tool in order to build their iOS and Android and web apps.

So when you're taking that approach, you just want to get as many people using it as possible.

Developers are also substantially different, there's a reason you have B2C, B2B and B2D. It's because the "Buyer" or the customer just approaches products substantially differently.

It's not a buying decision you make and then use, it really does require a lot of investment to learn a new framework or language or platform and developers typically don't switch tool sets often , and when they do they'll play around with something on the side and get to learn it, and then eventually when a new product or project comes around they reach for their existing toolset.

So what we really wanted to do is just get as much adoption by individuals as we possibly could, and I think there's a bunch of mechanics of how developers choose tools as well.

Developers don't see a Google ad and then pick up a brand new JavaScript framework, or whatever.

They will look around and see how many GitHub stars it has and how active the repo is, and if other people in the dev community are tweeting about it and what Hacker News is saying about it, and how vibrant is the Stack Overflow question and answer?

So, none of those things I've just listed are particularly in the domain of traditional marketing, it's mostly DevRel.

You have somebody with a technical background who's into interacting with the community, and they can generate those things.

So that's, given our strategy of trying to get everyone on board, that's why we chose that round.

Patrick: From the outside it seems like the Firebase community was just a massive success, but I imagine there were challenges along the way.

What would you say was the biggest challenge when it came to building that community out?

James: The first thing I want to say is that it was just a lot of elbow grease.

It was just that I spent a lot of weekends at events and a lot of nights at events, and developers are--

They spend an awful lot of time honing their skill sets and picking up new tools as I was talking about earlier, it's a big lift.

So we in turn had to show that we can demonstrate that we were serious.

It was just an awful lot of elbow grease and building out the community, so I think the second challenge that we found was you really have to pay attention to and really care for the people who are using you.

They bet their start up on you or they bet their career by vouching to their boss "This is the tech."

We had a couple of staffers, we almost lost some data several times, which is the biggest cardinal sin you can possibly commit initially as a database company and as a platform.

Then the second is we had some staffers on billing that were pretty gnarly, and your reputation is everything.

All of that elbow grease that you put in can be lost in a moment if you mess up in a big way.

There was a lot of crisis management throughout our initial days, and even going forward with Google, I think there's a couple of articles flying around on the internet about how somebody got charged $30 grand in a weekend.

Of course, we rectified all of those things.

One of them was an IoT company that had deployed Firebase into a bunch of smart fridges.

Then they had a polling interval of a few seconds, and they just had a bajillion smart fridges that were hitting our end points, so we had to end up blocking their IPs so that they wouldn't get charged with bandwidth.

We did bend over backwards many times to help people out of these situations, but when you're building a developer community or when you're building a community of any sort, because the bonds are strong the word travels fast.

If you don't treat people well, it can bite you.

Patrick: What would you say is the secret to building things that developers love?

James: Just speak with them. Just stay really close to them and they'll tell you.

These are some very opinionated groups of people, and they spend--

It's not like you buy a bottle of shampoo and you use it for a month and then you can get a new piece of shampoo.

That's a strange analogy, but just bear with me. It's not like a consumer packaged good.

Once you select a developer tool as an organization or an individual, you're using it for a long time.

It's painful to rip it out, so these people are full of opinions.

You just got to listen to them. The second thing I'd say is integrate with their existing toolset.

Chances are they already love a bunch of other stuff, and if you can make it easy for them to use two things they--

The thing they love in conjunction with the thing they haven't quite heard of yet but might love, that gets a lot easier.

It's the painting the cow paths metaphor.

For example, we did some pretty deep integrations with Angular and Vue and Ember, and some of the other .js frameworks.

Once you have demonstrated to a developer that you can go to them and say, "We've done the work to innovate with your existing toolset," that goes a long way.

Patrick: So in your time since Firebase, how have you seen the role of DevRel and the role of communities change since when you first started?

James: That's a good question.

I think, sadly, I've seen the word "Community" bandied about with wild abandon to some extent, I think if you're going to invest in a community--

Like, "Community" to me really means that you have a set of people using your product who are engaging and talking with each other, and it's like if you removed yourself from the conversation one day it would continue.

I think I've seen a lot of companies really halfheartedly do communities, like they have--

I would call them almost "Preferred user" programs or they have groups of people that they will give sneak previews to, or they will have active comments on their blog.

But I see a bunch of people who decide that community is the hot new thing, and that's what they'll do without investing properly.

Then the other thing I've seen is the exact opposite.

I've seen a handful of people use tools like Slack and put the time and energy and effort and resources into actively developing a really solid community and a really solid group of hundreds, if not thousands of people who are actively using the product and helping each other learn best practices and patterns, and building really cool stuff.

So, it's like with anything that has power. When you get power and influence, you get people who gravitate towards it who are doing it well and just doing it for the sake of doing it.

Patrick: In a similar vein, how would you say the landscape of developer tools has changed since you started Firebase?

James: I haven't done a ton of programming, to be honest.

I left screens behind as much as I can.

Certainly there has been a bunch in the server space that's come up, the container space has gotten significantly more mature, but there's still a new JavaScript library every week.

I've seen some really cool stuff around GraphQL.

GraphQL is pretty exciting to me, like Postg raphile on Hasura.

We continue to see some pretty interesting trends around "How do you help developers just build awesome user interfaces, and not worry about middleware?"

Then there's some pretty out that stuff as well, like Dark Lang, where I'm an investor who are trying to completely and fundamentally reimagine how you write software by removing accidental complexity from across your tools and how they glue together and how all of the negative externalities that can arise.

So, I'm pretty excited about where things are going for software engineers.

Patrick: Do you think if you started Firebase today it would be open source?

James: We always intended to make most of it open source.

We got held up a little bit at Google on the client side, but there are large parts of the Android client that are now open source.

Google has Google Play Services, which is the common Google layer that ships across all Android devices.

There was some internal debates about what should be open sourced and what shouldn't, so now all of the Firebase client libraries are on GitHub.

We had intended to do-- To make the wire protocol open source as well and do some open source reference implementations of the server, so this is just the real time database I'm talking about now.

But we never got around to doing that while at Google.

It's something I'm passionate about and I would love to see that, but I think the answer to your question is that if we would have continue continued independently more of it would have been open source.

Patrick: One my favorite questions is, "What are you reading?"

James: I just read Autobiography of a Yogi, and what else am I reading?

I've been reading Black Hole Focus, which is a book on how to align your values with your day to day actions.

I was in Alaska for a few weeks in August, so I read a book on the Alaskan wilderness, which was not Into the Wild.

Then a lot of random Hacker News articles.

Patrick: Of course. What do you think the role of founders' values are as it relates to their culture and community?

How did you think about that, or how do you think about that today?

James: I think it's everything.

I think the culture of the company and the culture of the community is the habits of the founders, and how they either consciously or subconsciously go about developing those and embodying them.

Before we hired anyone, Andrew and I sat down and wrote down a list of nine values. In hindsight, 9 was a little much.

But after we joined Google every new person who joined the Firebase team we would sit down, and we whittled them down to the top 3 at that point.

On day one, the first half an hour of their time on the team we'd sit down and explain them, and we'd call back to them and in our all-hands and how we treated the community.

So I think nothing is more important, like "The ship will go where the captain steers it."

If the captain is abdicating on defining values or if the captain is focused on fighting the next fire as opposed to thinking long term, then that will be reflected in the actions of not just how the team treats each other, but how the team treats the community.

Patrick: What were the top 3?

James: There was "This is your happy place," was the number one.

Which basically encoded that work is-- This is a very millennial thing in hindsight, but "Work is this thing that you spend 40 hours a week at for at least 40 years of your life. Why be miserable?"

So look out and do the things that engender happiness not just in you, but in your colleagues.

Obviously you're not going to be happy all the time, but hopefully that's the case most days.

We really strive to create an environment that was like that.

The second was "Speak up, we'll listen."

So really, we ended up hiring some great people and it's just a waste of time if you're not listening to their opinions.

I think that was also reflected in the developer feedback I was speaking about earlier, it was reflected in how we ran our internal meetings and how Andrew and I--

Hopefully, I would like to think, showed up for the rest of the company.

Then "We're all entrepreneur" was another value that's near and dear to my heart, which encodes taking ownership for your specific piece of the company, and it also encodes instead of sitting around waiting around to be told what to do and having a proactive approach to your work.

Patrick: I'm always curious about the value definition and articulation of it.

What were the heuristics for those three, how did they rise to the top?

James: We ended up going to a park in Menlo Park in the early days of the company, and we wrote hundreds and hundreds of things we wanted the company to be, and we ended up just condensing them down.

We were like, "These five go together and these ten go together. "

It was a brainstorm that got whittled down, and I think it just came out of a bunch of long form discussion . They just emerged organically.

Patrick: What were some of the ways that you made those actual, you mentioned all hands, and things like that--

How did you keep those values at the forefront?

James: First of all, as I mentioned, we encoded them the first day that everyone showed up.

We had a bunch of traditions, "This is a happy place." We had "Bring your pineapple to work day."

We basically had a tradition where anyone could put a day on the calendar and it would just happen.

So, we had formal attire day, and somebody put "Bring your Snuggie to work day."

I just came in and everyone was in Snuggies , and we had a bunch of interesting stuff like that.

In terms of "Speak up, or listen" we had developer feedbacks.

We had a very tight process, so we'd do 3-2 week spreads.

So, that was a 6 week and then we'd have "Experiment week," which was AKA "Hack week."

During hack week there was a subset of people who just went and did road mapping to the next six week cycle, and the entire company was involved and they'd reach out.

I could get feedback and make sure that people were being proactively engaged and involved in the process.

It was encoded by the norm that you'd respond to every tweet and to every support message and every Google Group message with care.

We'd set up time and processes to do that, and in terms of "We're entrepreneurs,"the things that came out of experiment week often formed the basis for many of our new products.

Firebase Hosting came out of an experiment week, and just speaking to the open source thing we had a project that came out of one experiment week that was basically doing lateral action on the real time database server component so that you could you stand up a mesh network and almost do an offline sync.

It never saw the light of day , unfortunately.

But we had a bunch of people building really cool stuff because of the structure we put around it.

Patrick: It sounds like you've been very intentional in the crafting, from the values of the company to the way the culture was built, to the way it scaled up. Well done.

James: It was a lot of work, but it was absolutely worth it.

Patrick: This podcast is called Developer Love, so I ask every guest, "What is one thing you're loving right now ?"

James: I'm loving not breathing smoke in San Francisco .

We have clear blue skies and mid 70s, so I'm excited about that. I'm loving seeing friends after seven months of quarantine.

It's been fun to socially distance and see people in the park and outside, which has been really lovely. It's been a strange year.

Patrick: We've talked a lot about Firebase today, but you're working on some pretty cool stuff lately.

Do you want to share a little bit about your current projects, and where people can find more?

James: Absolutely. At the moment I'm working on something called Covid Act Now, which is data visualizations around Covid and the spread of Covid.

So, you can find that at CovidActNow.org

It's with a bunch of the old Firebase team and some other smart folks from the tech world and from the epidemiology world.

We're just trying to help individuals and political decision makers make better decisions around this current pandemic we're going through.

Patrick: James, thanks so much for coming on the show today.

I can't wait to get this episode out and share with the world all of your wisdom around values and culture and community building.