Building SaaS apps that scale, and building great teams with Heroku co-founder

Interviewed by Christophe Limpalair on 01/04/2016

What if there were a set of principles you could follow to build SaaS apps that scale? There are, and they were written by Heroku's co-founder, Adam Wiggins. Adam is joining us today to explain these principles so we can apply them to our own apps. We also talk about building strong teams with hiring & onboarding tips, how to define culture, and how to grow the startup scene in cities.


Similar Interviews

Speed up your web apps with Google web performance engineer, Ilya Grigorik

Handling trillions of events daily and conquering scaling issues with Keen CTO

Links and Resources


Interview Snippets

So you're joining us from Germany, right? Half way across the world.


That's right. Well, it depends on where you are, but for Californians, it's definitely on the other side of the world.

The first thing we're going to cover is the Twelve-Factor app. Can you tell us a little more on what inspired it and what it's about?


The Twelve-Factor App is a set of first principles for application development specifically designed to make it maintainable and especially deployable to a lot of different targets, especially cloud targets.

We were inspired to do this because we had seen thousands of applications and a lot of different applications break in different ways. That includes when people go to first deploy and try to get it running as well as what happens over time as they make changes. We saw patterns in the kinds of problems that people would have. They would write into support or we would see these in usage logs. We were motivated to pull out that pattern and write about how to avoid the problem.

It was especially notable once we became a polyglot platform (support from multiple languages) because we saw problems that went across multiple languages.

For example, Factor #2, the dependency factor, is something every language community figures out on its own. We saw that the Python world wasn't completely on board with dependency management, the Ruby world was getting there, and the Java world figured it out a long time ago. While the tools are different, the solution is always kind of the same. It has a timeless quality. We wanted to write that down in a language diagnostic way to help customers and users and improve the state of the art for applications.

How do you enforce rules and make sure your entire team is actually using them?

I do think of a principle as being something different from rules. Naturally, one produces the other. The principle of, "It's wrong to take someone's stuff," may produce the law of "You will go to jail if you steal." A rule is a way to enforce or put a principle into practice.

The first place to start is to have those principles laid out in a clear way. Then get your team on the same page about it. We can say, "Yes, we want to do things this way. We think it will give us better velocity, makes our jobs easier, or makes our apps more robust over time." Once everybody agrees, you're just talking about a method.

I certainly like tools that encode rules and principles, which usually manifest as certain kinds of constraints or rules. Rails is a great example, where it encodes the model/view/controller principle. That, of course comes with restrictions.You can't access users' cookies from within a model. Some people might chafe at that restriction, but if you agree with the principle that the pattern encodes, then you should be happy to have that kind of constraint. It keeps you on the right path.

—-Ideally, a good tool makes the right thing to do also the easiest thing to do. It shouldn't be just that the tool encodes constraints that stop you from doing things, but that they also make it really easy to do things the right way, where "the right way" here is defined by whatever principle your team has decided it wants to adhere to.

—-I was just reading a chapter in "Clean Code" which talks about vertical and horizontal spacing and naming conventions and different rules that you want to have in place before any project begins. The author mentioned that before they started typing any code, they sat down as a team. It takes just a ten to twenty minute "all hands on" meeting where the team decides how to name and space things and what the rules are.This saves time and avoids arguments in the long run.

Factor #1. Codebase: What do we need to keep in mind when we talk about codebase?


I think that's one of the less radical or controversial ones. It tries to establish shared terminology. You can talk about apps, deploys, and code bases. If you have three developers working on an app, and you've got a production deploy, staging deploy, test deploy, these are all instances of this application in slightly different states, but they all share one codebase. It establishes a term we will use for what unites all these separate deploys.

Secondly, we have a revision system that's tightly tied to our deploys. Most continuous integration tools tie in well with GitHub. It becomes important to say "Yes, we have a codebase that's all coming from the same root branch. You can always resolve every deploy against every other deploy."

Factor #3. Config: Why/when is it important not to have configs in our code?


This can be confounding. Config, in this sense, can mean something that boils down into something different that's going on between each of those deploys. It can be commonly different between each of those deploys.

What I consider to be an anti pattern is the approach that early versions of Rails introduced, where you've got config files that have staging, production, and development too, and you often have a profusion of those things. What you want to be able to do is control all those values independently for each deploy, no matter how many there may be.

