About

I am a software engineering leader and software architect with 22+ years of experience, having lead 9+ teams throughout my career. My purpose in the area is to build or transform engineering teams into very efficient ones that produce extremely high quality products, where the deliveries frequently happen sooner than expected. I do this via technical or managerial leadership. Sounds too good to be true, right?

My secret, though, is not a secret at all: while the vast majority of the industry establishes a dichotomy between quality and speed, to me they're actually best friends! The real trade-off is not between quality or speed, but rather between "quality AND speed" (as a couple) and products grinding to a halt.

While rushing deliveries to production by compromising quality does give significant acceleration at the start of a project or product, it makes it way harder to fix the consequences of this choice in the future. And it becomes harder and harder as time goes by without fixing these issues, to the point that projects might literally grind to a halt. In other words, low quality might even help achieving critical milestones faster at the start of a project, but ultimately they're the enemies of maintainability, and thus sustainability as well.

By applying well-known high quality engineering and management techniques, and embed quality right from the start of putting the product in the hands of customers, I overcome all of these problems and build a solid forward-moving foundation.

How I do it

Stages

To build successful products I separate their evolution in 2 phases: Proof-of-Concept and Production-Ready. PoC is where the team can basically ignore any quality standards and rush everything, because this is just a learning phase when the organization needs to understand whether ideas are feasible and even make sense at all. Then comes Production-Ready, where the team puts aside the PoC to use it only as a conceptual reference, and restart the project from scratch, but now building a real product with high quality, great design etc. It's absolutely critical that teams don't reuse the PoC's code as the system to deploy to production as the final product, and this is a frequent mistake made by organizations which costs a lot down the line making products unsustainable.

If I start on a team that's in either of these two stages, I try to follow along. If I start on a team that's running a PoC-level system in production, I strive to turn it into a manageable system via multiple migration, refactoring and redesign techniques, perhaps replacing some (or all) of the components as needed and viable.

Management

On the managerial side, I point the growth of the engineering team towards stream-aligned teams, where each smaller team is responsible for a subset of the business domains, so that they can be autonomous and can deliver business value as independently as possible, thus avoiding handover and increasing deployment frequency and decreasing lead time. I make sure the team recognizes the value of their work, and that they don't overwork, so that they can keep their morale up.

Software engineers are a brilliant folk; Most of the time they're willing to do above their best to achieve greatness. It's up to managers to remove as many blockers as possible and provide a seamless developer experience, so to let engineers thrive, deliver greater value and feeling proud of what they do, which leads them into delivering even more value later on. Building an incredible work culture, one that leads to collaborators talking about how great the stuff they're working on is, is something absolutely worth doing!

I don't have a count of how many engineers I've interviewed in my career anymore, but it's well over a hundred at this point. My favorite way of interviewing candidates is by asking them more open-ended questions, allowing them to speak more so that I can "catch" more details about how they work and what their experience is. So there's a significant amount of real-time adaptation during the interviews I conduce - this is not just a coincidence with my agile way of developing software!

Engineering

On the engineering side, I use and influence others to use eXtreme Programming (XP) techniques, particularly Test-Driven Development, Pair-Programming, Continuous Refactoring and Baby Steps. Also, I'm a strong adopter of the DevOps culture - where developers are responsible not only for building the software, but also shipping it and overseeing it in production. This requires techniques like Continuous Integration and Continuous Delivery, to be done efficiently and with extremely high quality, by ensuring very fast feedback over the software produced and converted into business value.

The only moment when I leave these practices and techniques aside is when doing proofs-of-concept, or experiments, for the sake of learning certain specific things - for example, learning a new framework, a new programming language, a new database system etc. But then I start learning how to test these things, and I switch back to TDD as soon as it's time to build production-ready code.

Architecture

On the architectural side, I'm in favor of initial teams starting with modular monoliths (with vertical slices) and, as they grow and/or need to independently deliver changes to different domains under different architectural characteristics, they adopt styles like event-driven architecture, microservices or others, depending on the necessity. Ports and Adapters and Domain-Driven Design can also be very helpful in structuring applications or services, and I use them where necessary, but always trying to avoid unnecessary complexity.

I don't think architectural styles need to be "pure" or "complete"; Teams can partially implement them as needed, if that makes sense for them. For example, monolithic web applications can pair very well with small sets of microservices, whereas microservices also pair very well with event-driven architecture.

Skills

There's a whole page where I talk about my skills in details, but, in general, I'm experienced with leadership, software engineering, software architecture and infrastructure engineering. Within leadership, I'm more experienced in technical leadership. Within software engineering, I'm more experienced in backend engineering, particularly with Python and PostgreSQL. Within software architecture, I'm more experienced in monolithic designs, but also fairly experienced in service-based, event-driven and microservices architectures. Within infrastructure engineering, I'm more experienced with Kubernetes and containers (containerd, Docker etc.), but also a decent amount of Linux (by the way I use Arch :-P ).