With María now on board at Travis CI, we gain not only a new and awesome team member but a newly represented country in our remote workforce!
María is joining us from Madrid, Spain, as a member of our customer support team! Helping people comes naturally to her. She has helped set up assisted communication technologies for people who have difficulty speaking and communicating; she also volunteers in the Spanish ASL open-association with plataformaafectadosela.org and redela.org!
When she finds the time to do things for herself, María enjoys film photography and roller skating. Cooking is also a hobby of hers, as she's mastering delicious crêpes and brownies. Up for a challenge, she has also taught herself a bit of Android development by creating a couple of Android apps.
Help us in wishing María a warm "Bienvenido", on Twitter as @amalulla! And, should you run into María in one of our support channels, be sure to give her a high five!
We are ecstatic to announce that Emma Trimble has joined the Travis CI team!
Emma hails from Pennsylvania, and is now part of our growing "Pittsburgh office" (it's like Berlin but with more rust)! She is proud to be a nerd, and has been using Linux since receiving her first computer. She has a degree in Information Science and a few years experience doing ops and sysadmin work as well as a number more tinkering on her own.
When she's not at a computer or a tech meetup group, Emma can also be found rock climbing, or playing board games with her fellow nerds. She is also a big fan of video games, and the occasional anime series. And, of course, while doing any of the aforementioned, she will almost certainly be listening to music.
So let's have a warm welcome for Emma, on Twitter as @emdantrim! And for those of you heading to DevOps Days Pittsburgh, come say hi! She'll be there along with some more of our North America team and a few special guests coming in from Berlin!
Many of our friends are expats. Some of them have found a very nice financial setup: Berlin costs, Bay Area salaries. It works well for a developer, being able to choose wherever they want to live. It works well for the employer, who would pay just as much for a developer in Silicon Valley or San Francisco.
After all, what matters to the company is the value provided by their employees, not the living costs they have.
A Bootstrapped Company
When Travis CI started off in Berlin, we needed to think about every cent we spent. Not being VC funded meant a constant financial shortage.
In fact, in the early months I was the only one getting paid. As a post-grad drop out, I had no savings to rely on.
Even suggesting California level salaries would have been preposterous. And why would we? After all, we weren't living in California, either.
Learning by Doing
Oh how things have changed. Travis CI growing has been a great but surprising journey every step of the way. Half of our team is remote now, most of them in the US.
Over the first six months of 2015, we have more than doubled our team size.
Our approach to almost everything has been to figure things out on the fly. As chaotic as it can be, I like this approach a lot. You create structure as needed. You have to go through sometimes quite painful issues that could probably have been avoided, but this way you will know why you want a solution. Us moving away from an unlimited vacation policy comes to mind.
In fact, I find the parallels to how I learn and internalize software paradigms uncanny. I did not understand why I'd want to (sometimes) use dependency injection until it solved architectural issues I was facing.
One of the things we never really figured out are salaries. And we still haven't. This might sound surprising. After all, we are paying more than twenty salaries each month (you get paid monthly in Germany).
If this is something you didn't expect, then here's a little secret for you: Most startups haven't figured out salaries, either. Small companies usually determine if a salary is reasonable or not solely comparing what a potential hire is asking for to whatever their current employees make.
This is not necessarily a bad thing.
I should probably point out that some startups follow strict rules for salaries. Buffer, for instances, uses a formula to determine salaries, no room for negotiations at all. They even went as far as publishing their formula together with all the salaries they pay.
Larger companies usually use "pay bands" to determine upper and lower bounds each salary can fall within.
We want to hire great people and we want them to be happy. While pay is just one part of that, it matters.
Living off a California salary in Berlin is great. Living off a Berlin salary in New York, not so much. This is a problem we don't have a generic solution for at the moment, except that salaries within Travis CI differ.
When we started off with Travis CI in 2012, our plan was to pay everyone the same. And this might be a valid solution.
This opens up a few questions, amongst them:
Are we able to hire people anywhere in the world?
Can we pay competitive salaries? This would mean paying attention to market rates.
Can we pay salaries people can have a decent living on? This would mean paying attention to living costs.
We are planning to have better answers for this at some point in the near future.
One thing became quite clear though: "I guess a good salary in X is higher than in Berlin" is way too vague to determine if we're paying well.
So I started looking into regional differences.
My first foray into the world of regional differences was based on living costs. There are some great websites out there. If you're planning to lead the expat life, tools like Nomad List are a great way to get the big picture.
My favorite site on this topic is probably Numbeo. It gives a very detailed insight into costs. It ranks locations by a variety of indices based on consumer prices, rent, a combination of the two, groceries, restaurant prices and local purchasing power, compared to New York.
However, the cost of living isn't everything. While living costs show it's more expensive to live in major cities in the US, the differences aren't enough to account for the differences in pay.
Part of this is of course a difference in wealth. I do think that developers are generally wealthier in San Francisco than they are in Berlin.
But part of this is also due to different spendings, not just different costs. For example, in the US, it is quite common to own a house and have massive debt from student loans, both quite uncommon in Berlin.
Either way, it became clear that we should be investigating market rates as well.
I started off with looking up salaries for companies I knew on Glassdoor. I quickly realized that I could pull aggregated numbers for different regions and job titles from it as well.
Glassdoor works well for the US and some other English speaking countries. For other places, not so much. So I started looking at numbers from Payscale and comparable German and international websites.
Two things bothered me about this: First of all, I didn't feel like they gave the best picture, especially for places with a low submission rates. I felt like both top earners and lower income employees might not be using these websites to report their salaries. Moreover, it seemed to me like I could not compare results from one source to another, due to different audiences, data quality and underlying calculations.
For certain regions, I found sources that would give a more complete picture: Governments. A lot of industrialized countries publish extensive data on their job markets. For the US, you can even access every single H-1B visa application, including salary.
So I collected all this data on different costs and rates from different sources all around the world and soon I was drowning in numbers without a good, overall picture. It became clear that I needed to do some math with these numbers.
I wrote a small Ruby script calculating a factor by comparing it to the data I had on Berlin. As a result, it generated tab separated values for each location, which by the way looks gorgeous on GitHub.
The script followed these rules:
Calculate factors separately. From the most reliable ones, choose the largest factor (in dubio pro reo).
Only compare values from the same sources (ie, never compare market rates from Glassdoor to those from Payscale).
Only compare values of the same type (ie, never compare average salary to median salary).
Prefer median over average. Ignore market rates beyond the 90th percentile and below the 10th percentile.
If data for a city is missing, fall back to country data.
This worked out pretty well.
Then I went on vacation. And while my vacation was great, I spent a lot of time on airplanes, busses or just not feeling sleepy yet. I didn't want to work directly on Travis projects, but I also didn't feel like doing open source work. So I played with the numbers.
To judge on the competitiveness of salaries, factors based on market rates are ideal, as living costs would give lower results for IT centers like San Francisco.
However, this would not be fair to countries with high costs of living, but weak economies. The application therefore picks the higher factor.
If you look up a specific location, it will give you a lot of details on the different factors that make up living costs and market rates.
Once I had the basic application running, it became clear to me that I could do some visualizations based on the data.
An obvious one was coloring a world map based on these factors.
Another interesting graph is comparing living costs to market rates. Looking at the graph, you can see that most points fall more or less on one line.
It should be pretty obvious even without aggregating any data, but the graph shows what I'd expect: If people generally earn more in one location, cost of living also tends to be higher.
There is one lonely dot though at the top of the graph: Monaco. It has a living cost factor of 3.47, but a market rate factor of only 1.31. I do think these numbers make a lot of sense: Most people that live in Monaco probably either don't work there or don't work at all. Most people that work in Monaco don't actually live there.
I did the same thing over and over: Copy the factor from the site and do some rough calculation with it. Either use it to just multiply a hypothetical salary, or to calculate a fixed offset (which is comparable to what Buffer does), or for some other way to see if I can compare two different salaries.
Also, I'm lazy. Or at least I think I'm lazy. And like most developers, I assumed building a generic solution once is significantly less work than copy-pasting a few numbers around.
And now there's also a calculator built into the application.
It can be used to compare salaries for different locations, using different formulas. It automatically converts between currencies. And it can change the location these factors are based on (which by default is Berlin).
I honestly don't know, but at least I feel like I have a better picture of regional income differences.
If these insights helped you in one way or another, or you have suggestions on how to improve and extend this little app, we'd love to hear from you.