Work schedule

Client guide

Client guide

Our typical working hours are 9am-6pm CET, with one hour dedicated to lunch.

Because we also use a time tracker to keep track of how many hours we actually work on client projects, you can expect an average of 7 billed hours/day, with the remaining hour being consumed by breaks and other interruptions.

Investment time

We also only work four days/week, from Monday to Thursday. Our Fridays are dedicated to study and self-improvement: developers experiment with new tools and practices, work on open-source projects, write new posts for our blog… Whatever makes them better professionals or makes Nebulab a better company is fair game!

We know giving up 20% of the week is a huge undertaking for our clients, and we are extremely thankful for this opportunity. With that said, spending some time to improve our craft every week allows us to stay on top of our game and deliver more and more value every day. In other words, these experiments have a tangible impact on the quality of the work we do for you!

Our investment time policy also makes Nebulab an attractive workplace for the top professionals in our industry, which allows us to offer you an ever-expanding range of services.

As a rule of thumb, our developers will skip their investment time for up to two weeks in case of emergencies, personal vacation, holidays or any other events that would reduce the number of work hours in the week.

What if I need more hours?

If you are afraid that 32 hours/week are not enough to accomplish what is needed, you always have the option of scaling up the team.

However, most clients find that, even with only four days/week, their team maintains a velocity that allows them to accomplish all the scheduled tasks. We suggest, at the very least, trying it out and seeing what works for you.

Timezones and remote work

Because most of our clients are in the United States, we have mastered the art of working remotely and asynchronously in a way that makes us more, rather than less, efficient.

However, we can only do this with your support! By adopting a remote-first, asynchronous culture, you will not only improve the quality of our work together, but also the efficiency of your entire team. Here are some recommendations:

  • Make information public and available. Do not require team members to ask you for information, but make all the details at your disposable available upfront where they can see them. One example of this would be describing Scrum stories exhaustively before the start of the sprint, so that developers can work on them without having to go through you first. Also, keep all information public unless it absolutely needs to be private, so that the entire team can access it if needed.
  • Minimize synchronous communication. Sometimes, face time is needed to deliver information in the appropriate context or to reach consensus around a particularly difficult decision. Most of the time, though, asynchronous communication in a Slack channel or a Google document is actually the better option: it gives everyone time to collect their thoughts and respond appropriately without forcing them to all be present at the same time.
  • Use timezones to your advantage. Processes should be structured such that any timezone differences are a strength, not a weakness. For instance, you could have your development team deploy to production when they get to work in the morning and your customers are all going to bed, minimizing any service interruptions.

With the right mindset, a remote team can supercharge your project. All it takes is a little effort and creativity!