Be more available to the rest of the team

At MarsBased, we've been following the "Less is more" approach in many areas. We prefer to develop fewer features and, then, evolve them. We prefer to have a limited set of tools over too many of them doing small things. We like to reduce meetings to their minimum expression. And, after 8 years of running the company, we don't even have accounting software.

But there is an area of the company where we were not following this approach: we always tried to deliver as many hours as possible to our clients, making the most of our employees' time.

Let me explain it better.

Our developers work either 20 or 40 hours per week for a given client. We make sure that he/she does these hours and gets as little distractions as possible from other stuff.

While we consider that email, internal communications and certain in-company collaborations are part of their job, there are always things that come up, affecting their daily schedule: for instance, an issue from another project where they used to be assigned, and therefore they're best suited to fix it, or someone needs help with a specific technology right now and this developer is the right person to help.

We've been extremely protective of our developers. Sometimes, even, some former clients reached out to them to get some help "on the side" and that's a red line we're not willing to allow.

While this protective approach has been good to grow the team and the company and to optimise for our employees' outcome, this has also meant that our developers and tech leads haven't been usually available to collaborate and support on other projects. We have siloed, if you will, our own team.

This, in turn, has created a stronger dependency on higher-level roles, like the CTO, which is not assigned to any specific project but is there to support everyone. This, of course, creates bottlenecks and prevents us from doing other C-level tasks, making our developers wait longer for support, feeling more isolated. In a lesser degree, it also happened with our tech leads.

In the last few months, however, we have started to reverse this situation.

We have started a policy of everyone can help everyone. If a developer needs help with, say, Capistrano, and we know that Pablo is our expert in Capistrano, this developer will ask Pablo for help provided this doesn't take a significant percentage of his working hours away. But if it's a couple of hours only on a single week, we know that this impact will be negligible in the long run. Moreover, maybe next week, Pablo gets some help from someone else for 2-4 hours for another matter, so it ends up evening out for the clients of both projects.

I can tell you that I'm surprised of how well this is panning out. It's working better than we had anticipated.

In order to enforce more cross-project collaboration, we encouraged our employees to have more available time to support other projects and we are now actively suggesting who could help solve every specific problem, regardless of their seniority. No need to wait for the tech leads of the CTO to be available.

This will also help us to overcome the impostor syndrome we often have individually and collectively.

So far, we have received very positive feedback from these measures. People do not only feel more connected to each other and enjoy sharing knowledge with other team members, but also we have reduced the time to solve some of these issues by not making them dependent on a single person's availability.