I've written in the past about how I see the role of a CEO to be one where you are repeatedly firing yourself. Joe Kraus brought my attention to thinking about the role in this way, and it has been an incredibly powerful mindset as Buffer has grown.
It's been fascinating to see how this idea of firing yourself has been reflected not only in the evolution of my role, but also our co-founder and Chief Operating Officer Leo, and our Chief Technical Officer Sunil. I'd say it is probably happening right now for Carolyn, our Chief Happiness Officer, too.
I thought it might be interesting to take a look back on the journey so far and share the times where myself or others have fired ourselves.
When to first think about firing yourself
It seems quite clear to me now that we're 15 people and I've replaced myself a few times, that this notion of firing yourself is one which is very useful to embrace as a founder. As a founder you're always thinking about the whole business, and so by hiring people for your key skill tasks, they can focus fully and do a better job.
I have the opportunity to regularly meet with founders and recently my meetings have caused me to think about when the right time might be to start thinking about firing yourself from the first key skill-based activity you are working on.
First you need to achieve product/market fit
Before any kind of scaling, I think its essential to hit product/market fit. This is the point when it's clear your product works. People are sticking around, they’d be super disappointed if you went away, and youre growing fast. You can feel the potential when you've hit this stage.
To put it another way: until you hit it, your only job as a startup founder is to work on reaching product/market fit.
Keep working on a skill long enough to hire well
Even once you've hit product/market fit, you probably want to keep doing your skill tasks long enough to truly see how useful it will be to have someone else in that role full-time. For your first skill-role, perhaps coding or marketing depending on whether youre a technical or non-technical founder, you will probably not have the challenge of wanting to let go of the role too soon. Most people hold on too long, and sacrifice slow down growth of the company. I certainly have done this myself. However, once you've fired yourself from that first task, for subsequent ones which youre learning from scratch you might want to do them long enough to see the full opportunity and understand the area well enough to ask the right questions when hiring.
Start doing many things at once (it will become chaotic)
As a founder, especially as a CEO, you're probably going to be doing many things at once. You'll at least be thinking about many things at once. My role has shifted from actually doing many things to helping to run many things. As you grow you might find you have a larger impact by becoming an editor and thinking about how the team can move faster, as well as helping to refine some of the details and keep everything moving in the right direction.
As you gain more traction, you will find increasingly many areas of the product and company to stay focused on. New useful roles will emerge which you didn't have to begin with. What's worked well for me is to embrace this expansion and try to handle many of these areas. When everything feels somewhat chaotic, its a great time to think about firing yourself from one or more of the areas. And that chaos is healthy I think. It can be hard, I've had many times where I felt I was letting people down by being stretched in many directions.
You'll start leaving money on the table, so become aggressive about firing yourself
Once you've grown to a stage where youre juggling many different areas and key metrics are growing healthily month to month, you'll start to leave money on the table by holding onto tasks. You'll be doing a less adequate job in many areas than someone else could who is more experienced in that speciality and has an opportunity to focus on the task full-time. It's key to start being reflective about areas of the company for which this is happening. It's then great to start hiring to remove yourself from the day-to-day of some of the roles.
The times my co-workers and I have fired ourselves
I first fired myself in a small way when Leo and I were fundraising after AngelPad demo day in the last 2 months of 2011. We needed to keep our traction going, so Tom had come on board as our first developer other than myself, and we also hired a contract marketer so that Leo could step back a little from the content marketing. It worked well: we continued to grow at a great pace and managed to secure $450,000 in funding from great investors.
A couple of months later, our support volume had grown quite high and Leo had been the one who decided to take it on so that Tom and I could continue building out the product. We soon realized that it was quite hard to manage, and that we wanted to do more than just manage customer support. Its now a core part of the vision of Buffer which is to be the simplest and most powerful social media tool, and to set the bar for great customer support. Thats when we started to grow our Happiness team and Leo gradually let go of support completely, to stay focused on Marketing, PR and Partnerships/BD.
Half way through 2012 while in Tel Aviv, we realized that Android was a huge potential area of growth and so I spent a couple of months learning Android and preparing a new version of our very minimal app which had thus far been developed by someone on a freelance basis. It was a real struggle to fit in learning Android as well as making progress on the actual app, alongside all my other tasks which were less maker and more manager. This is when I wrote my article about transitioning from a maker to a manager. Shortly afterwards Sunil joined the team as an Android hacker. He eventually fired himself from this role, too, and became our CTO.
In late 2012 and early 2013 we started to grow the engineering team further, and I began to code less and less. My key focuses were hiring, culture, investor relations and overall product and growth coordination. About 3 months into 2013 I decided to drop coding and become more focused on product. Stopping thinking so much about technical details helped me stay focused on the needs of the user.
Sunils role evolved a lot in the first half of 2013. Tom finished at Buffer early in the year (now doing great things with Sqwiggle which we use on a daily basis) and Sunil quickly switched over to Web and helped us grow a lot there. We then started looking for someone to take over Android so that he could focus on Web and eventually get into a position of overseeing all of technology at Buffer. In April we made him CTO and Carolyn became our CHO.
The most recent example of firing myself has been to step away from the day-to-day operations on the product side of things. Im still very much involved with setting the direction and being an editor of the product. I try to be one of the most active users of Buffer (I originally built it to solve a pain-point I experienced so this isnt hard) and I often spot things we need to adjust.
Stepping away from product has probably been the hardest example of this concept yet for me. I always viewed coding as a means to create something, but product itself is that creation itself. In December 2013 it hit me hard that by keeping hold of the role I was neglecting to think about the business as a whole, and I knew I needed to find someone to run it within the next few months.
I originally thought we might look for someone outside Buffer to help run product, then I chatted with our advisor Hiten and he planted the idea in my mind that I could ask people in the team to take over different parts of the role. I bounced the idea off Brian, our designer, and he immediately took to it. It only took him a week to be doing a better job of product than I ever was. Oh, and it probably comes as no surprise that were now looking for our 2nd designer.
When you do something yourself, youre not doing it well
Having thought about the concept of firing yourself further in the last few weeks, Ive come to a key realization: if youre doing something yourself as a founder of a post-product/market fit startup, youre probably not doing it well.
The way I see it is that if you are doing a task yourself alongside juggling all the other duties you naturally have as a founder, you have to make compromises. To put things into perspective, the areas weve identified as key tasks at Buffer currently are: Product (web and mobile), Engineering, Marketing, PR, Customer Support, Partnerships/BD, Admin, Growth, HR, Recruiting and Investor Relations. There are probably more, too. As CEO I have to have all these things in my head, and oversee half of them directly. As COO Leo oversees the other half.
With this much to think about, anything Leo and I are doing directly ourselves right now has to be done only partially. We both look for the 20% of the work which will get us 80% of the benefits, and cant do much more than that for everything were working on.
Therefore, as a founder, I think its important to approach firing yourself as a cycle, embrace it and enjoy letting go. You have to be happy to be an expert of nothing.
As an interesting final point, there might be another way to do this. Ive found it fascinating to read Rand Fishkin talk over the last year about the idea of a high-level Individual Contributor. A key piece on this was his article titled If Management is the Only Way Up, Were All Fd. I also found it fascinating that Rand recently stepped down as CEO of Moz and his role is now simply Individual Contributor. I love Rands idea of multiple ways to progress in a company.
Have you experienced your role evolve and the concept of firing yourself? I’d love to hear your thoughts on this topic. I imagine I still have a lot more self-firing to do yet!
Photo credit: Xavier
It’s an exciting time for Buffer. Toby Osbourn just joined and we’re now 16 people. Toby joined us as a Backend Hacker, and he’s been a joy to work with so far. Within just a few days we can all feel his impact.
In the first few days, Toby has been fantastic with asking questions and learning about the Buffer culture. One thing he asked me is how we think about email at Buffer. I thought that writing a blog post as the answer could help lots of other founders too.
Buffer Value #2: Default to transparency
One of our highest values at Buffer is to default to transparency, and we aim to live to this value in many dimensions. We stick to this through good times and bad, and we had a chance to demonstrate this recently with our unfortunate hacking incident. It was amazing to see the support we received by staying transparent and trusting our customers with the full details of everything happening.
Within the Buffer team we have complete compensation transparency and every team member knows each others’ salary and equity stake through stock options. We go all the way - we share whether we’re fundraising, we share when we have acquisition interest, and we share the bank balance. In fact, we share the bank balance and revenue numbers publicly.
Transparency builds trust and triggers better decisions
"lots of traditional, widely accepted, and perfectly legal business practices just can’t be trusted by customers, and will soon become extinct, driven to dust by rising levels of transparency, increasing consumer demand for fair treatment, and competitive pressure" - Don Peppers and Martha Rogers in Extreme Trust: Honesty as a Competitive Advantage
There are many reasons we default to transparency at Buffer, and perhaps the most important is that I genuinely believe it is the most effective way to build trust. This means trust amongst our team but also trust from users, customers, potential future customers and the wider public who encounter us in any way. For example, we have a whole blog dedicated to sharing everything about how we run the company.
By sharing all our decisions, numbers, successes and failures, we are showing our customers and supporters that we are responsible and strive to do the right thing.
Keith Rabois, COO of Square, put better than I ever could the second reason we place such a priority on transparency in an interview with Rob Hayes of First Round Capital:
Ultimately, if you want people to make smart decisions, they need context and all available information. And certainly if you want people to make the same decisions that you would make, but in a more scalable way, you have to give them the same information you have.
Defaulting to transparency with email communication
Narrowing down to the aspect of team emails, this is an area where we also strive for complete openness and transparency. Stripe do something similar and provided great inspiration for us.
When you start working at Buffer, it can come as a little bit of a shock. Instantly you’re receiving every email exchange between team members, in every single team. If you’re in our Happiness team you still see all the emails going on in the engineering and product team. You see design iterations and progress on our mobile apps. You see emails about our content marketing and work towards getting press.
This might sound a little crazy, and probably certainly seems totally overwhelming. But that’s the price we’ve decided it’s worth to have complete transparency. Nothing is more important to us. We have chosen to be open, and we find ways to handle the volume.
You also see emails of external communications happening. Interview requests, getting press and discussions with partners.
When you experience it, there is a magical aspect to it. You learn how Leo goes about getting us in all the top tech news sites when we launch a new feature. It all contributes to a faster pace of learning for the whole team, and means that everyone naturally knows a lot of what is going on.
How email transparency works in practice
We have several internal email lists, which only Buffer team members can send to:
- team@ - this goes to the entire team
- engineers@ - includes all our engineering team
- heroes@ - for our happiness hero (customer support) team
- crafters@ - related to content marketing
- design@ - for design discussions
- product@ - for product feedback and signals
- metrics@ - anything to do with company metrics
- biz@ - related to buffer for business
- bizdev@ - for BD activities (partnerships, integrations)
- marketing@ - related to press activities
Whenever you email something to do with Buffer, you almost always cc or bcc one of these lists. For example:
- email a specific team member and cc a list
- email an external person and bcc a list
- email to a list to notify a whole team
The general rules are as follows:
- if it’s “to” you, you’re expected to reply
- if you’re specifically cc’d, you’re expected to read it
- if it’s your own team that’s cc’d, you should read that
- you should strive to always cc or bcc a list
Handling the risk of email overload
Admittedly with a growing team the overall email volume has gone up a lot in the past couple of months. We’re so bullish about transparency that this isn’t a huge concern for us. That said there are a few things we’re doing to ease that volume:
- we’re starting to encourage filtering out some emails between other team members so they’re not in your inbox but they’re easily accessible and browsable
- transparency often simply means that you can access that information when you want to, not that it’s pushed in front of your face
- we’ve set up a private Facebook group to share links and emails that don’t need a reply. The concept of a “like” is proving to be very powerful for messages where you want to show appreciation but might not need to reply
Times when we might keep email private
There are a few times where email transparency doesn’t feel quite right. Usually this revolves around specific personal circumstances or a potential upcoming team change (e.g. a promotion or thinking about a firing). With this said, we truly strive for transparency and want to improve here too. Currently we try to always ask each other whether we can accelerate some of these discussions and bring in transparency.
How do you handle email at your company? I’d love to hear your thoughts on this topic.
Photo credit: Juin Hoo
One of the things I enjoy most about building a company is to focus on culture, and to think about how we can create a team which is a joy to be part of. A large part of this is creating a set of values and trying to gather people who feel at home amongst each other.
As part of this focus on culture, we have done quite a few things rather early at Buffer. We started to think seriously about culture when we were just 7 people and put our values into words shortly afterwards.
A realization my co-founder Leo and I had shortly after this was that if we truly want to focus on creating a great culture, it is inevitable that some people won’t work out and we would have to ask them to leave the company.
There is very little written on the subject of firing people, and it’s a hard thing to talk about, especially when you are still small. However, one of our highest cultural values is transparency, and for some time I have felt we were not being true to our values by not talking about this.
The journey to the current Buffer team
To put things in perspective here: Buffer is now a team of 13, and in the journey so far we’ve actually let 6 people go. For us, we’ve luckily never had financial struggles, all of these decisions were based around culture-fit. It’s hard work to hire people and even harder to fire people, so a team of 13 feels rather small for the efforts we’ve been through so far. At the same time, this team of 13 is a real privilege to be part of.
Hiring for skills vs hiring for culture
When I started Buffer, I had no real idea what culture is. We grew quite fast, and my intuition was to fill the gaps we had with the most skilled people I could find.
Once we reached 7 people, I started to see the importance of building a cohesive team that works well together and is a lot of fun to be part of. A large part of this is defining the culture and finding people who are a great fit for that culture. That’s when we put our culture into words and created our cultural values.
Once we had put our culture into words, that’s when we started to much more rigorously hire based on the values. In fact, it’s really hard to hire for culture-fit until you have your values in words:
“‘Cultural Fit’ is only a valid hiring criteria if you can accurately define your culture” - Chris Yeh
With our culture in place, we’ve evolved our hiring process and we focus a lot on the culture we have. This means finding people who are positive and happy, with a focus on self-improvement, who have gratitude, are humble and are comfortable with our extreme transparency. We have what we call a ‘Buffer Bootcamp’, essentially a 45 day contract period with 1:1 meetings for feedback at 2 weeks, 1 month and 45 days. A lot of this is to see whether Buffer is a good fit for the person joining the team.
With this more rigorous process, we found that some people didn’t fit the culture and letting people go was inevitable. Surprisingly, the very act of letting people go has shaped our culture more than anything:
"I think some of the core decisions that impact culture are who you let on the bus and who you make sure gets off the bus. The values that determine these decisions really shape your culture. Similarly, who gets rewarded and promoted within your company really shapes your culture. So, it’s the actual every day operating decisions that most shape your culture." - Dave Kashen
Culture is not about right or wrong
Although we’ve let 6 people go, these were all great people and they all did fantastic work. We just realized that they were not a perfect fit for our culture, so it made sense to part ways.
I would even go a step further and say that keeping people around who are not a great culture-fit is one of the worst things that could happen to someone. It has almost always been a mutual feeling when I had the conversation to let someone go: they felt some relief. I even have this quote on my wall to remind myself to think in this way:
"Waiting too long before acting is equally unfair to the people who need to get off the bus. For every minute you allow a person to continue holding a seat when you know that person will not make it in the end, youre stealing a portion of his life, time that he could spend finding a better place where he could flourish." - Jim Collins
Why letting people go is part of the process
I think firing someone is perhaps one of the hardest things you have to learn as a founder. Another key realization for me has been that letting people go is a continual part of growing a great team.
No matter how awesome our hiring process is, it’s inevitable that sometimes the person is not a great fit. Now that we have grown to 13 people and had to make tough team changes along the way, we’ve started to see a ratio emerge. We now know not to be surprised if about 1 in 4 people we hire doesn’t work out. It helps to know this possibility in advance.
"If you are super-scrupulous about your hiring process, you’ll still have maybe a 70% success rate of a new person really working out — if you’re lucky." - Marc Andreessen
This is probably one of the hardest areas of learning I’ve experienced as a CEO. I’ve spent a lot of the last 10 months thinking this through, reading as much as I could about it and getting lots of advice. We’re still at the very beginning, but it is comforting to have got to a point where this is a bit less scary.
Have you had to let people go while building your company? What do you think about the priority which should be placed on culture-fit? I’d love to hear your thoughts on this topic.
A special thanks to Leo, Carolyn, Belle and Sunil for reading drafts of this.
Photo credit: Katie Tegtmeyer
Buffer is a fully distributed team. It’s a decision I had to make at the end of 2012, and it’s interesting to reflect on that decision now. I am happy to report that I am in love with the choice we made to be distributed all across the world.
How Buffer is set up
When I say we’re a distributed team, I mean that we’re literally spread across the whole planet. Buffer is a team of 12 right now, and here are the locations of everyone in the team:
- 4 people in San Francisco, California: Leo, Carolyn, Sunil and myself
- 1 person in Texas: Brian
- 1 person in Massachusetts: BMR
- 2 people in the UK: Andy and Colin
- 1 person in Sweden: sa
- 1 person in Hong Kong: Michelle
- 1 person in Taipei, Taiwan: Niel
- 1 person in Melbourne, Australia: Belle
In addition, Michelle was in San Francisco until just a week ago, Andy regularly travels and sa just took a few months trip back to Sweden (she normally resides in Sydney, Australia).
6 reasons being distributed is so exciting
I think the distributed team discussion is often focused around the challenges. I wanted to share from our experience the fun side of being distributed, which I think far outweighs the challenges:
1. Our team is super productive
The thing about hiring people for a distributed team is that they need to be self-motivated and productive working at home, coffee shops or a co-working space. We have a 45-day contract period to see how this goes and we look especially for people who have worked as freelancers or on startups. Everyone on board is incredibly smart and it’s humbling to work with them.
2. Team members have incredible amounts of freedom
Have a family event coming up and need to travel on Friday? No problem. Want to take off to Bali or Gran Canaria for a few weeks and work from there? Awesome - please share photos :) These things have all happened and are regular occurrences within our distributed team. It’s the little things too, like being able to avoid a commute and spend more time with family. We don’t have working hours and we don’t measure hours at all. We’re all excited about our vision and we focus on results, balance, and sustained productivity.
3. It feels like the future
Even being able to share the locations of all my co-workers when I meet others and chat about Buffer is so much fun and exciting. I think it provides a great story rather than all of us being in the same office each day. People ask how we manage it and I share our workflows and tools. We call HipChat our office, and a number of Google Hangouts are our conference rooms. I genuinely believe that how we’re set up will be very normal in a few years. There are certainly challenges and we’re still figuring a lot of it out. It’s fun and a huge privilege to be able to be part of this innovation and experiment and share our learnings.
4. I’m learning so much about the world
People within the team speak lots of different languages and talking with each other we learn about what it’s like to grow up elsewhere in the world. We think carefully about shaping our culture further and how our choices might affect the various cultures within the team. Carolyn recently has kindly been educating us about Nashville:
I enjoy having internat’l coworkers for *many* reasons, but explaining the concepts of “honky tonks” and “line dancing” is high on the list!
Carolyn Kopprasch (@CaroKopp) August 26, 2013
5. We travel the world to work together 3 times a year
Part of the DNA of Buffer is that we traveled all over the world for much of the first two years. This is something that has been sustained and is part of our values (and many in the team have lived up to this value by traveling as part of the team).
In order to have deliberate face-to-face time together to bond and have fun, we have 3 Buffer Retreats per year, where we gather the whole team in a single location. We spend a week working together and also do activities like sightseeing, boating and jet-skiing. We had our first in San Francisco (and Lake Tahoe) and next time we’ll be heading to a beach in Thailand!
6. Timezones make you awesome
Finally, you can look at timezones as an inconvenience, or you can embrace them and discover the magic of the time difference.
A key part of our vision is to set the bar for customer support. We obsessively track happiness of our customers and our speed to respond to them. We have almost a million users and we reply to 50% of emails within 1 hour and 75% within 6 hours. We do this with a Happiness Hero team of just 3, and we couldn’t achieve this level of service without being spread across multiple timezones.
Timezones are a huge help for our development cycle too - with engineers in the US, UK and Asia, we literally never stop coding.
Do you have experience of working in or growing a fully distributed team? Or do you have any thoughts about working in this way? I’d love to hear from you.
Photo credit: Colleen Lane
As a CEO I often ponder how I can help the team be as productive and happy as possible. As part of our decision to be a distributed team at Buffer, there have been a number of amazing advantages this has brought as well as it making a fun team to be part of due to the many different cultures and locations of team members. Recently I’ve seen quite a number of articles about remote working, and I’m excited so many are sharing their insights. I particularly enjoyed Wade Foster's article on how they manage a remote team at Zapier and wanted to share some insights into how we do things at Buffer.
The decision to be a distributed team
During the few months I spent focused on the decision of whether to commit to Buffer being a distributed team, I sought advice from many people. Some of the best advice I received was from David Cancel, who I had the chance to sit down with and chat over coffee. His key insight was that in his experience founding a number of companies so far, he has found that two scenarios work well, while one doesn’t work too well. He advised that we either be fully distributed, or have everyone in the same office. David said that the time he had a main office with the majority of people there and only one or two people working remotely, that didn’t work so well.
With this insight and further thinking I made the decision and we became a fully distributed team. We immediately hired a number of people working remotely to quickly balance out the team and ensure we were fully distributed rather than a team in one location with just one or two remote workers. This was an immediate benefit to us especially as a team focused on outstanding customer support, since we quickly covered all timezones.
The delicate nature of a distributed team
The interesting thing I’ve found with a distributed team is that I believe it is a very delicate balance to ensure that everyone who is away from the main base location feels just as much a part of the team. What you don’t want is to end up with a scenario with people feeling like “second class citizens” if they are not in the base where the office is. Jason Zimdars from 37signals put this in the best way I’ve heard:
There are no advantages for people who come into the office, no disadvantages to staying home to get your work done.
I think this a super important quality of a great distributed team, and it is one we consistently keep in mind and something which causes many of the questions and choices around our distributed team.
Questions often in my mind while we grow as a distributed team
As a result of these difficult and important choices to ensure a distributed team works well, I often have some interesting thoughts and questions in my mind which to some could seem petty, but which I believe are essential to get right in order to thrive as a distributed team. Some of these questions we now have a confident stance on, others are things which still linger in my mind. I believe being a distributed team and figuring out the best path is a journey which will last the lifetime of the company.
Is it appropriate to have a base location?
This is a question I spent quite a number of months pondering. During the time, we were traveling the world having been unable to get visas to stay in the U.S. (we have visas now).
In the end, we realized that there are advantages to having a base location, depending on what your startup does. For us, we are in the social media space and we are regularly doing integrations with other startups. It just so happened these startups and the big social networks were all mostly based in San Francisco or Silicon Valley. Proximity to them was a huge advantage in order to secure partnerships.
Is it right to have an office in the base location?
For some time, we avoided having an office at all. By early 2013 we had a team of 9 with 4 in San Francisco. Some felt less productive working from home and coffee shops than they would in an office. We spent a number of months sharing an office with the awesome Storify guys and the team grew a little more, too.
We also started to focus even more on culture, and the whole team started to love the fact that the Buffer way was rather different to the norm. Being part of Buffer felt unique and we wanted to embrace this further by having an office we could call our own. I think most distributed startups have an office: GitHub and 37signals come to mind as good examples.
Another key reason we got our own office is that while a large portion of the team are not in San Francisco, we are planning regular retreats to get the whole team in the same place. The first will be in a month’s time and will be in San Francisco so we needed a sizable office to work together for the 10 day retreat.
In person meetings or everything via HipChat, Hangouts and Email?
With an office, if team members are in San Francisco it can be easy to delay meetings until all team members are in the office. I thought a long time about this and bounced the dilemma off Leo too. The conclusion we came to is that we should always do the thing we can do immediately. If we need to quickly have a meeting and we’re not in the same place, we should jump onto a hangout, even if we are in the same city.
In a similar fashion, we try our best to have a real bias towards chatting on HipChat and sending each other emails even if we are sat across from each other in the same office. By doing this we are really embracing the goal of there being no advantage to being in the office, and it also allows other team members to jump in and share their ideas in discussions.
Should we celebrate getting an office, or keep quiet?
This has been one of the most interesting recent questions I’ve had in my mind. Clearly getting our own office is a big milestone and feels very appropriate now that we are beyond 10 people and we are on a revenue run rate of over $1.5m a year.
We don’t want to shout too much about the office when many team members are not in San Francisco, that didn’t feel too good. At the same time, it is an exciting point to reach with the company. We’ve tried our best to find the right balance with this, however I’d love to hear any thoughts you might have.
What perks are appropriate when you have a distributed team?
At Buffer we’ve had a lot of fun coming up with some perks which are individual to us. We believe that perks are not something you can take and apply to any company. Rather, they need to be an extension and enhancement to an already ingrained culture. With our culture of self improvement, one of our most interesting perks is that everyone in the team is gifted with a Jawbone UP and this triggers discussion around getting good sleep and being active.
Most technology companies pride themselves with perks such as free meals and snacks at the office, as well as ping pong tables and other ways to take a little time out and refresh. The most interesting thing I’ve noticed is that the perks are almost entirely focused around what is provided within an office. A nice exception that comes to mind is Evernote who provide all employees with house cleaning twice a month and also pay employees to take vacation.
At Buffer, our answer to this dilemma is that we try to focus on “everyone included” perks which are not tied to a physical office. We give everyone a Jawbone UP and a Kindle Paperwhite, and team members can get any Kindle book free of charge with no limits or questions asked. In the future I can imagine other “everyone included” perks such as free gym membership and house cleaning.
What if people want to move to San Francisco?
The final question I want to share is a very interesting one: how do you manage having the right balance of people away from your base location of San Francisco if everyone who joins finds that they want to relocate to San Francisco? This is something we’ve started to encounter which I never imagined could happen. So far Leo and I have moved to San Francisco, Carolyn is moving next month and Michelle has obtained a visa to move towards the end of the year. We’re working on a visa for Andy too, who has already visited many times.
Unless we figure out this issue, we will end up with an imbalance and too many people in San Francisco. Other team members will be more likely to feel “out of the loop” and “second class” to those in SF.
I don’t feel like I can force people to stay where they are. As the CEO of a company where we have chosen not to delay happiness, and with a journey so far where we have found a way to travel the world while growing the company 300% year over year, I think it is my duty to help people move wherever they will be happy, whether that is SF or elsewhere in the world. It just so happens that San Francisco seems to be one of the most attractive places to be in the world.
My answer to this one right now is to keep hiring outside the Bay Area. This seems to work well since it is very hard to find people in the Bay Area anyway!
This is a portion of the questions I’ve recently had on my mind and currently are topics I’m thinking about. I feel it is a huge privilege to be able to shape the company and grow a distributed team. I’d love to hear any experience or thoughts you have!
Photo credit: Steve Cadman