Distributed work is hard. Company retreats to the rescue!

Working with distributed teams is hard. A key ingredient to helping teams gel is the good old company trip. Here’s how we do it. TLDR: Meaningful work plus some fun – not the other way around.

It’s been another crazy week in San Francisco!

One dear SI tradition is to send the entire company to the US once a year. Our Berlin and San Francisco  staff get to collaborate, and we can meet customers in person and brainstorm features. Additionally it’s a great time to slot in team activities such as sailing the San Francisco Golden Gate:


While last year’s trip focused more on longer term strategy, this year was mainly tactical, and it was a huge success! It’s not exactly cheap to fly the entire team across the world, but it’s an experience I’d definitely recommend to other startups – even early stage startups.

How and what?

Monday kicked off with a Beth Steinberg workshop, giving teams a chance to pick a seasoned HR practitioner’s brain. We’ve not been able to hire dedicated product managers yet, but we have assembled a team of highly product-focused developers, so for them to soak up Beth’s learnings was a perfect way to start the week.

Our R&D department consists of 3 empowered subteams that work independently on major features. Between Tuesday and Friday each team went to visit 4 customers, presenting their current work, soliciting feedback, and discussing next steps, while also sharing the overall product roadmap. Customers were carefully selected to align with the team’s respective features. Each dev team was joined by one Customer facing person, helping the departments gel.

In parallel, I went to meet a few partners, competitors and ex colleagues to pick their brains on topics such as product growth and marketing.

Key learnings

Get everyone together in the same house – no matter what! 


We managed to secure a large AirBnB house in the Mission. It had it’s quirks and certainly looks better than it sleeps — broken airbeds, rooms without windows, no locks on bathroom doors, you name it. But having everyone in one spot was really crucial, and once we had gotten accustomed (and rented a new airbed from an outdoor supplier),  the benefits of a single house really made a difference: a huge living room and three balconies/courtyards for work, great eateries nearby, and of course Bart access.  No hotel plus rented workspace could have created the same sense of team spirit.


One customer meeting a day is sufficient

Although 4 meetings in four days doesn’t sound all that much, proper preparation and debriefing did consume a lot of effort, and in a way each debriefing turned into productive feature-discussions quickly.  Teams could be heard debating client feature suggestions  late on the balcony late at night, and I feel this level of intensity could only happen because teams were not overwhelmed by meetings but had “only” one per day.

Ensure the roadmap can be reshuffled after the trip

It’s happy coincidence that most of our current features are wrapping up in the next couple of weeks. We came back with our heads spinning, there’s just so much we need to improve on, and so many client ideas that need to be worked into the roadmap. We’re now at it, debating and prioritising suggestions, and merging them with our “old” roadmap, and while we’re not done reshuffling yet, we will have a good merge available once the current feature work is wrapping up. Next time I don’t want to rely on luck though, but proactively plan ahead.

Fun activities are important, but engaging work is crucial

We’re no strangers to fun activities: This year we went sailing, explored an Escape room, and of course had some nice dinners. Last year saw a roadtrip down to Santa Cruz plus cycling over the Golden Gate bridge, and the year before that we went hiking. But as fun as it is, nothing helps a team gel better than exciting and meaningful work. For us, that’s customer visits and roadmap discussions. No amount of sailing can beat the experience of working shoulder to shoulder with your remote peers on wowing a customer.

But, the cost?

We’ve often been asked if it’s not a bit frivolous to send all developers around the world. Shouldn’t we send just the marketers and product managers? I think not. We’ve spent roughly $40k on this trip, but the benefits outweighed everything. We reduced “man in the middle” friction by having devs talk to clients,  we ensured that our departments gel, and having a clear goal (“be ready to demo to client by date x”) helped prioritising our work. The preparation and debriefing offered deep insight to everyone involved. And our distributed team being able to gel is priceless.

Rather than sending fewer people and saving on costs we’ll probably be sending more people. We have already encouraged SF staff to come to Berlin for 3-4 weeks once a year, we’ll probably increase this to twice a year. And we’ll be encouraging developers to make the trip in the opposite direction as well – it worked exceedingly well in summer in a pilot visit, and more trips are to come.

I see this as an investment, not as a cost.

Fun fact

This is the second time already that our Berlin based staff decided to grab the opportunity by its neck and extend the company trip by a weeklong private road trip.

