Running an effective software engineering organization is a formidable task at the best of times. Being a startup – especially when the core product is software – adds an extra dimension of difficulty on top of this because of the need to move fast and deliver in an extremely resource constrained environment. For extra difficulty points, add the fact that the product is open source and that the team is fully-distributed globally. At Cerbos, this is the situation we find ourselves in.

We are advocating a rather radical approach to tackling authorization by decoupling the logic from the application. To be successful in this quest, we have to ship a rock solid product that makes the transition easy and delightful while making sure that it’s secure, performant, and easy to deploy on various infrastructure stacks where our users run their software. Because we ship a packaged product that is self-hosted and because it’s developed in the open, there are very few – if any – corners to cut. Naturally, this means quite a lot of research, design, engineering, testing, and performance tuning before each release. In many organizations, delivering something similar would take many teams, product managers, Kanban boards, planning meetings, estimation meetings, standups, retrospectives and more. I certainly understand the purpose and value of these practices when applied correctly. However, in my experience, quite a lot of organizations tend to create a cargo cult around them and treat them as things to tick off in a checklist rather than picking what makes sense for them. Quite often, the predictable end result is loss of productivity, morale, velocity, quality, and innovation.

As a fully-distributed team with teammates literally living on the other side of the planet, there’s almost no suitable time that works for all of us to gather for meetings or standups. Therefore, we have chosen to eliminate mandatory meetings completely. All our coordination work happens asynchronously and in writing. Things that need to be done are written down as GitHub issues and added to a board. Any teammate can do this. We trust each other to know what’s important and best for the product. Other teammates comment on the issue to clarify details or suggest alternatives and improvements. After the idea is refined this way, someone picks it up and starts working on it. The implicit understanding is that the work takes however long it takes to make it shippable without adding any technical debt. That includes refactoring if necessary, writing automated tests, performance and regression testing and writing documentation. During development, feedback is sought by way of comments on the original issue, pull requests or impromptu Slack/Video conversations. Important architectural decisions are made on special GitHub discussion threads that are preserved for posterity.

This way of working may seem anarchical and idealistic but it has worked wonderfully for us so far. We have managed to maintain a high development velocity and deliver new features at a steady rate while keeping a healthy codebase that has almost no technical debt. Empowering the engineers by trusting them and giving them the freedom to be creative while maintaining a good work-life balance (we have no fixed work schedules either; everyone’s free to work the hours they prefer) has paid off handsomely. Most of the absolutely crucial and much-loved features in our product came about from individuals having an idea and just exploring it further. If we had constrained them to rigid schedules and deliverables, it’s unlikely that those innovations would have ever materialized.

To sum up: don’t feel pressured to do what everybody else seems to be doing. Get rid of unnecessary ceremony and constraints. Focus on creating an environment that gets the best out of your people. You might be pleasantly surprised by the results.