Examples of this would be:
  • What database you're connecting to
  • If this is Dev Mode should I put a special toolbar on the screen for the QA (Quality Assurance) testing?

Even in a substantial production application, there may be 10 to 20 keys in there, but they don't need to change that often.They are just different between every deploy.

That's separate from something like application config where you're configuring the framework to work in a certain way. You want that to be the same across all your deploys. You don't want that in the codebase because people are constantly doing checkins for these little config tweaks that only affect them and their local deploy, and it's just confusing. Often those config values have security credentials in the database (username and password, for example). There are lots of reasons to keep that out in a separate config store. It's small and can be set for deploy.

—-A good check for that is, "Can you make this repo (repository) public? Can you have the configuration files in there? Then you can't make it public because you'd have obvious issues.

Factor #4. Backing Services: Treating Backing Services as attached resources. What does that mean, and how do we do it?


It is. It's clearer now. When we were first offering this five years ago, cloud was a new area and what I call cloud services, that is to say, the Twilios and New Relics of today, weren't as common. You're often composing your application from using many of these services.

There seems to be a tendency in thinking, "Okay, I'm using a service to send an email, and that's an external API that I'm calling, but then I've got my local database and my local Memcached and I'm gonna treat those as more like embedded in the application in some way."

While it's true that PostgreSQL and Memcached are more critical to the application, all of them are just services that you're calling through some API. The idea is to treat each of them as a service that can be attached and detached at will. They tend to differ by deploy. If you think of them in terms of your database as an API service, it makes certain things very easy/ Like database upgrades, for example, where you can start up a secondary database that's following your primary database and while you wait for that to fill in the data from the primary database, then you can do a quick hot swap. You think of it as detaching one resource and attaching another rather than the database being something that's permanently married to the application. Maybe it's just a small philosophical kind of difference, but I find that thinking of it that way makes it easier to take advantage of all the great services that exist in the cloud world.

I always think of that as different lego pieces where you can pop out one lego and pop in another one. They all have the same connectors so they can fit as blocks into each other.

Factor #5. Build, release, run: Is there anything else important to remember between these different stages?


Having a clear process for how you do deploys and making sure you're not working backwards in the pipeline.

Adam spent a few years doing freelancing in the PHP world as well as Perl. In those days, it was pretty common to SSH into the production server and start changing code right there on the file system or even on the application itself. This is something you see heavily in the WordPress world: write out files onto the files system under the assumption that this is something that will persist. That's breaking the build, release, and run process where the build process is going to happen starting from the codebase. It comes out of version control cleanly and then it can combine with the config and go into production.

Having a clean separation makes continuous integration easy to do. Whereas, it's hard to do if you're muddling those up.

Christophe: I'm trying not to laugh because I'm remembering when I first started doing development with PHP and WordPress, more specifically. When I wanted to change a file, my versioning system was file_1.php. Problem with the deploy? Just change the name and push it up with FTP or something.

Adam: A lot of folks have gone through that "homegrown" versioning system. Now people who start up with the Ruby or Python world where versioning is just a part of the day 1 stuff that you learn, they don't have the "joy" of inventing the homegrown revision system.

Now you can do cap (capistrano) deploy or if there's a problem with it you can revert back and it does all that for you. It's beautiful.

Factor #6. Processing: Why are Sticky Sessions a violation of this principle?


Sticky Sessions is something where the front-end load balancer keeps track of a back-end runtime instance. So, in Heroku, we would call the routing mesh, the Dyno, so that subsequent requests from the same user go to the same back-end. So, if someone is going through the shopping cart on an e-commerce site, each request goes to the same back-end. That allows you to do things in memory. You can store the user's state right in memory. You just make a structure or whatever it is your language allows for and you store stuff that's in the shopping cart.

The problem with this is that it makes it hard to have a shared nothing architecture (SN). Shared nothing being one of the components of a robust distributed architecture where you should be able to send a request to whatever back-end is able to handle it. Also you see those Sticky Sessions where you come back later and it has timed you out or forgotten about you. Probably what has really happened is that the back-end has restarted or that the front-end load balancer has forgotten about you because they don't want to keep that many things in memory. It's not a good system from our point of view for how to build really robust distributed systems.

The much better solution is that the state shouldn't go in memory or the load-balancer. State goes in a place where you store state; a database is a really good example, something that's more transient.

