It has been a planned feature right from the start. But many months went by and it sort of became the Duke Nukem of the web hosting world. I’m talking about the freistilbox self-service web user interface, of course. Often requested, often promised, never delivered. Now the time has finally come to prove this mythical creature actually exists!
When we started freistilbox as a two-founder team, we didn’t have the capacity to both build an enterprise-class web hosting platform and run a serious software development project at the same time. So we decided to focus on the hosting platform first and do the customer dashboard “a tiny bit later”. Little did we know that our growing number of customers would keep us busy building new platform features and improving the existing ones for quite a while…
At first, we didn’t worry too much because being in close contact with our customers has been and will continue to be a central aspect of our strategy. In fact, each support request asking for a new website instance was an opportunity to learn what our customers were doing and to help them get started quickly. But with every new customer, it became clearer that this approach could never scale. Not having a self-service interface caused confusion and frustration for our customers and an ever increasing amount of support tickets for our tech team. There was no way around it — we had to make a change.
The name of this change is “freistilbox Dashboard” and we’re launching it today! Simply go to dashboard.freistilbox.com and sign up for a user account.
If you’re already using freistilbox, don’t worry about the fact that when you log in for the first time, you won’t see much. That’s because your new account is not yet associated with your freistilbox resources. So, as soon as you’ve signed up, simply use the support chat button in the lower right to let us know, and we’ll connect your account with your existing hosting resources.
By the way: We plan to add this live chat to our official support channels and we’re using the Dashboard beta phase as an opportunity to put it through its paces.
Beta phase? Yes, the freistilbox Dashboard will be a work in progress for some time. It currently offers only a view of your basic hosting details and you can’t make any changes yourself yet. But we’re already testing its self-service features internally and will make them publicly available in January.
We’re very excited to finally be able to provide you with a customer-friendly web interface that spares you the effort of keeping your own list of website details and sending support requests for every little change. We admit that it’s taken us a long time to get this far, and we apologize for all the inconveniences.
We’re determined to keep our current momentum and will continue adding new features on a regular basis. If you’re curious what we’re working on at any given time, simply visit the public freistilbox Dashboard roadmap [Update 2016-02-22] issue queue and development milestones. We’ll happily consider all your feature requests, so please don’t hesitate to give us feedback and let us know what you’d like to see next!
Do you have any thoughts about the launch of the freistilbox Dashboard? Let us know on Twitter!
17 Dec 2015
Dear freistilbox customers, the end is near. The end of the year, to be precise. And just as many of you, the freistilbox team is taking the holidays as an opportunity to wind down, relax and recharge.
From Thursday, 24 December, we’ll be off and our technical support will be limited to real emergencies. So, should incidents occur that impact the operation of your production websites, our 24/7 on-call will get them resolved quickly.
Support requests that aren’t related to such incidents, though, will have to wait until we’re back on Monday, 4 January 2016.
There’s still a week left to get things sorted, so we recommend you get in touch as soon as possible if you need our support for a last-minute project or for work you’re planning for the time between the years.
From the whole freistil IT team, thank you for another awesome year, have a happy Christmas and a great start into 2016!
15 Dec 2015
Doing business without a central office has become more popular over the recent years. These distributed companies vary widely in size, well-known examples being Automattic, GitHub, AgileBits, Canonical, Acceleration Partners, Doist, Lullabot and Trello. Other businesses join in and get rid of their existing office:
The obvious advantages are savings on rent and a far wider reach in recruiting new team members without them having to relocate. But the “remote work” approach also has downsides that make businesses shy away from this approach, most notably Reddit and Yahoo!.
Five years ago, I decided to build a virtual company, and I’ve not regretted it ever since. In this post, I’m going to outline why.
After I had left my job as Head of IT Core Services at 1&1 in 2009, I had a few months of garden leave for deciding what to do next. I had started a number of IT businesses before, and the entrepreneurial itch was strong enough that I was going be my own boss once again.
My daughter had been born a year earlier and while sketching out my business (literally, using the Business Model Canvas method), I much enjoyed being at home with my family. When I was in a productive mood, I did some work. When I felt my mental batteries draining, I took a nap. When I wanted to cuddle one of my girls, I shut my laptop and went next door. When I needed a change of scenery, I packed my bag and left for Starbucks or the Botanic Gardens. Not until much later I learned that what I was enjoying was called “work/life blend”.
A few months later, I started an enterprise web hosting business. Right at that time, Jason Fried and David Heinemeier Hansson published their new book. In “REWORK”, they share their view of business, strategy, customers and how to run a successful team, and this view differs a lot from the common corporate approach. Immediately, I fell in love with their philosophy of “keeping it real”. Inspired by statements like “Planning is guessing”, “Mission statement impossible” and “Decisions are temporary”, I named my new company “freistil IT”, German for “Freestyle IT”, and I was determined to do business my way. For example, freistil IT was going to be set up from day one as a virtual business with its employees working remotely. I wanted everyone on my team to enjoy the same level of freedom, flexibility and sense of achievement as I did.
Running a remote team in a sustainable way isn’t trivial. While there are lots of tools that allow a distributed team to collaborate, it is a challenge to foster effective communication and build a coherent company culture. Quoting from REWORK:
“You don’t create a culture. It happens.”
But where does culture happen within a virtual company? When there is no central office, opportunities for a few minutes of chat don’t present themselves randomly. In a distributed team, communication and social interaction need to be much more intentional. Many of the things we had to learn you can now find summarised in the latest book from Fried and Heinemeier Hansson, “REMOTE — Office not required”. In the following section, I’m going to highlight what I found to be the essential aspects of remote work.
You can not overcommunicate
A company lives and dies by communication. And I don’t mean just the intentional transfer of information in one-on-ones and conference calls. That’s what email and a host of video conferencing tools are for. But on top of that, there’s a huge spectrum of information floating around freely within healthy companies. The fact that Sue finished her first marathon last Saturday. The huge enterprise deal Sales managed to win. The reasons why Alan’s putting in a lot of extra effort to make a certain customer happy. In a distributed company, this information doesn’t disseminate as easily as where people are co-located.
Project management platforms such as Teamwork (a great fellow Irish company, BTW) or Asana are important tools to coordinate work with a remote team. But as much as they give structure and focus to project-related communication, they can’t fully prevent frustration and loss of efficiency. “Why did she assign this task to me of all persons? Surely she knows that I’m already booked to my ears this week!” Yes, she does indeed; she just didn’t take the time to add a short comment that this task doesn’t need to be done until the end of next week. Had this happened in a real-world meeting, she would probably have noticed the frown creeping onto her colleague’s face, or the hesitation in their voice, and would have quickly clarified the timeframe. In written communication, though, this immediate feedback just isn’t available. You’ll only find out that your teammate is grumpy later, if at all. I’ve been guilty of the sin of omission so many times that I’ve put a sticky note on my monitor saying “You. Can. Not. Overcommunicate.”
That’s why in a remote team, the barrier to getting in touch with a colleague needs to be as low as possible. We’ve decided to use Sqwiggle as our internal video conferencing tool. Sqwiggle displays a photo of every team member, and you simply click one to launch a video call. More remarkable is the fact that these photos are actual snapshots that get updated automatically every minute. It takes a bit of getting used to “Big Brother” but this allows us to see at a glance who’s actually at their computer and available to chat. It’s like peeking into their office – well, it is peeking into their office. But it’s more than just practical: On a subliminal level, simply being able to notice the T-shirt someone’s wearing today or smiling about a funny facial expression in one of the snapshots strengthens the sense of working within a team and not in solitary confinement.
Much more than web chat
A running text chat can be the backbone of a distributed company. We started with using IRC, then switched to Campfire, later to HipChat, and now we’re among the 200,000 users paying for Slack. Within less than two years after it was created by Flickr co-founder Steward Butterfield, Slack has gained 750,000 daily users every day, and a 2.8 billion dollar valuation. There are reasons for this impressive success.
As a first impression, Slack is easy to the eye. Other than a plain IRC client and even other web chats like HipChat, Slack is nicely designed. You can already see how much thought went into this product when you log in for the first time: Instead of presenting you with a plain input form, you’re greeted by “Slackbot” who asks you a few simple questions about your details and sets up your account. Slackbot will also notify you of important events and send you helpful hints.
In Slack, you can create as many chat channels as you like and we’ve set up quite a bunch of them to keep topics separated. Here are a few conversation channels and how we use them:
- #company — our “virtual water cooler” where we talk about what’s going on. This is also the place to let the team know when we’re leaving our desk for a while: “Got to fetch my daughter from school, BBL!”
- #ops — discussing IT issues: “db12 seems to have an unusual load. Does anyone know why?”
- #backoffice — sorting out administrative stuff: “Do you think I should simply call them and ask why they haven’t yet paid their invoice?”
- #helpcenter — consulting the team on support requests: “Here’s someone having a problem with Memcache. You’re more familiar with it, can I assign this to you?”
We also have quite a few “log channels”. And that’s where Slack’s value for us goes through the roof. What differentiates Slack from other solutions is the huge number of integrations that allow us to connect third-party services to a chat channel. With these integrations, we can make sure we get all the information we need simply by subscribing to the right channels.
For example, we make an effort to respond quickly to support requests. While our ticket system will notify us via email, checking our mailboxes every five minutes would completely destroy our productivity. Instead, everyone doing support joins #helpcenter-log. Whoever is free to take on a new request and sees one scroll by can immediately click its link and send out a first reaction. It’s that easy to impress your customers.
Our on-call engineers subscribe to the #monitoring channel where our monitoring systems post continuous updates on the health of our IT infrastructure. That way, they’re able to spot a negative trend even before an alarm is triggered.
In #sales-log, we can see new followers of our Twitter account and who subscribed to our mailing list. Our CRM system also posts updates there when a deal is created, updated, won or lost.
If an update is important enough, we even let services post directly into conversation channels. A team’s Google Calendar might post a reminder for an upcoming conference call right into the team’s channel 10 minutes in advance. New tasks added to an Asana project trigger an immediate notification in the respective project channel.
Slack enabled us to switch from “information pull” to “information subscribe”. Instead of visiting an endless number of web services to get up-to-date on our work, we simply click through a few chat channels. What information is important always depends on the person, on their current role, even on the time of day. Slack allows every member of our team to curate their individual “river of news” from a vast pool of updates. It’s easy to join a channel, and with a click you can leave it again. If there’s a new project or topic, you simply create another channel and invite others with whom you’d like to collaborate.
It’s even possible to extend Slack to people outside of the company, and we’re experimenting with creating permanent channels for key customers where they can engage with us whenever they need.
Mind you, it doesn’t have to be all about work. Slack also helps us learn more about each other as persons. For that purpose, we have a #random channel where we post things that might not be important but interesting or entertaining. Here we post links to articles we’ve just read in Pocket, location check-ins from Swarm or links to new posts on our personal blogs. It’s another way of adding a human touch to sitting alone in front of a screen all day.
A business is a community
A team is more than the sum of its parts. In particular, a team is more than a few people working on company objectives. To achieve a common goal, we need more than tools to coordinate our work. The team machine needs the grease of social interaction. In distributed organisations, social interaction must be facilitated. I can’t just by chance meet Markus on my way back from the toilet and can ask him a quick question about the new test automation infrastructure. These interactions need to be actively sought by everyone on the team and encouraged by their communication tools. It’s similar to an online community where it’s the community managers’ job to foster lively exchanges. With Slack, we find it very easy to strike up a conversation because the combination of posts by team members and the additional information from external services creates a vast pool of opportunities to get in touch. Reactions can be as small and quick as attaching an emoticon to a colleague’s post, like a “heart” or a “thumbs up”.
Tools increase efficiency. Culture grows effectiveness.
With electronic communication tools, there’s always the danger of them doing more bad than good. Information overload, notification fatigue and constant distraction come to mind quickly for everyone who’s ever used Instant Messaging and Social Networks. That’s why it’s important to create a common understanding of their intended purpose and clear expectations for how to use them early on.
We use Slack as a synchronous, real-time communication channel, just like the phone or video conferencing. The convention is that whoever has the time to respond will join the conversation. The others who miss it (intentionally or not) will be informed of any important results in due course. Especially during “Away From Keyboard” time, this prevents FOMO (“Fear Of Missing Out”). While it’s great to be able to scroll back to see what I’ve missed during lunch, I’m not expected to catch up on everything that went over the wire during my absence. Especially after having a few days off, I can rely on my colleagues to have documented everything important somewhere outside of Slack. I can start off again with “Chat Zero”.
Chat notifications help with getting a quick response – when they’re used sensibly. The latter part is important because constant electronic nagging will quickly erode any willingness to keep the chat client running during work that requires any amount of focus. That’s why we use the “@person” or the even more sweeping “@channel” mentions only in exceptional situations that require immediate feedback from a person or a whole group. Everything else we’ll either ask another time later or move to an asynchronous medium like email altogether.
While our Sqwiggle snapshots show who’s in front of their webcam at the moment, we found this indication not reliable enough to determine who’s available to talk. When I’m in a coffee shop, it may be too loud for productive conversations, or I might not even have the necessary bandwidth for a video connection, so I’ll keep Sqwiggle closed although I’m able to chat. Another time, I may want to be visible to my team in Slack but not be distracted by non-urgent messages. So we’ve agreed to switch our Slack status between “active” and “away” to indicate if we’re okay with having a conversation. That way, we avoid the frustration of asking questions into the void without getting any response.
These are only a few examples of how important it is to create a common ground when you’re using electronic communication tools. Especially for people who are new to an organisation, it helps tremendously to have an understanding not only of the “how” (using them efficiently) but also of the “why” (their purpose and the organisation’s expectations around them). That’s why we’ve written a “company runbook” that explains all the different services we use as well as how and especially why we use them.
In five years of working as a remote team, we found that when we apply powerful tools with a clear intention, they create an ROI by orders of magnitude. Slack is a great example.
30 Oct 2015
Yesterday, the Drupal core team made Drupal 8 Release Candidate 1 available. We won’t have to wait much longer for the final release of the best Drupal ever!
Holly Ross from the Drupal Association highlights the improvements in the upcoming release:
“With Drupal 8, the world’s best content management framework just got better. Every built-in theme is responsive. Every single component is translatable out of the box. More elements have configurable fields and there are new field types for better content modeling.
It’s built people-first. The authoring experience is better, with features like in-context editing and enhanced previews. It’s easier to add people-friendly meaning via native schema.org markup. There’s extensive support for accessibility standards.
Drupal 8 also has all the geekery you can Git. All-new configuration management (full exports, easier transitions between environments) means safer, faster site development and maintenance. REST-first native web services enable 3rd-party integrations. And adding Twig is the most complete transformation of Drupal theming in a decade. It allows friendlier syntax, better security, and a separate presentation layer.”
Drupal founder Dries Buytaert is excited as well:
“Historically, the adoption of Drupal has roughly doubled with each new release. We expect no different from Drupal 8, a release I believe positions Drupal most strongly for the future. We’ve undergone some big architectural changes to get more people using Drupal, and to prepare ourselves for the future. I can’t wait to see what the community does with Drupal 8. It’s time to start building!”
Yes, it’s time! Our engineering team has been busy over the last weeks, and we’re happy to say that freistilbox is ready for Drupal 8!
To prepare freistilbox for the requirements of Drupal 8, we’ve made a bunch of changes to modernise our web server setup. All our new freistilbox clusters make use of new software versions to make your website fly.
First of all, your application will enjoy the improvements in functionality, performance and stability that come with PHP 5.5.29. For example, we’ve replaced the APC opcode cache extension with the more efficient Opcache built into the PHP interpreter.
With the switch to PHP 5.5, we’ve also upgraded Apache from version 2.2 to 2.4. Its lower memory footprint leaves more memory to your web application. The Apache team also did a tremendous job at performance tuning. While Apache had a reputation for not being as fast as other web servers such as nginx, the new Apache version definitely measures up with its competition. Many of the new features and options in Apache 2.4 open up opportunities that we’ll use to make freistilbox even better over the coming months.
Due to changes in its configuration syntax, Apache 2.4 may make it necessary to
.htaccess files. See the
For a quick and easy application setup, you can avail of Drupal 8 versions of our
pre-fab configuration snippets.
Simply use “d8” in your
Of course, our new and improved Drupal 8 setup is available not only to new customers. So if you’d like your existing cluster upgraded for Drupal 8, just send us a support request!
Until the final Drupal 8.0.0 is released, there might still be slight changes necessary. Rest assured that we’ll be quick to adapt freistilbox so you can launch your shiny new Drupal 8 website on release day!
09 Oct 2015
When we launched our Managed Hosting service back in 2010, we quickly found that using Git for application deployment was a bit of a challenge for our customers. At that time, distributed version control systems just weren’t widely used yet and many people had no experience with Git whatsoever when they started hosting on freistilbox. So we did our best to keep Git usage as simple as possible.
This is the reason that up until now our deployment system only used the “master” branch of the website instance repository. While you could use any branch in your local development repository to work on your web application, finally the code had to be pushed to the “master” branch on the hosting platform side. If you use multiple website instances for staging and testing you’d push to multiple remote repositories but it would always be to their “master” branches.
Over time, our customers got more proficient with Git and started to adopt multi-branch development approaches such as “Git Flow”. With their Git skills growing, more and more customers started asking for a more symmetrical deployment concept. They’d expect that their “master” branch would go to the production website’s “master” branch, “staging” should go to the staging website’s “staging” branch and so on.
We’re happy to report that finally, multi-branch deployment is here. From now on, you can choose the branch from which each website instance will deploy code.
At the moment, you’ll still have to push to a separate repository for each website instance. But don’t worry, deployment to different website instances from a single central repository will come eventually, so please bear with us.
Until then, you can set up your working repository like this to make things as easy as possible:
git config remote.production.url <production repo URL> git config branch.master.remote production git config remote.staging.url <staging repo URL> git config branch.staging.remote staging
With these settings, a simple git push from the “master” branch will upload your changes to the production instance and a push from “staging” will automatically go to the staging instance.
Are you already excited to test the new branch deployment? Simply send us a support request and let us know the site ID of your website and which branch you’d like us to assign to it.
We hope that this change will make your daily development work a little bit easier. Drop us a quick tweet to @freistilbox to let us know if it does!
28 Sep 2015
Coinciding with the opening keynote of their CTO Dries Buytaert at DrupalCon Barcelona, Acquia today announced the expansion of their European business. In their PR statement, Acquia claims:
“With data centres now located in Germany, Ireland, and eight other regions around the globe, Acquia is the only Drupal platform service provider to offer pan-European support for high availability sites that accomodates EU data sovereignity requirements.”
We beg to differ.
Since 2010, we’ve been specialising in Drupal and WordPress hosting focused on high performance and availability; first under the “DrupalCONCEPT” brand and, starting in 2012, with our Managed Hosting Platform freistilbox. As an EU-based business, freistil IT has been compliant with EU data sovereignity requirements for over five years now. The data centres hosting our physical IT infrastructure are not only based in Germany but, equally important, also owned and operated by a German company.
On top of fully accomodating EU data sovereignity requirements, freistilbox is compliant with the German “Bundesdatenschutzgesetz” (BDSG) which is widely regarded as the strongest data protection legislation in Europe. German businesses that process client information protected by the BDSG are required to sign a “Vertrag zur Auftragsdatenverarbeitung”, a contract for the commissioned processing of data in which the hosting provider guarantees that both their technical infrastructure and their IT processes meet the strict requirements of the BDSG. The fact that we do has won us the trust of many privacy-conscious customers, for example the Federation of German Consumer Organisations and Doctors without Borders.
In conclusion, while we happily welcome Acquia’s initiative to strengthen the high-quality Drupal hosting market in Europe, we’d like to set the record straight that they’re certainly not the only provider of high-quality Drupal hosting accomodating EU data protection requirements, much less the first.
22 Sep 2015
In a strange kind of tradition, we’re launching our new website for the freistilbox user documentation today. We’ve copied all articles over from our Zendesk Help Center (and will remove them there soon in order to avoid confusion). We’ve also used this opportunity to update and improve many of the articles and FAQ entries.
The motivation behind starting a new documentation website was threefold:
- Efficient content maintenance
- Fast and effective navigation
Efficient content maintenance
As every developer knows, documentation is likely to be treated subordinate to implementation. Especially in a small team such as ours, there’s always work waiting either to improve existing or to build new feautures. In this environment, documenting how these features work or how to use them most effectively is often postponed to when customers actually ask about them in a support request. That’s not the quality of user experience we’re aiming at.
Additionally, maintaining content on a web-based system like the Zendesk Help Center is not the most efficient process when you’re used to writing in your finely optimised text editor of choice. That’s why we’ve been creating our documentation articles in Markdown text files stored in a Git repository for a long while now. On the one hand, this made the actual writing convenient and provided us with a change history for every article. On the other hand, publishing a new or modified article meant that we had to first convert it to HTML, then copy and paste it into the web form and then add additional metadata like tags/labels. The prospect of this tedious manual workflow didn’t exactly invite to make changes, so there always was the temptation of making changes directly on the website – and losing them again with the next update done correctly from the stale Git repository version.
Our new freistilbox documentation website is built with the Middleman static site generator. As until now, we write articles in Markdown and commit all changes to Git. But now, we can publish changes simply by making a git push to the central repository on Github. This push then triggers a CI process which runs a number of tests and (if they were successful), publishes the generated HTML files to Amazon S3 where the website lives.
Yes, we actually run tests on our documentation. At the moment, they only check that our source files adhere to a common Markdown style guide. In the future, there could also be tests for bad writing style such repeated words or overlong sentences.
Our new content publishing workflow will enable us to extend and improve our user documentation with the least effort.
Fast and effective navigation
We felt that using the Zendesk Help Center not only was less efficient for writing content, it also didn’t provide the best user experience to our customers. Finding the right article quickly is essential when you’ve got a question or issue and you’d like to check the available documentation before contacting technical support.
That’s why we’ve added a powerful search function to our new docs site that offers auto-completion and starts showing search results even while you’re typing. Behind the scenes, we’ll also get statistics that’ll help us improve our documentation based on actual search behaviour.
At the bottom of each page, you’ll also find a list of related articles that touch the same topics as the article you’re currently reading.
These improvements will help you find relevant content faster than before. We also hope they’ll reduce the number of support requests so that our engineers can spend their time on more demanding issues.
Search is just one example of how we wanted to make our documentation website as extensible as possible. This requires having full control over its inner workings, which we can’t get by using a third party solution.
Another small example is the link at the bottom of each page that actually allows editing the article in true open source fashion. Since we manage the content in an open repository on Github, everyone who’d like to make improvements to an article can fork the repository, make the necessary changes and send us a pull request. Simply click on the edit link and send us your suggestions!
Over the coming weeks, we’re going to add more features and, most importantly, more documentation that will help you using freistilbox better. If you have any feedback for us on the new website, write us an email or ping @freistilbox on Twitter!
11 Sep 2015
In the first week of August, we met for the latest installment of our company retreat named “freistil Days”. As a remote team, we come together every 5 months in order to strengthen our relationships and to do things we can’t do otherwise. On each retreat, we learn something that helps us improve the next one. In this post, I’ll explain what we learned this time.
The question of how long our retreat should be and how the schedule should look like is now pretty much settled. A whole week from Monday to Sunday has proven long enough to get a good bit of work done and short enough to limit the impact of our absence on the business and our families. We’ve arranged the schedule in a symmetrical way:
- Monday and Sunday are designated travel days.
- Midway through, Thursday is a good opportunity to do sight seeing so we get out and about a bit.
- This leaves two pairs of work days where we focus on projects.
Just like the previous times, we had prepared a schedule for these work days with time slots for project work, daily business, eating breaks and spare time. It hadn’t occurred to us until this time how hugely different this was from our normal year-round modus operandi. As a remote team, we trust that everyone knows their objectives and goals, and will work towards them. We don’t dictate when or how this work is to be done, though. This freedom creates a space for everyone to find their individual approach to working effectively. Halfway through these freistil Days, the Emperor’s Clothes question was finally spoken: “Why is our company retreat, of all things, the complete opposite?” We weren’t able to find a valid reason, so we decided to ditch the time slots, allowing everyone to decide individually when they’d work on freistilbox Solo, on support tickets or on other urgent business and when they’d rather lie down and read. From there, things got a lot more relaxed and (as expected) we still got a lot of work done.
Taking a break from work in the middle also does for a nice change. This time, we visited Hamburg’s Speicherstadt with the “Miniaturen Wunderland”, the world’s largest model railway. The amount of effort that went into building hundreds of square meters of model landscapes is amazing. And the control centre (see photo) was quite impressive, too. (Hey, we’re IT geeks.)
In advance of a retreat, we identify two or three projects on which we’d like to focus while we’re sitting around the same table. This time, we’ve decided to work on one customer-facing and one internal project.
The launch of our entry-level hosting plan freistilbox Solo has been delayed for months because we decided to base it on a new IT architecture that will also help us improve our existing enterprise hosting platform at a later time. freistil Days gave us the opportunity to focus on getting the new architecture further ahead and while it’s not finished, we’re much closer to a usable product now.
Behind the scenes we had noticed that our development workflows needed improvement. Now that there’s a whole team working on automating our IT infrastructure, the usual issues around collaboration, testing and releasing changes made us rethink how we do “infrastructure as code”. On a lovely Wednesday, walking along the green riverbanks of the Alster, we came up with a simple Continuous Deployment process that will give us everything we need with much less manual effort than before.
Spending a whole week together as a group certainly is a big difference to our normal team experience. All the unavoidable social interaction tends to draw a lot of energy, especially for introverts (which all of us seem to be to different extents). After a few days, our lunch conversations became less engaging and silent pauses got longer. Towards the end of the week, we all felt a bit exhausted.
So it was a good decision to get rid of the rigid schedule because this will allow us in the future to take time off the group whenever we like, whenever we feel it’s necessary.
On the plus side, we got a better understanding for each other and more clarity about our strengths and weaknesses.
Third time’s the charm! Our freistil Days in Hamburg advanced us as a team and as a company. We deepened our relationships and made progress on our products and internal processes. And most importantly, we had a lot of fun!
If you’d like to see for yourself what freistil Days (and the rest of the freistil year) are like, get in touch!
21 Aug 2015