Silence Means Assent
The FreshBooks development team is a group of peers. There are team leads, but we don’t have a single senior person who makes all or most of the technical decisions, or who sets the technical agenda.
Following this practice can lead to some messy times, when different people on the team have different ideas as to what’s the best plan. For example, deciding to use Python for our new data access layer was long-fought decision. Consensus can be a tough goal to reach, but at the same time, FreshBooks is growing fast and we need to make changes in an alacritious manner.
At a recent team discussion, we decided on a principle we call “Silence Means Assent”. It works by the combination of a couple of principles:
Everyone on the team has the right to raise an issue and propose a solution.
If you don’t offer any comments on a proposed solution, you are assumed to support the proposed solution.
- If you don’t implement your solution, it’s not going to get done.
A system as big as FreshBooks is guaranteed to have plenty of places where it behaves sub-optimally. What Silence Means Assent does is allow any developer on the team to take ownership of any issue, just by proposing a way to fix it. It also means the whole team has taken responsibility for ensuring that the solutions that go forward are properly vetted and have an assortment of brains applied to them.
In practice, what tends to happen is that folks who care about a particular bit of technology or functionality get involved in discussions about changes around those bits. Of course, for some stuff we do need to have a “gatekeeper” role who acts as the final word. However, those roles have emerged from the team, not been mandated from above. And even in those cases, somebody who wants to make a change just has to make sure they get the gatekeeper’s approval, and away they go. We haven’t set any time limits or anything like that — currently we just rely on folks to wait a reasonable amount of time for feedback. Most people will send out a “Hey, haven’t heard anything, gonna change some stuff,” email after the first one, just to make sure everyone’s seen it. But in general, the process works very well.
What this means is that technical decisions are owned by the whole team — if something does go wrong, the whole team bears responsibility for the bad decision. This encourages people to jump in on technical conversations, share knowledge and be great wing-persons for each other. It also means that our technical decisions can happen faster — we don’t need to try and assemble everyone in a room, hear all the opinions and try to reach consensus or elect a decision-maker. We start from a default of consensus, and rely on the team members to speak up when they can’t go along with the proposed solution.
The whole process depends on trust from start to finish. People making proposals trust that their proposals will get a prompt and thorough review. People reviewing trust that their suggestions will be taken, or else counter-suggestions made. Everyone trusts that any unresolved concerns will be addressed prior to implementation.
Of course implementation itself is subject to a more formal procedure of review and testing — this is just for the design process. And FreshBooks keeps getting better and better….