It’s totally fine (even recommended) for the US team too to extend the trip to Berlin for a private vacation in Europe by the way. But an entire dev team living on the road together for a week and not falling apart, that’s really something to be proud of!

In summary

Although it can be stressful at time, I can only recommend the annual trip to everyone who a) has a distributed team, or b) sells to clients far away, or c) both 🙂

Meet our two new subteams

As our company grows and evolves, so do our best practices. In this episode: Team Delineation.

Early days’ bliss

Until very recently, all our customer-facing staff were assembled in one team of 5. I loved the flexibility this gave us: The same people who introduced evaluators to the product would reach out to provide demos, offer assistance during billing and roll-out, provide day to day support, help with marketing, ultimately working to ensure all customers could succeed well beyond their initial sign up date.

While everyone had their special skills, it was crucial for all team members to be versatile – Ready to jump in and help at every stage in a customer’s journey utilizing Small Improvements.  This worked perfectly in our early days.

Challenges started mounting

Yet as we grew from 100 customers to 700 in 34 countries, it became clear that we were faced with dwindling bandwidth and a need for structure. “A Jack of all trades, is a master of none” … It was time for us to grow as a team as well as organizationally, turning those special skills our customer facing team possessed into dedicated areas of focus.

In recently hiring a new customer support representative, the customer team is now 6 people strong. This was really pushing the limits of the old structure, so:

The new way

We decided to split the Customer Team into two teams: The Customer Success team of 2 which is only focusing on proactive outreach and client retention and the joint Support and Sales team of 3. While still collaborators in many ways, our goal is to target our resources having even more of an impact on the happiness and success of our clients and prospects the like.


Customer Success will be driven by two of our longest tenured staff members: Scott Faverty and James Nichols.  Support and Sales will be driven by: Tore Ingersoll-Thorp, Andy Fordyce, and our new hire, Sarah Burgess. And Linda who had managed the team in addition to her Marketing duties can finally focus entirely on spreading the Small Improvements love – and we’re hiring in Marketing too!

Support and Sales?

While the combination of Sales and Support may sound unusual at first,  note that our approach to sales is very different to the “normal sales” out there. We’re extremely light-weight, and go out of our way to not annoy potential clients. We’ll suggest a demo, and we’ll follow up by mail if the demo was received positively. But we’ll not pester anyone with spam or phone calls, and don’t even sell to companies whose business models we don’t agree with. Accordingly our sales process works without quotas. Thus, sales being influenced by our support channel makes an interesting and fruitful fit.

We’ve just started the process of defining and strengthening the work these two teams will champion, but we’ve already seen higher engagement from our customers! The future could hold even further refinement of structure and growth, but the focus will always be on the optimal way to deliver the best customer experience possible.

Learn more about our customer facing team on our website!

Boom! Five new developers on one day.

The hiring drought in our Berlin HQ is over! Our development team just grew from 8 to 13 developers, and we’ve been able to find a perfect mix too: We’re joined by two Java developers (Alison and Tobias, left-center and right), two AngularJS developers (Alexandre and Peter, middle) and one UI/UX developer (Kristof, left).

Five in one day? Surely we’ve lowered our expectations?

Not at all. 2014 was a very slow year, but since October we’re seeing a really steady stream of good applications. It took us a while to get there: Lots of employer branding, conference attendance and sponsorships, meet-ups and blog posts, and of course ads on BSJ were required, but the work has finally paid off. And our grilling process has remained exactly the same as always: Informal phone call, one or two on-site interviews, and then 2 days of trial work. No magic, just friendly applicant-grilling.

Admittedly, it’s sheer coincidence that everyone wanted to start on the same date. We made an offer to Peter as early as February, and then we inked contracts with Tobias and Alison in March. For a long time we thought that was it, until Kristof and Alexandre signed up merely three weeks ago, also with a starting date of June 1st. Crazy!

So in summary, there’s no secret sauce, and our applicant pipeline is now dry. 😦

What’s next?

The first week was a huge success already, we’ve conducted a proper on-boarding exercise that included plenty of technical presentations, meet&greet with the international CS team, pair-programming and naturally computer setup. It’s Friday evening now, and the first small feature improvements are already on master and deployed to production.