Memcachedd, which I think of as a type of temporary database. That's the better practice. In the past, it was hard to get a Memcachedd going or it was hard to add a new table to your database, but in this wonderful new world of cloud services, we can do that stuff very easily. We can add a new Memcachedd with just one command. We can add a new table to our database with minimal effort.

Some apps keep you logged in forever, while others routinely time you out. How do you feel about having a user logged in for that long, from a security and privacy perspective?

I think that is an application specific security call. Banks tend to be really aggressive about logging out of their website, whereas something like Facebook isn't. That matches up more with my use. I probably care more about a careless bank session not logged out than I would about
a Facebook session left open. It's worth trying to evaluate in the context of what really is the impact to your customer, if they leave a session open accidentally on a friend's computer. Take for instance Dropbox. Some people use it for mission critical business stuff, and other people use it for photos of their vacation. The relative impact of a session left open accidentally varies by customer.

Factor #10. Dev/prod parity


The concept there is maybe more general than some of the others, like when we talk about logs, process, or distribution which are pretty technical. Dev/prod parity gets more into team workflow.

The basic idea there is something that changed in the last 5 to 10 years in software development is that you didn't have these incredibly long release cycles where there were a lot of layers between the developer writing some code and it eventually being on a site where people could try it out.

That's a really good thing for the most part. You have teams that deploy multiple time per day. You have a customer that writes in with a bug. You can fix that bug. You can get it deployed and turn it around and they're blown away by that result. It makes you fast and agile and it's very satisfying for the team too. You see your work "out there."

One catch in this is that it means that differences between a development environment and staging environment and a production environment are likely to cause problems when you're deploying that often. You have fewer gates to catch those problems. One really common one at the time ProFactor was written was people using SQLite as their local database for development, and then PostgreSQL in production, or maybe even PostgreSQL or MySQL locally and lets say they were using MySQL locally and PostgreSQL in production because they personally liked the MySQL Admin tool or the ops person running the production now says "No, PostgreSQL is more robust." It seems like a nice idea. It scraps away 99.9 per cent of what's different about these databases.

But when those few fractions of a percentage pop up, they really bite you. It's really a problem and that slows down your ability to deploy with confidence because now you're worried about these incompatibilities and that means you can do it less often, and you slow down and lose all that benefit of that fast feedback. So, the concept there is simple. Just make your local environment and make the staging environment match production as closely as possible. It's a little more effort to set up a PostgreSQL or set up a Memcached but not so much effort these days.

Some people take it to what I would consider the natural endpoint of that reasoning process, which is to use something like a Vagrant image and just say "Okay, we're just gonna completely remove all possibility of a different operating system." We're working off of these images and that image is the same one that's gonna run Dev production. You can never have a hundred percent because developers need things in their environment that would actually be detrimental in production and vice versa, but you can do everything possible to remove every difference and therefore save yourself a lot of pain and get that agility of fast, frequent deploys.

What if you need different tools in production than in development? Do you change the image, or manually add them?


That's a good question. I personally have not done a ton with this or the Vagrant based development. I've just seen teams do it and I like the concept. So I think there you have to make a choice between whether all the tools exist in every environment or you're just choosing which ones to bring in. That's probably the safest thing, but another way to do it would be to sort of mount an extra layer of stuff from one environment into the other. I don't have a ton of experience with that.

What do you use to make your environments the same?


Largely, it's just a matter of trying to avoid differences, like using a different database. One thing that is really tempting to use is in-memory sessions as a drop in replacement for Memcached but they're not quite the same. So again there I will want to run a Memcached even in a local Dev environment where it's not really needed. For me, it's largely about those services. I also would be on the lookout for a code smell anywhere there's code in the system. As in conditional code like: if environment==development or environment==production then… or if domain==… that kind of stuff. That is something to watch out for and be equated and try to normalize those out in some way.

How would you go about getting rid of these conditions in your code?


It's situation by situation, but I mentioned the case of having an administrative bar that appears maybe for testers in your staging environment. Maybe you also want it in the Dev environment but you never want it in production. I would make a boolean config that's just like Admin Toolbar on or Debug Toolbar on and if that value is set, it means that if you want to test something in production, you can just temporarily turn that off because if you feel that difference is creating a problem, or you can have a state one in staging environment that has that value that's turned on and then another one that's closer to production and the first one is for some kind of testing and the other one is for the final green "thumbs up."

