Distributed decision-making in tech

Matt: Hey, Cris. Do you know why we use self-hosted MariaDB, even though there are better alternatives out there?
Leila: Ah, it's been like this since I joined. Don't really see the point too.
Matt: What about this weird fingerprinting library? How it's managed to get into the app, since nobody knows what it is for?
Leila: I always thought it was built into the platform. My advice, don't touch if it works.

As more technology companies shift towards remote, it's common to forget to rethink habits and rituals that were established in the office. Occasional water cooler conversations and whiteboard talks that used to serve raising awareness and general knowledge sharing are now rarely possible and not that fun anymore online.

In a context when remote teams have to deliver value quickly, they often forget to sit back and reflect on how a system is evolving over time.

One knock-on effect is that developers with no perspective over how architectural changes come about find themselves caring less about similar decisions of their own:

"I'll just share this database with another service. If they both need cardholder data why not?".

The context, precursors, alternatives, goals, risks - all very important decision artefacts - get lost.

At Intergiro, we were no exception. As a remote-first company, we started to feel this problem very quickly.

Many crazy ideas came to mind. Let's do weekly architecture news hangouts? Or maybe CTO should be checking in with each team separately to stay on top of things?

The problem with regular calls and check-ins is they easily get off the rails and turn into heated debate with people making half-hearted suggestions, often lacking enough context about the matter. Also synchronous online communication is more demanding and can easily eat up your entire calendar. Not good.

We needed something scalable regardless of where the team is located and how many people are involved...

And then we looked at how massive open-source projects get their work done. Millions of people across the world, who don't even happen to know each other, get together to build complex software like databases, messaging protocols, frameworks and languages.

We analysed dozens of open-source projects and discovered a common theme among the most successful ones. They were all relying on some sort of the RFC (Request for Comments) design process, whether implemented via mailing lists, wiki pages or PDF documents.

That was the key for us. Now, sitting at the heart of our architecture design process, it allows developers to be on top of what's going on in the company without having to sit through lengthy conversations and pointless debates.

We can now guarantee there's always a trail record describing the context, goals and impact for every technical decision we make. This serves as a fair and transparent platform for developers to get feedback on design while at the same time providing a useful historical timeline.

Does that situation sound familiar to you? Feel free to adopt our approach at your company and let us know how it goes!

The transition to remote work is not easy and you might need somebody else to help out. You can also check out Oskar Wickström's essay on his experience in working remotely and 8 things remote CEOs do differently by Claire Lew for more insights.