Blog

Foreign founders rank as a large demographic of Y Combinator founders, so it comes as no surprise that the question of where to base a startup post-YC comes up often. As a part time partner and foreign founder, I'm often the one answering this question, so I've written my thoughts down in the hopes that they may be useful to others as well.

Most of this blog post discusses starting a company in Canada vs the Bay area because this is the question that comes up most often for us, but as far as I can tell it applies more broadly.

Starting a company is not an experience that's guaranteed to succeed. Even with the help of organizations like Y Combinator, it is very likely that your company will have periods of struggle and need help as it grows and matures. So while there's no guarantee of success, there are real things that you can do to improve the odds of success.

In particular, there are a few things that are incredibly important to improve a startup's chances: Access to capital, talent, partners, and customers. There's also one thing that's incredibly important and not very obvious: Where you incorporate.

Access to capital

In the first 9 months of 2014, the SF Bay area received $13.61 billion of investment through venture capital. The next city after that was New York, with $3.05 billion, and the next city after that was Boston, with $1.05 billion. In fact, the SF-Bay area received more venture capital than the next ten cities combined.

More broadly, According to the Organization for Economic Co-Operation and Development's most recent numbers, the US leads in absolute dollar amount by about 20x.

In the same time period, Canadian companies received $1.64 billion as a whole.

People will also often make the argument that in Canada you're a smaller fish in a smaller pond but based on the latest numbers, as of Q3 the average deal size in the Bay area was $16M, and the average deal size in Canada was $6.9M. So not only is there less money, the money also writes (on average) smaller cheques.

It is also quite true that many US based investors won't touch companies outside of the US, and quite often they won't even tell you that's the reason. Yes, like with most things in life, there are exceptions to this rule. If you're the hottest deal in town it won't matter. But in the "average" case, or the worst case, you'll have a harder time raising money. The reason is quite simple: Many investors want to be close to where their companies are.