It depends on your needs. But what I would basically do to start with is ask, "Do you really need this to be different? Think hard about that and then, if you actually do, throw in a little config value and try to really, really limit the scope of it."

How should logs be handled in productions vs. in development?

Logs are pretty simple. They go to your console in development and if you use a tool like foreman or one of its derivatives, those all interweave on your screen. You could even color code it or something like that with the process name that it came from and you can see it all in one place. In a development environment, there is little enough log span that scrolling through your terminal is just fine for finding what you need and then in production, those all get piped to some kind of central location. In Heroku, we have a thing called Logplex which is a really good thing for being able to tail your logs and all your in real-time. It's just a tool for every piece of the system to to be able to throw its logs out to some server so they can be all in one place and be aggregated and searchable later.

So you were the CTO of Heroku up until 2013 or so?


Technically, I was only it for 2 years. All three of our founders did a lot of different things, wore a lot of different hats and that was fine in the early days. As we grew and got to a certain size. I think when we were 50 or 60 people, some of the other executives there impressed upon me that titles are useful to help people know what you do. Especially new people that come into the company and people that are outside the company. At that point I agreed to take on a title, so I had it for the later part of my experience there. Really, the main thing I did was work on the product. That was my role.

What did "day to day" look like at that point?


There were many points. Part of the fun and challenge of a fast growing startup is that the job changes every 6 months. My job, when we were 10 people hacking away on something and trying to get that product/market fit, was vastly different from when I was managing a 75 person department where we had a huge customer base and a lot of revenue and a lot riding on the continued good operation of the product.

The theme that ties through all of it, I'd say is the product work. I define product work or product management, as it is sometimes called, as being an expert in the domain of the customer:
  • Knowing what your users and customers need
  • What problem you're solving for them
  • What their lives are like and what's important to them
  • How you can help them be successful at whatever they're using your product to do

For a company that's making consumer products, the product people will not necessarily be so technical because they're more focused on the parts that face the user and the user is not technical and when you're making a product for developers, obviously the person who is leading needs to be a developer him/herself and from that background him/herself.

My "day to day" always involved understanding what problems people had and how we could make those things better. And then growing and organizing the team around our goals, what we wanted to accomplish on a roadmap, what things we were trying to build and ship to users and get the team together to figure out how we could make that come to life.

How do you understand what users really want? Do you look at numbers of interact "face to face"?


It's basically black magic. Not all of it, but a lot of it is intuition and a gut instinct. You develop a sense for it over time with experience.

It has to be data driven for sure because you can get too focused on your loudest, most vocal customers. You can't make the mistake where people writing in on Twitter or Facebook who may or may not be (and most certainly are not) representative of your whole user base. A lot of people are quieter because they are just busy building their app. They don't have time to talk about it. You have to do a lot of things, particularly when you grow. When you're small, it's easier.

We would go to RailsConf when we only had a few thousand users. We would basically meet half our user base there and talk to them and they could show us what they were working on with their app and what product and see what problems they were having. That made it easy to do on more of a personal level. You could easily synthesize all that information in your own head.

Later it's gotta be with usage statistics, you've gotta go out of your way to reach out to people and find out and say,"I see you're doing something interesting on the platform," talk for a little while, and the trick there is always to come not to just understand what their application is and how they're using the product, but also find out who they are and what's important to them, what things they value, what poses problems for them in their lives. It may or may not be things that are in the scope of your product. You gotta have a "whole picture" of these folks you've devoted your whole life to helping in order to make the leaps to create substantially different products rather than doing small iterations or improvements based on people writing in that they want certain features. If you get to know, in a deep way, a representative sample set of your audience, you can combine that quantitative data to qualitative data with a good bit of "black magic" and you throw it all together.

How do you prioritize new features? Do you build all requested features, or ignore some of them?


There is a lot of trial and error. You have to combine evidence driven reasoning with some instinctive ideas. Ultimately, the market is the only test. For every 5 features you build and ship, only 1 is gonna be really useful. If you watch companies that are really great at product, like Twitter or Slack and they're pushing out new stuff all the time, very often, 99% of it seems like a good idea, but in practice, it doesn't improve the product that much and maybe they trim it away later.

You were laughing when I said that. Is there a specific example that you guys worked on that turned out to be a pretty bad feature?


