Empower People: Decentralized Technical Decision-making

Francesco Strazzullo interviews Francesco Tassi

What does it mean to truly empower your team to make (even tough) decisions? What makes a decision important? How much do you struggle making it? How much money is involved? Or maybe what type of impact do you think that decision will have?

Francesco Tassi answers these questions in this in-depth conversation with Francesco Strazzullo. The interview is taken from Decision-making for Software Development Teams, the latest book by Francesco Strazzullo—published by Avanscoperta.

A freelance contractor for Soisy, Francesco Tassi has extensive experience as a software developer, and in this chat we explore the topic of complex decision-making within a fintech company.

Francesco S: Hello Francesco, nice talking to you. Before we start with this interview, I would like you to introduce yourself and tell us something about Soisy.

Francesco T: Hi Francesco, thanks for the opportunity to share my story. I have been a software developer professionally since 2002 and I’ve enjoyed coding since I was about six years old. As a developer, I consider myself an agile and extreme programming practitioner. I’m also passionate about self-organizing/self-managing teams and horizontal or flat organizations. I’ve been involved with Soisy as a freelance contractor for the last two years.

Soisy is a fintech startup providing a buy-now-pay-later solution for e-commerce, fueled by peer-to-peer investments. Basically, Alice gets to pay for Bob’s TV in instalments, and he gains some money funding it, all without a centralized bank providing the money. Soisy is a small team (growing, but still small), and the organization is almost entirely flat. The decision-making process is heavily decentralized, not only within the tech team but in the whole organization.

Francesco S: I would like to discuss how you make technical decisions in Soisy. What is the most crucial decision you made as a team in the last year, and how did you tackle it?

Francesco T: This is a tricky question. What makes a decision important? How much do you struggle making it? How much money is involved? Or maybe what type of impact do you think that decision will have?

How you feel about a decision before making it is not the same as thinking about it in retrospect (welcome unknown unknowns). I will pick two examples of different decisions to explain what I mean: psalm and Haskell.

We decided to be stricter about types in our codebase (mainly a PHP codebase). We introduced psalm, created a baseline and chose not to accept any new errors identified by it in our codebase, integrating the tool in our CI process. One member of the team thought it would be a good idea and opened a PR for it. Another peer developer reviewed it and agreed to it, so he merged the pr.

From that moment, it was part of our daily routine. Who proposed it became an evangelist (sort of), paying attention to related questions on our slack channel and organizing a few training sessions. We never looked back, and nobody ever proposed to remove it from the toolchain, not even in the early, painful stages.

It started as an initiative from a single person, but the team recognized it as a valuable tool and adopted it. It seemed a small decision at that time, but in retrospect, it was an important one because it affected how we write our code a great deal.

The other one is about how we extracted a bit of our monolith into a Haskell microservice. Once again, this started as a proposal from a single dev. However, he asked for feedback in our dedicated slack channel before implementing anything in this case. We quickly realized that we needed to involve some business people in the decision flow to be sure not to consider only tech aspects, and so we did. We ended up (down)sizing the domain we wanted to port to Haskell and considering it an experiment. At that time, “experiment” meant mainly that it could fail and that we were aware of the potential cost of such failure (the worst-case scenario would have been rewriting it in PHP).

We also agreed on pair programming for the implementation to ease knowledge sharing in the team. As a matter of fact, at that time, just one team member had Haskell’s expertise. To mitigate the risk, we started some internal training also.

The example about Haskell felt a lot “bigger” than the one about psalm. The latter was heavier than the former, but mostly, I think, because it carried a lot more uncertainties, not necessarily because it was more “important”.

In general, we try to shrink down any decision as much as possible and configure some experiments any time we can.

Francesco S: You brought two very interesting stories. Before a deep dive into the two decisions and their differences, I would like to talk about the decision-making process you use in Soisy. From your examples, I imagine you have a very unstructured decision-making process. Tell me more about it.

Francesco T: I wouldn’t say unstructured, but it is decentralized. There is no decisional hierarchy, nor are certain decisions restricted to some people (excluding a few exceptions due to the banking regulatory system and laws). This is true for the whole organization and not only for the tech team.

We embrace the concept of a “distributed CTO” regarding the tech team. The idea is that we don’t want a single person acting as CTO, but we want the group to behave like one. To achieve that, you really need to empower people and allow them to take even tough decisions. Usually, telling someone to go ahead and decide about anything he/she cares about is not enough. People need to feel they’re doing the right thing, not just something they’re allowed to do.

How do you make people feel safe about making a tough call? We came out with a system that relies on feedback from peers. The more challenging the call, the wider the feedback you will seek. Given that you can use several decision-making tools, we implemented some suggestions to pick the right one, based on two dimensions of the issue itself; we try to identify the decision’s impact and how much the effects will be reversible. Usually when we go from “low impact, easily reversible” to “high impact, hardly reversible”, we go from deciding on our own to involving the whole team.

It is not only the number of people involved that changes, but also how deeply you involve them. Sometimes you may want to consult with other people, other times you may want to allow anybody to consent or express an objection and block a certain decision.