SR&ED (This topic is truly specific to Canadians, so if you're not one, feel free to skip to the next section.)

One of the most common capital arguments that people make when they think about basing a company in Canada is the Scientific Research and Experimental Development Tax Incentive Program, or SR&ED (pronounced shred) which provides tax credits for R&D work.

Yes, you may get tax credits back, but it's a short term gain and it has two issues: You'll only get them back at the end of the year, after the tax season, and more importantly, the value of these credits to you will dramatically decrease over time as your product matures and you start hiring more non-R&D people (sales, marketing, accounting, administrative, etc).

Asking a few Canadian founders about SR&ED resulted in generally negative feedback, and one common theme was:

If you want to bootstrap, then SR&ED may be worth it, but for any startup the amount of time you spend doing the paper work is just a time suck. Instead of focusing on the product you become a professional form-filler.

re: SR&ED specifically, people end up asking engineers to write down what they are doing as though they are lawyers billing for hours. That's not how innovation works. You can't claim a credit for "thinking".

On top of all that, in recent years, the Canadian government has been making it harder than ever for companies to receive SR&ED funding.

Access to talent

Once you have capital, you're going to want to hire. Many of my Canadian counterparts will tell you that if you stay in Canada you can hire the "untapped resources" of Waterloo.

The problem is that you're limited only to engineers who actively do not want to explore outside of the Waterloo region, and I don't believe that's a majority of the engineers there. I don't have statistics to back up this argument, but from our own experience at AeroFS, I suspect most engineers would at least entertain the idea of working for a Bay area company. I'm also reasonably sure the converse is not true.

In general, if you're trying to convince an engineer to uproot and move, convincing them to come work in the Bay area is going to be significantly easier than convincing them to go elsewhere.

This means that at least in theory, startups in the Bay area can extend their hiring reach to talent worldwide. Unfortunately, this is not fully realizable today because of the broken high-skilled labor immigration system of the US, but even so, startups in the Bay area can still recruit top engineers from at least anywhere in the US and Canada as well as any other countries with friendly US immigration relationships (such as Australia and Mexico).

Access to partners/customers

This is probably the one area where your decision may be "region dependent". If your potential customers and partners are all in one country, it may may make sense for you to base your business in that country. But if one country is truly your total addressable market, there's a real question to be asked about the growth opportunity for your startup.

Most likely, your customers are based globally, and although launching in a market that you know may indeed be the best decision, that does not mean that your company has to be based there. AirBnB's first market was in New York, but they are still headquartered in San Francisco.

Delaware C-Corp

There are many little things that become easier when you're doing things the "standard way", which is why where you incorporate often matters as much as where you base your operations.

When it comes to incorporation, having a Delaware C-Corp is standard.

You can and will run into investors that won't deal with non-Delaware corporations, and even more investors that won't deal with foreign corporations. They're simply not familiar with these corporate structures, meaning they need to spend time and money on lawyers to figure out what protections they have, and what other various legal implications may be.

It's hard to stress this point enough. Not only will you save money on legal diligence, but in early stages, being a non-Delaware C-Corp can be incredibly harmful and even devastating in a fund-raising process as investors simply refuse to deal with the diligence required.

Serendipity

One final meta point: There's a magic to Silicon Valley that simply has not been replicated anywhere else. The density and sheer number of entrepreneurs, founders, investors, engineers, etc. leads to great things. A lot of that comes from the serendipity of randomly running into like-minded people on the street. This type of ecosystem leads to introductions, new hires, acquisitions/exits, partnerships, and so on. Today, you simply won't be able to achieve it anywhere else.

Foreign founders rank as a large demographic of Y Combinator founders, so it comes as no surprise that the question of where to base a startup post-YC comes up often. As a part time partner and foreign founder, I'm often the one answering this question, so I've written my thoughts down in the hopes that they may be useful to others as well.

Most of this blog post discusses starting a company in Canada vs the Bay area because this is the question that comes up most often for us, but as far as I can tell it applies more broadly.

Starting a company is not an experience that's guaranteed to succeed. Even with the help of organizations like Y Combinator, it is very likely that your company will have periods of struggle and need help as it grows and matures. So while there's no guarantee of success, there are real things that you can do to improve the odds of success.

In particular, there are a few things that are incredibly important to improve a startup's chances: Access to capital, talent, partners, and customers. There's also one thing that's incredibly important and not very obvious: Where you incorporate.

Access to capital

In the first 9 months of 2014, the SF Bay area received $13.61 billion of investment through venture capital. The next city after that was New York, with $3.05 billion, and the next city after that was Boston, with $1.05 billion. In fact, the SF-Bay area received more venture capital than the next ten cities combined.

More broadly, According to the Organization for Economic Co-Operation and Development's most recent numbers, the US leads in absolute dollar amount by about 20x.

In the same time period, Canadian companies received $1.64 billion as a whole.

People will also often make the argument that in Canada you're a smaller fish in a smaller pond but based on the latest numbers, as of Q3 the average deal size in the Bay area was $16M, and the average deal size in Canada was $6.9M. So not only is there less money, the money also writes (on average) smaller cheques.

It is also quite true that many US based investors won't touch companies outside of the US, and quite often they won't even tell you that's the reason. Yes, like with most things in life, there are exceptions to this rule. If you're the hottest deal in town it won't matter. But in the "average" case, or the worst case, you'll have a harder time raising money. The reason is quite simple: Many investors want to be close to where their companies are.

SR&ED (This topic is truly specific to Canadians, so if you're not one, feel free to skip to the next section.)

One of the most common capital arguments that people make when they think about basing a company in Canada is the Scientific Research and Experimental Development Tax Incentive Program, or SR&ED (pronounced shred) which provides tax credits for R&D work.

Yes, you may get tax credits back, but it's a short term gain and it has two issues: You'll only get them back at the end of the year, after the tax season, and more importantly, the value of these credits to you will dramatically decrease over time as your product matures and you start hiring more non-R&D people (sales, marketing, accounting, administrative, etc).

Asking a few Canadian founders about SR&ED resulted in generally negative feedback, and one common theme was:

If you want to bootstrap, then SR&ED may be worth it, but for any startup the amount of time you spend doing the paper work is just a time suck. Instead of focusing on the product you become a professional form-filler.

re: SR&ED specifically, people end up asking engineers to write down what they are doing as though they are lawyers billing for hours. That's not how innovation works. You can't claim a credit for "thinking".

On top of all that, in recent years, the Canadian government has been making it harder than ever for companies to receive SR&ED funding.

Access to talent

Once you have capital, you're going to want to hire. Many of my Canadian counterparts will tell you that if you stay in Canada you can hire the "untapped resources" of Waterloo.

The problem is that you're limited only to engineers who actively do not want to explore outside of the Waterloo region, and I don't believe that's a majority of the engineers there. I don't have statistics to back up this argument, but from our own experience at AeroFS, I suspect most engineers would at least entertain the idea of working for a Bay area company. I'm also reasonably sure the converse is not true.

In general, if you're trying to convince an engineer to uproot and move, convincing them to come work in the Bay area is going to be significantly easier than convincing them to go elsewhere.

This means that at least in theory, startups in the Bay area can extend their hiring reach to talent worldwide. Unfortunately, this is not fully realizable today because of the broken high-skilled labor immigration system of the US, but even so, startups in the Bay area can still recruit top engineers from at least anywhere in the US and Canada as well as any other countries with friendly US immigration relationships (such as Australia and Mexico).

Access to partners/customers

This is probably the one area where your decision may be "region dependent". If your potential customers and partners are all in one country, it may may make sense for you to base your business in that country. But if one country is truly your total addressable market, there's a real question to be asked about the growth opportunity for your startup.

Most likely, your customers are based globally, and although launching in a market that you know may indeed be the best decision, that does not mean that your company has to be based there. AirBnB's first market was in New York, but they are still headquartered in San Francisco.

Delaware C-Corp

There are many little things that become easier when you're doing things the "standard way", which is why where you incorporate often matters as much as where you base your operations.

When it comes to incorporation, having a Delaware C-Corp is standard.

You can and will run into investors that won't deal with non-Delaware corporations, and even more investors that won't deal with foreign corporations. They're simply not familiar with these corporate structures, meaning they need to spend time and money on lawyers to figure out what protections they have, and what other various legal implications may be.

It's hard to stress this point enough. Not only will you save money on legal diligence, but in early stages, being a non-Delaware C-Corp can be incredibly harmful and even devastating in a fund-raising process as investors simply refuse to deal with the diligence required.

Serendipity

One final meta point: There's a magic to Silicon Valley that simply has not been replicated anywhere else. The density and sheer number of entrepreneurs, founders, investors, engineers, etc. leads to great things. A lot of that comes from the serendipity of randomly running into like-minded people on the street. This type of ecosystem leads to introductions, new hires, acquisitions/exits, partnerships, and so on. Today, you simply won't be able to achieve it anywhere else.

Today we are happy to announce the release of two features focused specifically on large enterprise needs: Group Sharing and Autocomplete.

Up until now, sharing a folder with a team required you to list their exact email addresses, one by one. However, this method isn't foolproof - misspellings are always a possibility - and especially for larger organizations with many new team members, not everyone knows everybody else's email address.

As some of the organizations we work with have thousands and tens of thousands of employees, we wanted to provide a simpler way to invite large groups of people.

Group Sharing

A group is a great shortcut to sharing a folder with many coworkers all in one go.

AeroFS Groups are sets of users that can be set up by the organization administrator to let groups of people share information with each other easily. Once you are a member of a group, you are automatically invited to join any of the shared folders that it joins or it was already a part of. People can also be members of multiple groups at the same time.

If you are a member of a shared folder both individually and by way of a group, your role within the shared folder becomes the greater of your own and your group's role. For example, if your personal permissions are that of a Viewer, but your groups permissions are that of an Editor, you will have the rights of an Editor within the shared folder.

Of course, all this is only true for as long as you are a member of the group, if an administrator removes you from the group, you also lose access to the group's shared folders and permissions.

LDAP Synchronization

For larger organizations that organize their teams through an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) deployment, we have also included LDAP Group Synchronization; a way for AeroFS to create groups that automatically mirror your LDAP tree's groups and them keep them in sync with any changes you make.

Autocomplete

Autocomplete allows you to stop guessing your coworkers email addresses, helps prevent accidental typos, and speeds up adding members to your shared folder. Once you start adding people to a shared folder, AeroFS will automatically suggest users and groups that match users you've invited to shared folders in the past.

If you're unsure of the new member's full email address, or even just want to save yourself the time of typing it out fully, just select the autocomplete option and you are done!

As you can see in the pictures above, Autocomplete also allows you to use AeroFS Groups as possible members of a shared folder.

All About The Experience

As we grow with our customers, we continuously improve the experience of our product. These are two of many features that will provide the best experience in private cloud collaboration.

Today we are happy to announce the release of two features focused specifically on large enterprise needs: Group Sharing and Autocomplete.

Up until now, sharing a folder with a team required you to list their exact email addresses, one by one. However, this method isn't foolproof - misspellings are always a possibility - and especially for larger organizations with many new team members, not everyone knows everybody else's email address.

As some of the organizations we work with have thousands and tens of thousands of employees, we wanted to provide a simpler way to invite large groups of people.

Group Sharing

A group is a great shortcut to sharing a folder with many coworkers all in one go.

AeroFS Groups are sets of users that can be set up by the organization administrator to let groups of people share information with each other easily. Once you are a member of a group, you are automatically invited to join any of the shared folders that it joins or it was already a part of. People can also be members of multiple groups at the same time.

If you are a member of a shared folder both individually and by way of a group, your role within the shared folder becomes the greater of your own and your group's role. For example, if your personal permissions are that of a Viewer, but your groups permissions are that of an Editor, you will have the rights of an Editor within the shared folder.

Of course, all this is only true for as long as you are a member of the group, if an administrator removes you from the group, you also lose access to the group's shared folders and permissions.

LDAP Synchronization

For larger organizations that organize their teams through an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) deployment, we have also included LDAP Group Synchronization; a way for AeroFS to create groups that automatically mirror your LDAP tree's groups and them keep them in sync with any changes you make.