I would say we threw away 95% of the things we ever built. Of course, I have no way to compare that to other companies, but generally speaking, that's how it goes.

You can't truly know until you build it and ship it. That's the reason you have to move fast and try out prototypes. You double down on things that seem to have struck a nerve and trim away the rest.

To answer your question about prioritization, in the early days, it's pretty simple because you just pick a target user, which can be a real person, and say, "We believe this person is square in the center of something we can serve and we're just gonna do everything we can to make something they absolutely love and then you go into the trial and error process." When you narrow it down to 1 person, it's often easier. Later, when you're trying to serve a lot of different demographics with a lot of different needs, it gets much, much harder.

There, you need to do qualitative and you need to bring in lots of different work groups in the company to give you different perspectives. What the sales people say they need to close a deal is going to be different from what the support people say they need to stop a problem. This is going to be different from what the engineers are going to say is possible to build with technology that could be awesome. You combine this info with market data and customer interviews and all these other things. Hopefully, you come up with some things you think have a good probability to succeed, and you test those and go from there.

We didn't cover all of the Twelve Factors, so check them out here.

You're in Germany now advising various startups. What kind of startups are you advising?


All kinds. I sort of went on a rampage after I left Heroku and wanted to fill in my work time with something that was not such a massive responsibility as starting a new company and hopefully would let me use some of the things I learned from hard gained experience to help other companies.

To name a couple of companies I'm advising here, one is called Contentful which is an API driven management system. You can think of it in the same category as Druple but more completely focused on API driven. Sort of web page driven. They're doing really well. I came a couple of years ago and have been helping them out.

There is also Clue, which is a really fun one. They do digital reproductive health. So they make Apps for Android and iOS that let females track their menstrual cycle and that gives you all kinds of capabilities of understanding when you're fertile or not. It can be useful if you are trying to have a kid or not have one, and you're trying to understand your particular health conditions that interact with that as well as just the sort of lifestyle impact of this biological process.

That's another company that's really blowing up now, but they were a tiny little team of 8 or 10 when I first met them and so it's really a lot of fun to help them out. That's one of my favorite sizes for a team. Especially to get to listen to this demand that I didn't know much about.

Those are both Berlin companies and they're both doing well.

Hiring is a difficult process. How do you find the first employee(s)?


Hmm, that's also one of those things that is as much art as science. It's also something I've spent a huge portion of my career learning how to do well. There are a lot of process things you can do to make the hiring process work well.

For example, starting with knowing what you want. I like to base that around job description, so it's one of the first things you want to do when your team starts. Let's say you are a couple of founders and you want to hire this first person to join your team. You think you're ready. Write down what you think the job description is, what the job is going to be. What's the ad going to be that we put up somewhere on Stack Overflow jobs or whatever?

For ourselves personally, we're going to write a one page document that just says, "Here's what we're looking for. Here are the qualities we want. Here are the things we want them to work on. Here are the things we want this person to bring to our team." Often, you find that the process of trying to write that down is very difficult. Often, one person writes it down and the other says," No no that's not what I was thinking at all." Having a lot of clarity around that is important. It's just one of many process things you can do to help you proceed. To some degree, it's just something you need to do and get experience. Getting help from advisors or mentors who can give you their wisdom is probably a good idea.

I can be really picky when it comes to hiring. How do you weigh the pros and cons especially when it's early stage startup hiring?


It's almost an existential question. Certainly, knowing what you're looking for, sharing it with your team, all being on the same page and writing that down and placing it in your job post so you know what you're looking for is essential. The process of applying for a job or many jobs is stressful in itself and you want to make it as easy as possible for people to see if:
1. You are a company they would want to work for, and
2. Whether they feel they can fulfill the things you are looking for.

One thing I do like to use in addition to trying to write a lot of stuff down, is to make a list of ways I think this candidate can fulfill the list of things we agreed we're looking for. Before we hire, I like to ask this question to myself and everyone who interviewed the person,

"How personally excited would you be to work with this person?"

I'll ask for 1 to 5 stars or thumbs up/thumbs down. Don't accept abstract answers like, "This person seems like a good designer,"or They seem like a good front end developer." Ask them, "Are you super pumped to spend 40 hours per week working with this person for the next 3 or 4 years?"

