BeBanjo develops solutions for the Video On Demand industry. Our products help companies like AMC Networks (creators of Mad Men and Breaking Bad) in the U.S. or Sky, Channel 5 or BT Vision in the UK to manage their Video On Demand Services. We pretty much help them with everything they need to do in order to make their content available on multiple platforms and devices; this includes keeping track of their content and acquired rights, putting together a schedule, preparing content metadata, tracking the operational processes and publishing it all to the end platforms.
We have 14 employees:
- 6 developers (3 in Madrid, 1 in Asturias, 1 in Berlin, 1 in London)
- 1 Systems Administrator (Madrid)
- 1 Designer (Asturias)
- 1 Technical Account Manager (London)
- 1 Office Manager (Madrid)
- 1 Sales exec (currently in Israel, previously in Paris)
- 1 Operations Director (London)
- My co-founder and Myself (Madrid)
So in total: 7 in Madrid, 3 in London, 2 in Asturias, 1 in Berlin, 1 in Israel
Our office is in Madrid, but only 3 or 4 of us come to the office everyday (mostly the ones that have young children and cannot find peace and quiet at home...). The others come whenever it makes sense, but they are free to work from home or the office.
We do. In fact, we make a point to. Our market is so niche that we knew from the start we needed to be perceived as an international company because we would not be able to survive if we focused in Spain only. Hiring foreigners has enriched our company in many ways. Additionally, all our internal and external communications are in English (campfire, email, invoices, website...).
Completely flexible work day, except if it is your turn to do support. The support responsibility is shared amongst all developers and the sys admin: one week each. If it is your turn, you are expected to be working during business hours. However if you can’t be around for whatever reason, you just need to find someone to look after support while you are gone.
We only hire people that are self-motivated and we trust them to be responsible with the hours they put in the job. We have learnt that it is immediately obvious when they don’t, so no one polices how many hours people are putting in.
For development, the main tools we use to collaborate are GitHub, Campfire, Google Hangouts and email.
-
GitHub: Absolutely central to our development process. We not only use it to store our source code, but also to track everything we are doing with GitHub Issues and associated Pull Requests. I speak a little bit more about our development process in the last question.
-
Campfire: We use campfire to have an open line of communication with pretty much everybody in the company, except maybe the sales guys, who tend to get lost amongst the technical jabber going on. Conversations usually start on the “BeBanjo only” room which is where everybody is, and then people will break off to other rooms to keep the noise down.
We also have a hubot robot we lovingly called “Bender” which helps us with a few things (and with internal trolling, of course). Here is my favourite command!:
Many of us use Flint as a campfire client.
-
Google Hangouts: They beat the hell out of Skype and are free.
-
Email: Our email is on Google Apps and we use it for any other type of communication that doesn’t fit the above, or for private conversations or non-urgent things.
For collaborating and giving feedback on design, we recently started using Layervault. When it comes to design, it lends itself much better to iteration than GitHub issues.
Lately we are also using Freckle for time tracking if we do any bespoke work for our customers, such as integration, training, etc.
Aside from these tools, we also use Dropbox and Basecamp when we need to collaborate directly with our customers
How do you prevent your employees from working too much? And how do you promote a healthy work environment?
Here are a few examples:
- We make it clear that no one is going to be policing minutes and that everyone is responsible to put in the time they reckon is reasonable
- No one gets the evil eye for leaving early or coming in late
- Developers are encouraged to stop at a reasonable hour, or are free to come in later if they are tired or need to run an errand.
- Burning the midnight oil is just not something we do. We’ve done it in the past a few times and have always regretted it.
When did you start allowing employees to work remotely, and was it an immediate success? If not, what were the initial stumbling blocks?
From the beginning. Our first hire, for instance, was based in Berlin although he eventually moved to Madrid and is now in London. We (5 of us) then worked together in Madrid for a while, but our offices were so miserable (no cash!) than we would often work from home and would come in only to catch-up or pair-program.
It has required some fine tuning along the way and we’ve also seen that some people are better than others at working remotely. When in doubt, we’ve asked new hires to spend some time in the office for the first 1 or 2 months to learn about our products and about how we work; sometimes the new hires were the ones requesting to work in the office for a while. This approach has worked really well.
How do you promote a company culture when employees aren't in the same location? Is there a requirement to come into the office at certain times? A quarterly or yearly meet-up? Something else?
We find that company culture is hard at the beginning (you don’t have one yet!) and it is very dependent on your first few hires because they become the core of your company, and it is important to be in sync with them when it comes to values and beliefs. In our case we think it did help being in the same city for the first few months and having a chance to get together if we wanted to. It is also exciting when you are starting and is nice to be able to bounce ideas off people in person. However, if I were to start a new business, I would focus on finding the ideal people independently of their location, which is what we do now.
If the company culture you promote is good enough and you are able to retain some of the core people, it becomes easier to promote a certain company culture, because new hires will tend to do what the veterans do.
Another thing that has helped in our case has been that our developers were very active in the Ruby on Rails community; they would talk wonders about BeBanjo within the community and this has given us access to a lot of good developers who would come to us looking for a certain way of working and a certain set of values. These new guys would assimilate the company culture in no-time because they were already aware of it.
How did you get past the "trust" issue (i.e., how do you know your employees are working if you can't see them)?
I’m not sure we ever needed to “get past” the trust issue, but rather have avoided the “trust” issue altogether by:
- hiring only people we feel are trustworthy, professional and skilled. Gut feeling plays a role here, but in addition to that, we always bring people in to work with us for at least a week; we give them access to campfire and our tools and the chance to interact with us. This is a great way to clear/confirm any doubts we might have had when meeting that person.
- once we decide to hire someone, we try to create an environment to enable them do their best work by giving them the chance to choose on what they work on, making them responsible for their decisions, asking for their opinions and trusting them to decide on technical matters, etc.
If despite all this I find myself wondering often about someone in particular (“what has he been doing?”, “where is he? I never see him online”, etc...) it is generally a very bad sign. If we end up discovering that it doesn’t quite work with that person, then we try to part ways as soon as possible and look for someone that we can trust.
We find that some people are better than others at working remotely: self-motivated, knowledgeable and passionate people normally are good candidates for working remotely, whereas people that require management or motivation or that lack the skills to be productive in a short period of time, normally aren’t. This is key to us when we hire: we only hire people we reckon are going to work well remotely.
Good writing skills are also important for remote workers; things are far easier to misundertand when written than when said face to face and people's feelings can easily be hurt, specially those of people that are working remotely and are isolated from their peers.
We are very proud of our KanHub tool. This is a simple “kanban” board we’ve built during breaks that uses GitHub Issues as the back end. It:
- is a small Sinatra and Javascript app running on Heroku
- uses GitHub for Authentication, making it really easy for new developers to hop on board
- uses GitHub's Issues API as the backend, so there is no db maintenance for us to do
- has become the central hub we work around each day.
I try to explain a bit more how we use it in this video (~3:40)