Autocomplete

Autocomplete allows you to stop guessing your coworkers email addresses, helps prevent accidental typos, and speeds up adding members to your shared folder. Once you start adding people to a shared folder, AeroFS will automatically suggest users and groups that match users you've invited to shared folders in the past.

If you're unsure of the new member's full email address, or even just want to save yourself the time of typing it out fully, just select the autocomplete option and you are done!

As you can see in the pictures above, Autocomplete also allows you to use AeroFS Groups as possible members of a shared folder.

All About The Experience

As we grow with our customers, we continuously improve the experience of our product. These are two of many features that will provide the best experience in private cloud collaboration.

We're happy to announce that as of last month, AeroFS officially offers paid maternity and paternity leave! In case of birth or adoption of a new child, AeroFS employees of any gender are eligible for:

10 weeks leave, paid at 100% of salary,

8 weeks additional leave, paid at 50% of salary, and

10 weeks additional unpaid leave—or more, if approved

Why do this?

As President Obama reminded us last week, The United States is one of the only developed countries in the world without paid parental leave. The Family and Medical Leave Act (FMLA) only requires companies of 50 employees or more to support parental leave at all. Most startups of smaller size do not state that they offer such leave, paid or unpaid, until an employee explicitly asks for it.

There are a variety of reasons why startups take a passive approach, but fundamentally, as Cindy Alvarez, Yammer's Director of User Experience and Product Design, explained on her blog, waiting until something happens before creating a policy does a disservice to your employees and to your company.

