Update: see the latest version of this document on our Handbook.

NiteoWeb is a distributed team of Web experts spread around the World. While we do rent office space in Ljubljana, Slovenia, most of us work remotely. Here’s a quick overview of how we go by our days.

Communication

Instant messaging is done through Slack on different channels (operations, support, development etc.). We have daily standups at 9AM UTC on Google Hangouts when everyone has a minute or two to say what they’re working on and if they need any help. Once a week, Dejan has “catch ups” (better known as 1-on-1) with everyone on the team to keep himself in the loop.

About once or twice a year we fly the whole team somewhere nice and we’ll have an “IRL” (in-real-life) meetup. Here we discuss company status, projects and the future in a group setting.

Then there are ad-hoc in-person meetups that happen about once or twice a month, as needed.
Some of us might get together to watch a talk at a local conference or we go to lunch together to discuss project work.

Project and Company Management

Project and task management is currently done with either Plan.io (being slowly discontinued) or GitHub. Support handles tickets through GrooveHQ. We also have an internal document system (intranet) we call “intra”, running on Plone, where all our company processes and documents are stored.

We track cash flow with Xero. Finance reports are published to intranet on a monthly basis and are viewable to all full-time team members.

Monthly company newsletter covers the main events of the month and is a great reference point for digging deeper into parts of the company one does not know that well.

Development

NiteoWeb runs several SaaS projects, serving a few thousand customers. We use several techniques, libraries and services that allow us to make several deploys to production every day. That does not mean that we do not test code before shipping it. Rather, we have a workflow that runs a variety of checks and automatic tests and makes it very fast and easy to test new features in staging environments.

And even if we do push buggy code to production, we only push it to a fraction of users to minimize impact. The outcomes are great: happy users, since they get features and fixes fast. And maybe even more importantly, happy developers, since the code is actually being used minutes after being merged rather than being stuck in a bureaucratic production deployment workflow. Nejc has given numerous talks on the subject.

Setting Goals and Deciding What To Work On

We subscribe to the 12-Week Year philosophy for planning and goals. Every beginning of the quarter we review what we’ve done and if we hit all goals. Then we plan for the next 12 weeks (everything is of course viewable on our intranet). The time interval is just short enough for actual week-to-week plans while also being long enough to get things done.