UTRUST has been a challenging project from day one. The goal is ambitious, like all attempts to change the world. The development team behind this massive undertaking collectively merges the experience of dozens of projects from a variety of fields. We always bring to UTRUST the best we have learned from all our experience.

But this is a project like no other. Building a system that bridges the common user into the revolution of cryptocurrencies is requiring us to reach far beyond what we knew until now. We experiment, and we study, and we devise practices, standards, and processes so that we can excel.

Growth always comes at a cost and, in our case, the expansion of our development team caused the entropy in our communication to increase significantly. Being up-to-date with the pains everybody was feeling, coming up with solutions to keep the ball rolling, questioning assumptions, or even agreeing on new approaches started becoming sluggish. And as the project grew faster and faster, we could not afford to slow down.

So, the developers of UTRUST decided we needed to meet and talk about our work. We call these our “Tech Discussions”.

Open agenda

The goal of these meetings is simple: to align the development team. This is the time and place to discuss a problem that has been slowing or even blocking our progress. It’s the place to start a discussion about possible solutions or to suggest and debate over the best approach. It is also the place to share decisions that affect the entire project or simply shed some light on something we feel should be addressed.

These meetings are always informal moments. We start by having each person add whatever topics they wish to discuss to the list. No censorship and no need to prepare anything in advance. Then we go through every item on the list, one by one. Whoever proposed the topic has to introduce it, and free flowing conversation does the rest. No stone is left unturned, although we try to be quick if the list is very long (it seldom is).

Since developers represent around half of the UTRUST team, we take care to prevent these discussions from turning chaotic. First, one person talks, the others listen. If the argument heats up and people start interrupting each other, the team stops the argument and schedules a work session specifically for working on that topic. Second, people speak freely, but we try to keep it short. If the discussion starts to digress too much, or if the topic is controversial, we move the conversation to a work session. Third, we work as a kind of democracy, meaning that we respect the wishes of the majority and act upon that decision. If someone suggests something, and the majority of the developers disagree, we work on an alternative instead. If the team is too divided and consensus cannot be reached within the session, we move the discussion. This can be a work session, a collaborative document, an asynchronous discussion on Slack or Asana, etc.

Every week

Tech Discussions happen every Friday at 11 AM Western European Time, with very rare exceptions (like a retreat). They last for around 1 hour, usually less, rarely more. Every developer is invited and welcome, but attendance is not mandatory. If those attending don’t have anything to share, we wrap things early. But as long as someone has anything to share we’re there, listening and discussing.

Weekly meetings have worked well for us. Some sessions we have little to no item on the agenda, while others are packed with a wide range of topics to discuss. The frequency of these meetings prevents people from having to pile up multiple issues, and at the same time limits the impact these discussions have on everyone’s schedule.

Focused on the result

No topic is excluded during the Tech Discussions, but there is one requirement: whatever the outcome of the discussion, it must be documented and acted upon (if applicable). This means that if a new approach is suggested and the team agrees with it, then someone will have to at least document it. If an issue is found and there’s consensus on a solution, then someone will have to make it happen.

Every outcome is assigned to a person who’s accountable for seeing it through. Outcomes are listed alongside the suggested topics in such a way that the team is free to check for progress and query the person in charge about them. We also keep a history of both issues and outcomes and thus avoid having the same discussions over and over again.