When we decided to put our policy in place, no employee was asking for a leave of absence. We simply decided it was good for our company.

An actual, written-out parental leave policy gives startups:

More interest from potential hires, especially senior-level candidates: If you don't have a policy written out and visible where people can see it, potential candidates will assume you offer nothing. Even saying that your startup will match FMLA's twelve weeks of unpaid leave is better than nothing.

More diverse hiring candidate pool: We chose to make our parental leave policy gender-neutral. This accommodates non-heterosexual couples and adoptive parents from the get-go and helps our employees divvy up childcare however works best for their family. However, we know that in our society parenthood disproportionately affects the careers of women. Women who are birth parents have to deal with the physical disability associated with pregnancy and childbirth. Women are also expected to take on a greater proportion of infant care duties than men. We want to do what we can to help with that by building in flexibility into the system. In addition, hiring technology workers in the Bay Area is hard enough. Why give any talented person who might be considering parenthood in the next few years another reason to choose Google or Facebook instead of our startup?

A signal of a mature and empathetic company culture: Parental leave policies indicate that your company anticipates your employees' needs ahead of time. Given their (unfortunate) rarity among small startups, they also suggest that your company is further along.

Fewer sick employees: Many companies make employees save up their sick leave in order to take maternity leave. This is incredibly short-sighted, as it means new parents will have few or no sick days remaining when they return to work. When their adorable little germ factory picks up all the latest bugs at daycare, parent-employees will go to work sick and spread those illnesses. Having a separate parental leave policy helps combat this.

Employees better able to focus on work while at work: Not that new parents are exactly refreshed after having a new child, but at least they won't have to return to work before they've physically healed and their new household routine (sleep schedule, daycare, and so forth) has most of the kinks worked out. Studies indicate that parental leave policies positively affect employee morale and loyalty.