The decision tool you choose determines the number of people involved in the process and how deeply they are involved. Basically, we try to dynamically adjust the delegation level between the whole team and the single developer, decision by decision. Keep in mind that all this is based on subjective evaluation. There is no possible way to know for sure what will be the impact of a decision (sometimes you just don’t know, and you discover it only in retrospect), nor you will ever be able to say, “this decision will have an impact on 3 out of 10”. We simply accept that we might just use the wrong tool from time to time, and we accept that changing “how” you’re making a decision is always possible.

Again, feedback from your peers is king. My perception of the impact or reversibility of a decision might be wrong, but our collective perception usually isn’t. And we’re building experience over time by choosing the right tool for the job. It’s not always easy, but you get better at it over time.

To support the whole process, we created some tools and practices. For example, we have a slack channel dedicated to consult- ing the other dev. If I’m posting to the “dev-consult” channel, it is clear that I’m not asking for permissions or making a decision, just asking for feedback. Every taken decision is enforced by a tool (when possible) or documented (differently according to the type of decision). It is vital to be explicit about decisions taken vs proposals or simple discussions.

Francesco S: I have to admit that the idea of a distributed CTO is very innovative and enlightening. Have you ever struggled to make a decision in this way? Were there any discussions that ended up in a stalemate?

Francesco T: Quoting Stelio Verzera, “we like to see management as a set of key activities rather than as a group of people”. Yes, we struggle to make decisions, but who doesn’t? I am fully convinced that having a single person (or a small group) making the call for the rest of the team doesn’t ease the pain; it just hides it from the rest of the group. Avoiding deciding behind closed doors exposes the whole group to its difficulty and exposes you to a better outcome than a single person could have ever reached.

As far as I recall, we never experienced a stalemate. In Soisy, we have an escalation process for such occasions, but I have never really seen it applied in the last two years. There is a far more common pitfall in my experience: not raising the question at all. In my experience, when you’re distributing the responsibility for making decisions, you need to pay attention that the right discussions start first. “Someone else will take care of that”, or, “I don’t have time/energy right now to raise that question”, or “This issue is none of my business”; these are some examples of very risky thoughts in a system like ours, and you need to protect your system against any form of inertia.

Some things help, like frequent retrospectives, or allocating time to co-create a shared vision of your project. In general, you need to ensure people are engaged; otherwise, a lot of essential discussions never actually start in the first place. That is far more risky or common than not being able to converge to a solution once an issue has been raised, at least in our group.

Francesco S: Do you think that the people involved should have some common attributes for this kind of decision-making process to work?

Francesco T: I’m not sure about people, but I think the environment must have specific attributes.
You need to feel safe expressing your opinion, whether is to agree or disagree. The context must always remind you that being wrong (or making a mistake) is not a fault but rather a realization that the reality is different from your expectations. Also, it must be perfectly fine to be involved and decide, but also to step aside and trust others.

That said, people may indeed need to unlearn some things about how a company or a team should work and may need to lower some of their expectations about how they should interact with the rest of the company/group. This kind of process can take time, and you need to be willing to take that journey. Some people might adapt faster (in fact, some are ready and blossom in such an environment) than others.

Francesco S: Let’s return to the stories you introduced before. I’m very curious about the “Haskell Story”. What problem did you try to solve with Haskell? And is your experiment concluded?

Francesco T: Let me spend a few words about the context of that particular decision.
We needed to release a new major version of that portion of the codebase anyway. At the time, we were focusing on reducing the scope of our monolith, and we had several strategies in mind, one of which was releasing some portion of it as a microservice. We were trying to be more type-safe, and also we were tasting some functional programming patterns. Also, we had a team member with Haskell’s expertise.
The context is critical to understand that we did not rewrite it to write it in Haskell; we needed to evolve that bit of our codebase. It was simple, small and self-contained enough to be a good candidate for a service, and it could be implemented as a pure function of some input data. Hence we chose to implement a microservice because it fitted our refactoring strategy, and we chose Haskell because we wanted to leverage its type system and expressivity. It could have been a different, strongly typed programming language, but given the team’s expertise, at that moment, we chose Haskell.

The service has been in production for a few months now at the time of writing. We even released some minor versions of it and a new major. A few team members worked on it (other than our main expert), so we avoided the potential bottleneck effect. After a few months, not every team member fell in love with the language, and we did not release any other service using it, but still, Haskell feels like the right tool for that particular job.

In short: yes, the experiment is concluded, and we agreed to include Haskell in our toolset. That does not mean that we will not revise that decision in future. As always, the context changes, and you must adapt.

Francesco S: Thank you, Francesco, for your time and for sharing with me Soisy’s approach to making technical decisions. Bye!

Francesco T: My pleasure ;)

Photo by Mike Enerio on Unsplash.

Learn with Francesco Strazzullo

Francesco is the author of the book Decision-making for Software Development Teams (published by Avanscoperta and available in digital on Leanpub and as a paperback on Amazon), and trainer of Decision-making for Software Development Teams Workshop and Domain-Driven Front-End Workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.