Somebody might say, "Oh, well, they seem like they have good skills, but I'm actually not that excited about them." Or someone might say, "Well, they do have a couple of gaps in their skills, relative to what we said we wanted, but they can acquire those skills, and I'm really excited to work with them because when we talked and worked together on a start up product (another piece of hiring process I like to use) we made really good things together, we had really creative synergy. Therefore, I think they're gonna bring a lot to the team."

So the character fit or the personable fit is more important than their current skill level?


Skills are really important. I have done the thing before where I have hired people that I think have a ton of potential, I think they would make a good fit with the values of the company, but they didn't really have the skills for what we needed. It's a rude thing to do to them because you're setting them up for failure.

Skills are important, but I think of them as table stakes. We're lucky enough to be in a position where usually we can choose jobs that feel meaningful to us. As for an employer, the skills are the table stakes: you gotta have this and that, more or less. It's okay if there are a few gaps and we identify them and we're willing to fill them in, but we also have to feel that we have great creative synergy and that when we work together, we will create great things.

I try to separate that from the culture fit which can be problematic. Sometimes that can boil down to, "Is this someone I'd like to hang out with, which means this is someone like me, and that produces a situation where if the team is all pretty young people (which is pretty common), then it may create a situation which can make it harder for an older person who actually could bring a lot to the team, not seem to fit because they're from a different generation. We need to put that aside. What really matters is how you work together, if they bring fresh ideas and fresh skills to the team that can help accelerate your work.

At the same time, you need to share values about things that matter about the mission you want to accomplish such that you're able to work together fluidly rather than friction that is created by, for example, one person is hardcore Java and you're a pure Python team. In that case, it's gonna be hard to get along.

Is culture a conscious effort where you sit down and make a list?


That's another one of those almost "magic", ineffable sort of things, but so important to get right. When you can look at the companies that are successful, really strong culture tends to be
one. For me, I think it's not something you can prescribe or that you can build systematically. It's not worth focusing on early on.

"The culture will flow naturally out of the founding team, out of the early employees that join. At some point, you will have a culture and it will become what it is because of the people that you have, so pick those people well."47:50

At some point when you reach 15 to 25 people you may decide you need to codify some of the elements of your culture. You should write some things down in a new hire handbook. We could encourage the development of the desired culture by creating some events where, for example, if you're a team on design, we'll take a field trip to a museum and look at some historic design material. That's something we did at Heroku.
You can find ways to amplify and grow that culture that started organically. That's important. In the early days, it's who you are. It becomes the company based on who those individuals who work there are.

Would you say it's a top down approach where the executives or managers instill these cultural values or is it the other way around?


I don't think it's a top down instilling. I do think it comes from the people who have been there the longest. The senior management or whatever you want to call it is going to be part of that.

You can think of a company as a tribe ideally, maybe it's almost sort of a family. It's the people who have been around the longest that the newbies are gonna look toward to see how to behave. The new hires may ask, "What are the norms of this tribe that I've joined?" They will do it unconsciously. For example, if you are a company that is design oriented, they will look to those people who have been around a long time who are cultural fixtures. They will emulate that. You can amplify that with handbooks, videos, and field trips. These steps amplify things that are already there from people. But I think people in management positions can do things to try to amplify the good parts of the culture and make them apparent to new people who join, so they don't need to be flailing around trying to figure out how to belong in the group. They may be thinking, "I've joined tis tribe, but I don't know what the customs are."

For example, here's this new person and we're gonna send her to an onboarding process where she gets exposure to people who have been around for a long time. Maybe you can buddy them up and they can shadow them for a week or two and learn the ropes that way and learn all those little tacit things that make your culture what it is.

As far as the technical side goes, and having new employees come onboard, how do you get them up to speed and deploying?


First of all, I think onboarding is incredibly important and often an overlooked part of the hiring process. I think of it as, once you've hired someone, you've only done half of the job.

The next half is helping them be successful, helping them find their place in your company where they can contribute the most.

As for engineers, I am a strong believer in getting something deployed the first day whether or not they deploy it themselves. I like to give them a task that is simple and as straight forward as possible. There's a bug to fix, for example. You're gonna probably need a one line change. Pair them up with someone with experience. You're gonna get in there and get it out and they're gonna have their name on something that's in our production system that first day. It's a fun way to build momentum and start learning that process, and if you are a company where developers are just doing their own deployments all the time, (which is common for early stage startups) that's a great way to show them that and make them feel like they're part of the process and see how it works.