Lower turnover: After noticing that new moms were twice as likely to quit as other employees, Google lengthened its maternity leave policy to five months. The number of moms quitting dropped by half as a result. A startup's people are its greatest asset. Even the most generous parental leave policy is cheaper than losing skilled employees and recruiting, interviewing, hiring, and onboarding newcomers. We believe it is basically always better to give skilled employees time off rather than have them leave altogether. AeroFS historically has been flexible with giving employees lengthy sabbaticals or otherwise giving leave that fits people's needs. Doing so for parents as well makes perfect sense to us.

Your startup's parental policy may be different than ours, and that's totally fine. Different companies have different circumstances and different policies that may make sense, but having a policy is important. If you're thinking about implementing a policy but are not sure where to start, you're in luck because Cindy Alvarez has already written one for you, so even if you're too small for an HR department, you can implement one really quickly.

We're happy to announce that as of last month, AeroFS officially offers paid maternity and paternity leave! In case of birth or adoption of a new child, AeroFS employees of any gender are eligible for:

10 weeks leave, paid at 100% of salary,

8 weeks additional leave, paid at 50% of salary, and

10 weeks additional unpaid leave—or more, if approved

Why do this?

As President Obama reminded us last week, The United States is one of the only developed countries in the world without paid parental leave. The Family and Medical Leave Act (FMLA) only requires companies of 50 employees or more to support parental leave at all. Most startups of smaller size do not state that they offer such leave, paid or unpaid, until an employee explicitly asks for it.

There are a variety of reasons why startups take a passive approach, but fundamentally, as Cindy Alvarez, Yammer's Director of User Experience and Product Design, explained on her blog, waiting until something happens before creating a policy does a disservice to your employees and to your company.

When we decided to put our policy in place, no employee was asking for a leave of absence. We simply decided it was good for our company.

An actual, written-out parental leave policy gives startups:

More interest from potential hires, especially senior-level candidates: If you don't have a policy written out and visible where people can see it, potential candidates will assume you offer nothing. Even saying that your startup will match FMLA's twelve weeks of unpaid leave is better than nothing.

More diverse hiring candidate pool: We chose to make our parental leave policy gender-neutral. This accommodates non-heterosexual couples and adoptive parents from the get-go and helps our employees divvy up childcare however works best for their family. However, we know that in our society parenthood disproportionately affects the careers of women. Women who are birth parents have to deal with the physical disability associated with pregnancy and childbirth. Women are also expected to take on a greater proportion of infant care duties than men. We want to do what we can to help with that by building in flexibility into the system. In addition, hiring technology workers in the Bay Area is hard enough. Why give any talented person who might be considering parenthood in the next few years another reason to choose Google or Facebook instead of our startup?

A signal of a mature and empathetic company culture: Parental leave policies indicate that your company anticipates your employees' needs ahead of time. Given their (unfortunate) rarity among small startups, they also suggest that your company is further along.

Fewer sick employees: Many companies make employees save up their sick leave in order to take maternity leave. This is incredibly short-sighted, as it means new parents will have few or no sick days remaining when they return to work. When their adorable little germ factory picks up all the latest bugs at daycare, parent-employees will go to work sick and spread those illnesses. Having a separate parental leave policy helps combat this.

Employees better able to focus on work while at work: Not that new parents are exactly refreshed after having a new child, but at least they won't have to return to work before they've physically healed and their new household routine (sleep schedule, daycare, and so forth) has most of the kinks worked out. Studies indicate that parental leave policies positively affect employee morale and loyalty.

Lower turnover: After noticing that new moms were twice as likely to quit as other employees, Google lengthened its maternity leave policy to five months. The number of moms quitting dropped by half as a result. A startup's people are its greatest asset. Even the most generous parental leave policy is cheaper than losing skilled employees and recruiting, interviewing, hiring, and onboarding newcomers. We believe it is basically always better to give skilled employees time off rather than have them leave altogether. AeroFS historically has been flexible with giving employees lengthy sabbaticals or otherwise giving leave that fits people's needs. Doing so for parents as well makes perfect sense to us.

Your startup's parental policy may be different than ours, and that's totally fine. Different companies have different circumstances and different policies that may make sense, but having a policy is important. If you're thinking about implementing a policy but are not sure where to start, you're in luck because Cindy Alvarez has already written one for you, so even if you're too small for an HR department, you can implement one really quickly.

We are happy to announce that Simtech-IT has signed on as the latest AeroFS reseller in Europe. Under the agreement, Simtech-IT will be able to both resell and host the AeroFS private cloud file sharing service.