We’ve expanded each sub-team a bit (5 on objectives, 4 on user-import, 4 on the improvements team) and then most likely we’ll move to a 4-subteams-config once everyone has truly settled in. We’re not expecting miracles during the first couple of weeks, but since the grilling process was pretty intense we’re very confident that our feature&refactoring-throughput will increase substantially. Go team!

PS: We’re still looking for a Senior Java developer.

Our new office has doors.

Update: Here’s our official office-tour page.

We’ve loved our old office because it was very pretty, and its open layout allowed us to grow from 3 staff to 11 while being very flexible with our desks. We’ve hosted our international team members and had sufficient space to run public BBQs and Meetups. The old office cost us about $1600 per month for 115 square meters – a total bargain.

But also, it was getting noisy once we grew beyond 6 staff. Discussions needed to get planned ahead (or moved to a café nearby), and every applicant who came in was yet another distraction. We didn’t realize just how densely packed it was until seeing the bird’s eye perspective in our time-lapse moving-out-video:

Startups don’t have to use open plan offices

We don’t believe in open plan offices, but we’re not fans of private offices either. In our opinion, every team should have their room, and teams should be between 2 and 4 people. Teams should be able to chat and discuss without disrupting everyone else. Unfortunately, finding a matching office in Berlin is tough, at least if you want the office to be beautiful as well. Most beautiful offices were either too small, or only supported open plan layouts.

But after 5 months of reading very many ads, we finally signed a lease and moved in last week. We’re still busy refurbishing, painting and buying furniture and lamps, but it was worth the wait!

The office has a very interesting floor plan, no room is like the other, and there are lots of wide doors. We can keep the doors open for maximum inter-team communication, or close them during discussions. We’re placing couches into most rooms to support impromptu meetings, and there are several large and small rooms for longer discussions too.


There’s still a lot of furniture missing, and several rooms require renovation and painting, but here are two glimpses into what it’s going to be like:



Pricey, but…

The price tag is roughly $7000 per month (including heating and taxes), which is quite the stiff price tag for 270 square meters in Berlin. But location and style do matter for employer branding, and doors and flexible room sizes are crucial for productivity and employee happiness, so we see it as an investment. And yes, even as a startup you need to invest, and the benefits of a great office (with doors) outweigh the costs by far.

Fun facts:

  • The new office used to be a personal shopping area for a fancy clothing store downstairs, and we’ve kept the style of most rooms.
  • There used to be an actual bar in the red room above. It was taking too much space though, so we bought a (supposedly) 1830s travel-bar at an auction instead
  • O2 wasn’t able to provide internet within 4 weeks, so we’re using LTE for 11 people in the first two weeks. It worked surprisingly well once everyone had turned off automatic system updates…

We’re far from done renovating, but we’ll host a house warming party once we are. So ping us if you’d like to pop over for a drink from the mobile bar!

Unexpected UX session with the customer success team

Being a distributed team we can never communicate “too much”, so we’re making it a habit to always share news and recurring things like meeting minutes on our intranet.

But the best thing is when communication between teams “just happens”.

Below I shared a screenshot for an improved “this list is empty”-screen. First, nothing happened at all. Then the next day the customer success team in San Francisco noticed and started making suggestions. It turned from pure language-level suggestions into a real review of the user experience of that screen (the discussion went on for two more screens), and the resulting screen is of course much better than what we initially came up with in the Berlin office.


It’s nothing earth-shattering, I know, but I really love this cross team/ cross timezone thing, and how well it can work out even for the small things. We usually post feature specifications onto Confluence since it’s better suited for larger discussions, but using Hipchat for all the small things is just as great.

Pragmatic “user testing” at SI

We’re not religous about user testing, and most of our smaller features only go review by one or two people before getting deployed. But larger features can get a special treatment, and here’s how we do it.