That might not be the right thing for all companies. I'm certainly a fan of that approach. Anything that's going to get them involved and taking ownership and being a part of the real thing as soon as possible as opposed to the feeling that they're in a sandbox and not really being a part of the team. Otherwise, you're just delaying the time it's gonna take to get them fully up to speed.

You see your work in the live environment and you're like, "I'm part of this project now. I'm not just another employee in this company. I'm part of the team."

That's so important and it's easy to forget how much, as a new person joining the team, you're an outsider. You feel that and you're excited to be a part of it, but you don't yet know how to fit in. As a manager, you need to do whatever you can to help them feel like a part of the team even in all these small ways. To me, it's huge.

I witnessed a mistake I see a lot of new managers make in that realm which is to take this new hire and say, "We can take this new person and have them go work on this side project which we've been wanting to do for a long time that we haven't been able to get around to." In my experience, that never works. They don't feel like a part of the team. They're off on the side working on this project that doesn't have anything to do with what other people are doing. They're not getting exposure to the real system because they're not working directly with the people that are in up to their elbows and so loaded with responsibilities that they can't do this other project. I try to avoid that. Even if that person has the skills that eventually would make them suited to that project, I would much rather throw them into the main line of your development cycle, whatever that is, and help them get their hands dirty for awhile. Once they feel like they're in it and they build trust with their teammates and they build relationships, and understand the codebase and tools and processes, then you could think about some side projects.

You moved from San Francisco to Germany, which is a really big move. How do you do that? How do you meet people and get involved with like-minded people and then get involved with the startup community?


I had a pretty easy time of it partially because the startup scene is very welcoming here, but partially I had the calling card, I guess, of having a successful company under my belt in Silicon Valley which is, of course, considered the center of the world tech wise and that certainly made it easier for me. That said, I would imagine most people show up in a city and look up meet ups and look up events that are happening and look up the people on Twitter to follow. It's the nature of these networks that once you find one particularly well connected person, you can follow that thread into one of the co-working spaces go to, coffee shops and that kind of thing.

That said, I think the best way to get into a local startup scene is to go to work for a local startup. It could involve trying to get a job at a more established one or trying to look for an early stage one as a cofounder or just offer your services.

"What can you offer?" That's always one way to put it. So, if you show up with, "Hey, I'm here to take from this community," that's probably gonna be harder to plug in than if you show up saying, "Hey, I have something to offer. I want to offer my skills to help one of the companies or one of the ventures that are going on here." If you do that, you'll probably get hooked to a small scene, which most of them are small relative to or compared to San Francisco.

I live in Greenville, SC, which is a nice little city. You can feel that it is starting to grow, especially in the tech scene. How does an individual or even on a bigger level encourage this growth?


Growth of the startup scene itself or startups? I'm not sure…that's something that most people don't have levers to affect. You can have government that can do things to try to speed that development. Established investors that say they want to open up an office in this city and support startup events in the city would help get things moving.

Startup scenes, in the end, are made up of startups, so probably the best thing you could do would be to start or be involved with a successful startup. That's what's gonna make a scene grow. You can talk about co-working spaces and coffee shops and some accelerators and investors, but what makes the scene is having great startups.

You mentioned meet-ups, which are really helpful, and you could even work on various projects. Projects that have always interested you but you never started, or never really knew how to get started. When you get a group of people like that together, you can do stuff for fun.

Absolutely, like hackathons and things like that. I've been to a few events in Berlin that I quite liked…not quite hackathons but hack themed workshops. I went to one that had a health tech theme which was basically a combination of things. We were given a heart rate monitor, Raspberry Pi, some LEDs, a thing you could wrap around your arm for a heart rate monitor and another thing that was like a motion sensor and basically given the project, "What can you build in three hours using these components?" which included some training on how to use these specific devices. I've seen other ones on all kinds of interesting sub niches. Music and sound tend to be big around here because you've got Spotify and SoundCloud and so forth in the area. Music specific hackathons…I think finding one of those is a good way to have fun and meet folks.

How can people reach out to you?

Twitter is probably the best way to find me @hirodusk
You can also go to my website at

How did this interview help you?

If you learned anything from this interview, please thank our guest for their time.

Oh, and help your followers learn by clicking the Tweet button below :)