We are seeing rapid traction by European companies in private cloud technologies. This is explained by two trends:

European companies become more sensitive to data security and privacy breaches

European laws make it more and more difficult for companies to use public cloud technologies. For example, organizations throughout the UK are required to comply with the Data Protection Act (DPA) and face harsh penalties if they fail to do so.

Traditionally, companies using private cloud are large organizations with dedicated support teams. As more diverse companies are interested in private cloud, they turn to companies like Simtech-IT to fully support their need. By providing file-sharing tools across multiple platforms including OpenStack, VMWare and VirtualBox, we allow companies to quickly deploy and scale a secure file-sharing tool without the difficulty associated with typical private cloud solutions.

We are very happy that Simtech has elected to work with us. Our customer base in Europe continues to grow, and with this partnership we’ll now be able to provide our customer base throughout the region with a more hands on approach to deploying and maintaining our Private Cloud service.

If you are based in Europe and you are interested in providing collaboration tools while keeping your data secure, please contact Simtech-IT.

We are happy to announce that Simtech-IT has signed on as the latest AeroFS reseller in Europe. Under the agreement, Simtech-IT will be able to both resell and host the AeroFS private cloud file sharing service.

We are seeing rapid traction by European companies in private cloud technologies. This is explained by two trends:

European companies become more sensitive to data security and privacy breaches

European laws make it more and more difficult for companies to use public cloud technologies. For example, organizations throughout the UK are required to comply with the Data Protection Act (DPA) and face harsh penalties if they fail to do so.

Traditionally, companies using private cloud are large organizations with dedicated support teams. As more diverse companies are interested in private cloud, they turn to companies like Simtech-IT to fully support their need. By providing file-sharing tools across multiple platforms including OpenStack, VMWare and VirtualBox, we allow companies to quickly deploy and scale a secure file-sharing tool without the difficulty associated with typical private cloud solutions.

We are very happy that Simtech has elected to work with us. Our customer base in Europe continues to grow, and with this partnership we’ll now be able to provide our customer base throughout the region with a more hands on approach to deploying and maintaining our Private Cloud service.

If you are based in Europe and you are interested in providing collaboration tools while keeping your data secure, please contact Simtech-IT.

We recently held our third internal Hackathon, and the results far exceeded our
expectations. Aside from the intangible benefits to teamwork and culture,
literally every project had one or more elements that we are productizing and
integrating into AeroFS.

One of the most important aspects of a hackathon is that it is a safe environment for the critical
work of attempting high-risk experiments.

We all know that failures provide valuable results, and the company needs to make a space for those attempts
somehow. Although most people conceptually agree on the above, it is especially challenging to foster that environment when you're focused on growth and shipping a real product to customers.

I don't think I need to say much more about why we conduct Hackathons. But I do want
to share some thoughts about how we conduct them in hopes that they may be useful to others.

