Authority Goes Bottom-Up, Accountability Goes Top-Down.

In my small journey as a tech lead, I’ve learnt that effective leadership isn’t about issuing commands from an ivory tower. Instead, it’s about redistributing authority while still holding onto accountability. This idea might sound counterintuitive at first --- after all, traditional management put both authority and accountability at the top. Traditionally, managers made all the key decisions (authority flowed top-down) and pushed responsibility for failures onto their teams. But the model I saw bring the best results is different: one where authority goes bottom-up and accountability comes top-down.

How Redis broke our application

A tale about how relying on abstractions broke an application serving thousands of customers every day without us noticing it at all before it was too late.

Semigration

Whenever we are approaching migrations in a system or a software project we usually have an ideal representation of the future aspect of our application in mind.

As soon as we start migrating the system, however, business necessities, technical challenges and changes in already-made decisions make our idealized future further away.

With this mind-provoking talk, I want to talk about a concept I call "semigration", explainable as: a chance to change some migration decisions, converting them into best practices and flows we can add to our daily job, taking opportunities whenever they arise to reduce migration complexity but achieving many of the expected results following the Pareto Principle.

I will provide an example case history of a monolith migrating to a micro-services architecture, stopping some months in the process and moving to a service-based approach, test-oriented development and CI/CD.

Migrating to Node.js by beating technical debt.

In 2022, I joined a 3-people team with 40% bugs per sprint, 100% PHP-based. Today, our 7 people team is flying at less than 5% bugs per sprint with 60% of the code written in Node.js.

How is that possible?

What Sits And What Fits.

In software development, the concepts of rules, principles, and best practices form the backbone of our work. These are the foundational elements - what sits - that guide decisions, standardize processes, and ensure scalability in complex systems. They act as anchors, providing stability and a shared understanding across teams and projects.

Yet, no rule or practice exists in a vacuum. There are moments when the established path is not the best path. Context shifts, priorities change, and sometimes the solution lies in stepping outside the boundaries. These are the moments when fits - context-specific adaptations - become necessary to resolve unique challenges. The tension between sits and fits is the core of pragmatic software architecture.