Mobile Jazz Company Handbook [pdf]
mobilejazz.com
mobilejazz.com
Alternative download (Google Drive) in case the server goes down: https://drive.google.com/file/d/16D90e7L7whbeRSCLxhZ_X3-K_3R...
EDIT: Added alternative download.
If only you would be looking for Audit/Security/Compliance, you would have my CV in a heartbeat!!
And that makes me wonder how do you manage GRC in the Team and the processes...
> Plan your day in Asana, then post your status update in Slack
In one of our comments in the other thread, you state that some colleagues will log in on the weekend to get work done, how do you manage colleagues working more than they should?
During the week we track time using Harvest (https://www.getharvest.com/) and the next week we review the planned time vs. actual time spent on each project (and overall) and adjust the planning as necessary. It's not 100% precise, but it works most of the time.
Besides the planning vs. reviewing part, we're very open and encourage discussion on the remote work and with flexible schedule topic. Some team members have a lot of experience and some are doing this for the first time, so sharing is important. Having a routine is an important element into a good work-life balance.
Some minor thoughts on the PDF: The bottom of page 2 looks like it has a clickable button on it (I'm not sure if that was intentional). Of the four colored titles on page 3 the PRODUCTS one stands out as not-a-gradient, compared to the rest. The font that looks hand-drawn feels cheap and Comic-Sansy to me, I'd prefer actual hand-writing or a font that doesn't look like it should have natural variation. On page 19, the Harvest window has a shadow that the other example images on this page and the next don't have, which looks inconsistent.
In general I do like the document, these are just nit-picks I thought you might find useful.
I suggest you don't write down in gray on white "by the way, we will also store your email". Put it somewhere either prominent or maybe outright have and opt in button for that? It's an industry wide practice, but that does not automatically make it ok.
I started out thinking "whoah that should be a great company to work with/at" and then the marketing thingie happened...
I'm glad to hear your company is also incorporated in Estonia. How well has it been working for you?
I'm also curious for your take on one question: you describe yourself as "a remote team working all over the world", and also say that to keep the team cohesive, you try to overlap with other members of the team four days a week, and use CET as your "standard" time zone. The globe diagram makes it seem like all of your team members are relatively close to that time zone.
How would you support team members living in locations that are farther away (e.g. the west coast of the US), given that overlapping with central Europe would require those employees to work either very early in the morning, or very late at night?
Currently the team is spread over Brazil, South Africa, Thailand, Malaysia, Vietnam, Germany, Austria, Czech Republic, Spain, Australia, UK. That said, 1/3 of the team is in Barcelona (where we started the company), but not necessarily Spanish. That said though, while we're quite diverse and from many countries and cultures, most of us do live in Europe though and once the summer is back we'll migrate back there.
So in summer it's quite easy for us, as we as a team sit closely together. However many of our customers are from the US West Coast and then the other extreme is a client in Australia. Winter time is then more difficult as some people go back home to Latin America or over to Asia. But so far we've always managed and actually sometimes it helps to have someone being in a different time zone. Makes it easier to monitor servers around the clock.
We do however require that team members do have a certain overlap with CET. Just in December I was myself in Brazil, so I simply started working at 6am and stopped around 2pm to go kitesurfing. Maybe not something everyone wants to do, but since our company is mostly about lifestyle everyone in our team appreciates that freedom, but also understands the responsibility that comes with it.
From your experience so far, do you think that the overlap requirement is essential to successfully running a distributed company? Did you have it right from the start, or is this something that you discovered you needed as you went along?
Still - it felt soooo 2000's. Give us your e-mail, so you'll get 32 instead of 31 shitty e-mails you don't read anyway. And without your email we won't do anything for you.
1) A recruitment tool
2) Marketing
Recruitment and marketing are definitely a good side effect, but as @znq mentioned earlier, we built the guide in the first place for onboarding our own team members, then we thought sharing it publicly would benefit the community.
It's not, to my mind, an actual corporate handbook -- it's missing boring important things like "here's our password and security policy, please remember we have people's super-personal health data in our apps, so it's really important". I guess that's probably in the company Wiki or similar.
However, this whole thing started out as a Onboarding Handbook for new team members. Then however we thought it's also a great book to share with the world. So we decided to remove certain items and have those in the internal wiki only.
These experiments range from little internal dev tools, to scripted spreadsheets, to open source libraries to even hardware projects. Sometimes an experiment is also just trying out a new way of running the company. For example MJ Talks and MJ University were initially experiments. Or our trip to Thailand in 2014 was an experiment. Now we do 5-6 company trips per year (workations, skiing, hiking, kitesurfing). Our bonus/profit-share program was an experiment that we started 11 months ago.
Also some of those experiments turn into products. At least we try. Some are successful and spawn their own company from it, e.g. Bugfender. Most experiments however failed to gain traction as a product. Maybe not because the idea/product itself was bad, but because we're a tech company and suck at sales and marketing.