(Oh, and if the engineering culture described here seems interesting to you? You should probably talk to us. Soon.

Scheduling: opportunistic

In the US, the week of Thanksgiving is an annual puzzle for project managers. Is three days even a "week"?

Rather than try to scale our expectations for planning, we simply removed the vestigial week from the planning calendar. Our project roadmaps were scheduled assuming no progress that week, but that did not mean that we couldn't get some work done anyway.

This three day hole provided a natural drop-in for a "Hack Week".

We kicked off the hackathon on Monday morning; checked in at a team "Friendsgiving" Tuesday
night; and by mid-afternoon Wednesday we held demos, chose our winners, and then
relaxed with some social time. It was an energizing lead-in to the holiday
weekend.

This turns out to be a strength overall - it is a better, and safer, use of time and attention than
trying to cram in one last commit before your flight.

This three-day schedule felt about right, but we don't have enough data to say that it's the best length.

Frequency: as often as possible, and no more

You might expect that a company might treat this type of event as a loss of scheduled development time, and try to limit how often we do this. In fact, the opposite is true. The projects were so creative, and the results were so impressive, that we are getting pressure from literally every person on the team to do them more often.

My view is that the actual limiting reagent is setting the events far enough apart that
each time feels like a special event - a welcome visit from an absent friend.
We're still experimenting to find the best rhythm. Right now, the plan is to
try a quarterly hackathon.

The biggest mistake would be to say "we'll do them when we have less schedule pressure";
as most engineers will tell you, that day will never arrive.

Make it a priority: No hall passes

As I briefly mentioned earlier in the post, project schedules accounted for the missing week — all ongoing projects were suspended. However, we still wanted everyone involved. The hackathon was not "optional" — every engineer who was present was expected to participate.

There are multiple reasons why we wanted everyone to participate:

It creates a feeling of value. Something everyone is working on.

If you have some people working on "real work", while others are working on the hackathon, people may feel pressured to continue working on their regularly scheduled work.

Similarly, having people skip the hackathon implies the event is not important, both devaluing the efforts of others, and the hackathon itself.

Have a theme, not requirements

Having a theme is important because it creates a loose framework for the team. You definitely don't want product requirements to be a part of your hackathon, but a theme allows people to easily discuss projects, compare ideas, and generally make sure we're all "swimming in the same direction".

We keep the theme open to interpretation, but the teams should be able to tie
their work back to the theme. The better your work applies to the theme, the
more the rest of the team will appreciate it.

This time we asked the team to focus on defining new features and services. Bug fixes and improvements for internal services were not allowed (that seemed too close to "real work").

As a company, we are strong believers that a Private Cloud architecture gives
businesses and users the best mix of usability, privacy and features. Like everyone, we still find ourselves using public services when there is no private equivalent. And we grumble about it.

So, our theme was: leverage our Private Cloud infrastructure and expertise to
build a better version of a public cloud service.

For historical purposes, our first-ever hackathon theme was a deliberate effort to validate our new
API before announcing it to the
public. We have also used a hackathon to experiment with improvements to our
developer and production infrastructure.

Play favorites

We give equivalent prizes in two categories.

Most impact: Vote for projects that make an impact on the stated theme.
This rewards those 80/20 projects - where a few days' work can make a big
difference in our lives.

Technical amazingness: Vote for projects that accomplished something
amazing, or took on a crazy amount of work, or attacked the hardest problem. We
want to recognize the technology innovators here, regardless of how shiny the
results are. This could also be a cool failure.

We choose the winners by secret ballot. All humans present at the demos get a
vote. Non-humans can observe, but cannot vote.

One very important note: Live count the votes! I almost screwed this up.
Tallying the votes on the board was surprisingly fun - tense and dramatic. The
two leaders for technical amazingness prize were, through sheer good luck, tied
until the very last vote was counted.

Speaking of prizes: Have some

In my view, the ideal prize for an internal event should be:

coveted: The rest of the team actually wants it - it's not a white elephant.

unique: You can't obtain this prize any other way.

valueless: No monetary value. This is a physical manifestation of pride.

As an obvious example, a retailer gift card is perhaps the worst employee prize
imaginable.

The big prize for this Hack Week was truly a big one:

A hand-made "You win hack week!" certificate.

But it has to include some other reminders you can use to remind the rest of
the team of your amazingness:

gift certificate for a pint of delicious Scoop ice cream (I realize this contradicts my 3rd point about the prize being "valueless", but Scoop is so delicious that we couldn't resist).

A ribbon and medal

the right to choose the movie and dinner for our next Movie Night.

Grounding the discussion

Of course, it's unlikely that two different companies will run a hackathon the same way. There is no "one size fits all" for hackathons, just like there's no "one size fits all" for management, company building, or engineering practices in general.

This is only how we've handled hackathons in our short time running them. We hope this information has been useful for you, but we'd also love to hear from you how you run your own hackathons, if you're willing to share.

We recently held our third internal Hackathon, and the results far exceeded our
expectations. Aside from the intangible benefits to teamwork and culture,
literally every project had one or more elements that we are productizing and
integrating into AeroFS.

One of the most important aspects of a hackathon is that it is a safe environment for the critical
work of attempting high-risk experiments.

We all know that failures provide valuable results, and the company needs to make a space for those attempts
somehow. Although most people conceptually agree on the above, it is especially challenging to foster that environment when you're focused on growth and shipping a real product to customers.

I don't think I need to say much more about why we conduct Hackathons. But I do want
to share some thoughts about how we conduct them in hopes that they may be useful to others.

(Oh, and if the engineering culture described here seems interesting to you? You should probably talk to us. Soon.

Scheduling: opportunistic

In the US, the week of Thanksgiving is an annual puzzle for project managers. Is three days even a "week"?

Rather than try to scale our expectations for planning, we simply removed the vestigial week from the planning calendar. Our project roadmaps were scheduled assuming no progress that week, but that did not mean that we couldn't get some work done anyway.

This three day hole provided a natural drop-in for a "Hack Week".

We kicked off the hackathon on Monday morning; checked in at a team "Friendsgiving" Tuesday
night; and by mid-afternoon Wednesday we held demos, chose our winners, and then
relaxed with some social time. It was an energizing lead-in to the holiday
weekend.

This turns out to be a strength overall - it is a better, and safer, use of time and attention than
trying to cram in one last commit before your flight.

This three-day schedule felt about right, but we don't have enough data to say that it's the best length.

Frequency: as often as possible, and no more

You might expect that a company might treat this type of event as a loss of scheduled development time, and try to limit how often we do this. In fact, the opposite is true. The projects were so creative, and the results were so impressive, that we are getting pressure from literally every person on the team to do them more often.

My view is that the actual limiting reagent is setting the events far enough apart that
each time feels like a special event - a welcome visit from an absent friend.
We're still experimenting to find the best rhythm. Right now, the plan is to
try a quarterly hackathon.

The biggest mistake would be to say "we'll do them when we have less schedule pressure";
as most engineers will tell you, that day will never arrive.

Make it a priority: No hall passes

As I briefly mentioned earlier in the post, project schedules accounted for the missing week — all ongoing projects were suspended. However, we still wanted everyone involved. The hackathon was not "optional" — every engineer who was present was expected to participate.

There are multiple reasons why we wanted everyone to participate:

It creates a feeling of value. Something everyone is working on.

If you have some people working on "real work", while others are working on the hackathon, people may feel pressured to continue working on their regularly scheduled work.

Similarly, having people skip the hackathon implies the event is not important, both devaluing the efforts of others, and the hackathon itself.

Have a theme, not requirements

Having a theme is important because it creates a loose framework for the team. You definitely don't want product requirements to be a part of your hackathon, but a theme allows people to easily discuss projects, compare ideas, and generally make sure we're all "swimming in the same direction".

We keep the theme open to interpretation, but the teams should be able to tie
their work back to the theme. The better your work applies to the theme, the
more the rest of the team will appreciate it.

This time we asked the team to focus on defining new features and services. Bug fixes and improvements for internal services were not allowed (that seemed too close to "real work").

As a company, we are strong believers that a Private Cloud architecture gives
businesses and users the best mix of usability, privacy and features. Like everyone, we still find ourselves using public services when there is no private equivalent. And we grumble about it.

So, our theme was: leverage our Private Cloud infrastructure and expertise to
build a better version of a public cloud service.

For historical purposes, our first-ever hackathon theme was a deliberate effort to validate our new
API before announcing it to the
public. We have also used a hackathon to experiment with improvements to our
developer and production infrastructure.

Play favorites

We give equivalent prizes in two categories.

Most impact: Vote for projects that make an impact on the stated theme.
This rewards those 80/20 projects - where a few days' work can make a big
difference in our lives.

Technical amazingness: Vote for projects that accomplished something
amazing, or took on a crazy amount of work, or attacked the hardest problem. We
want to recognize the technology innovators here, regardless of how shiny the
results are. This could also be a cool failure.

We choose the winners by secret ballot. All humans present at the demos get a
vote. Non-humans can observe, but cannot vote.

One very important note: Live count the votes! I almost screwed this up.
Tallying the votes on the board was surprisingly fun - tense and dramatic. The
two leaders for technical amazingness prize were, through sheer good luck, tied
until the very last vote was counted.

Speaking of prizes: Have some

In my view, the ideal prize for an internal event should be:

coveted: The rest of the team actually wants it - it's not a white elephant.

unique: You can't obtain this prize any other way.

valueless: No monetary value. This is a physical manifestation of pride.

As an obvious example, a retailer gift card is perhaps the worst employee prize
imaginable.

The big prize for this Hack Week was truly a big one:

A hand-made "You win hack week!" certificate.

But it has to include some other reminders you can use to remind the rest of
the team of your amazingness:

gift certificate for a pint of delicious Scoop ice cream (I realize this contradicts my 3rd point about the prize being "valueless", but Scoop is so delicious that we couldn't resist).

A ribbon and medal

the right to choose the movie and dinner for our next Movie Night.

Grounding the discussion

Of course, it's unlikely that two different companies will run a hackathon the same way. There is no "one size fits all" for hackathons, just like there's no "one size fits all" for management, company building, or engineering practices in general.

This is only how we've handled hackathons in our short time running them. We hope this information has been useful for you, but we'd also love to hear from you how you run your own hackathons, if you're willing to share.