It depends on the size of a feature, but before shipping a major feature, we typically work like this:

  • First, every developer needs to give their feedback, and we fine tune until we’re happy
  • Then we show the feature to a customer success agent, watching their screen while they explore. We tend to show a feature to the most enthusiastic person first, take their feedback on board, show it to the next person, and so on
  • Once all SI staff are happy, we pick one or two customers and let them explore a new feature while we watch (screensharing again). This often reveals entirely unexpected problems or shortcomings. A favorite user testing session went like this: We had rewritten a very large admin screen from scratch, made it tons more useful, stable, faster and prettier, and we were really proud of it. Our tester, a long term SI customer, looked at the screen briefly, muttered “yep, looks like always, nothing special here.” (we were silently crying at this point). Then she said “dang, there is still no preview-feature for emails that I trigger, does it have to be this cumbersome?”. This was her one feedback – and we realised that we had missed an elephant in the room. Fortunately, she did like the overall screen (although she didn’t realise just how much worse the original version had been) and after adding said email preview feature, she was happy.
  • Once we’ve satisfied two or three key users, we enable a new feature in beta mode for select customers to use permanently. We ask them via mail or phone how things are going, and since each of our application pages has a prominent “give feedback” button, we do hear when there are problems
  • In the next phase, we might announce the beta over our newsletter or via in-application notification, and allow customers to enable a new feature if they like. This increases adoption and feedback again.
  • In the final step, we switch all customers to the new feature, while leaving a “keep the old version?” button in place for another month or two. Once nobody uses the old feature anymore, we entirely drop it, and all associated code.

Well, it’s no rocket science really, but many applicants have been burnt by much worse development processes, so we wanted to share this!

How we plan and prioritize our work

Inevitably, all good applicants ask us this question: “so, perks aside, how do you actually plan and prioritize your work at SI?”.

First of all, we need to consider our overall goal:

“We want to build an awesome product, and enjoy coding and supporting it.

This guides the first two stages of filtering:

Ensure ‘Philosophy match’
This is something we always have in the back of our head. If a feature would make the product less awesome, then we won’t build it. For instance, we often get asked about adding tons more ratings. We don’t think that’s useful, we’re a feedback tool and not a ratings too. So that feature won’t be built at all.

Ensure “Technology match”

Some features would be awesome to have, but terribly to code. Internationalization is such a feature. Sure, having great German or French or Spanish language support would be slick – but it simply makes coding less fun, and each feature much slower to implement. Demand exists, but it doesn’t outweigh the downsides by far. We’re not touching internationalization for the next couple of years.


Once we’ve removed all the feature requests we don’t want to build, there’s still a massive amount of things we can pick from.

Next up, here’s our general prioritization approach:

  • We favor bugfixes over new features. We hate answering the same support ticket over and over again, so it’s more efficient to squash bugs with a high priority.
  • We favor incremental improvements to existing features over entirely new features. It’s better to have fewer but more awesome features, and you only get there by iterating relentlessly. So we are careful in opening up new cans of worms. We’ll ensure that existing features are awesome first.
  • We clean up code debt all the time. This slows us down in the short term, but helps us move faster longer term, and makes bugfixing easier too. Also, if we didn’t clean up debt, we’d get buried after a while, hate our jobs, and quit.
  • We build new features as well. It’s most fun of course. 🙂 But we usually wait until no other pressing work needs to be done before we tackle entirely new features.

Having this basic ordering is good, but there’s still a large amount of features and improvements to choose from. We need to consider efficiency as well:

  • How many customers will like a feature (or improvements) vs how many customers will not even use it?
  • How risky/hard is it to build?
  • What developers is available to build it, will they be efficient at it, and are they keen on building it at all?

The first items are kind of obvious and probably commonplace at most companies. Items 3 is not quite as common though. We believe that everyone should enjoy their work, so even if our AngularJS expert Sebastian is available for building a new AngularJS screen, and would be super efficient – well, if he needs a break and wants to work on the Java side for a month, then the task might get postponed.

If you’ve read this far, you might have wondered about “but, what about urgency!?”.  And that’s the really great thing about SI. It’s almost never urgent to implement something. Sure, we do want to ship a lot of stuff, and do so as fast as we can. We’re not slackers. But working under extreme pressure only leads to problems in code quality and morale, so we try to avoid it. By always prioritizing bugs, by always cleaning up code when we see it, bugs rarely linger until they are really urgent.

Sure, sometimes unexpected problems crop up, sometimes issues are urgent. Then we work on them immediately – but it’s usually not a problem if they take more than a day. We have built a pretty large test system that covers the backend and the frontend, so a massive unexpected problem is rare, and we haven’t done a single night shift in the 4 years of SI history.

So, summing it up, we first filter loads of things that look good on paper but don’t match our philosophy, and then we prioritize with a bias for bugfixes and improvements of existing features, and also take into account what each developer wants to work on.

It’s no rocket science, but we get asked about this a lot by applicants, so we thought we’d share it!