João Alves

@joaoqalves.net

71 Followers 27 Following

2x Dad. Husband. Head of Engineering @Adevinta. Building abistama.com and rotahog.com Opinions are my own. Writes in PT/ES/EN/CAT

Whiteboard sketch outlining three promotion mistakes: "potential" trap, competition favors proven experience, and visibility gap limiting cross-team trust.
A graph showing how risk changes: too few services? monolith, and potentially problems when deploying. A lot of services? A headache too
Four years later, I'm still seeing the same patterns, just dressed in different frameworks, clouds, and YAML dialects. The tools evolved, but the fundamentals didn't: distributed systems remain distributed, humans remain human, and complexity remains undefeated. What's coming next will make this even more interesting. We're now trying to build AI agents: autonomous, stateful systems that communicate with each other, make probabilistic decisions, and respond to unpredictable inputs. In other words: distributed systems with opinions. What could go wrong? The same fallacies apply, just at a different layer. Latency, consistency, observability, determinism. None of them magically disappears because the component now "thinks."
Multi-cloud made it to the final spreadsheet, but only so everyone could see how crazy expensive it would be. In the past, AWS and other hyperscalers had single points of failure. As @GergelyOrosz mentions in the latest Pragmatic Engineer newsletter, there are still some components that are “global” and run on a single region (us-east-1). That’s not the norm, and the vast majority of services can be run in multiple areas. It’s up to the business to understand (a) what its critical paths are and (b) what its risk appetite is versus the cost of running multi-region or even multi-cloud/hybrid setups for specific scenarios. For some businesses, 24/7 uptime is more critical than for others. Take Glovo or Uber, for example: there’s a high per-minute cost during peak hours. Why? The cost of switching is low. Users also have Lyft, FREE NOW, Just Eat, and Uber Eats on their phones, so they can easily open another app to get from A to B or order a meal. If one of Adevinta’s portals (secondhand, real estate, or motors) is down at 2 a.m. on a Friday, that’s mostly OK. Yes, there are peak times, but there’s also a counterbalance thanks to (a) network effects — a lot of the inventory on @leboncoin isn’t listed anywhere else; everyone in France uses it — and (b) low time sensitivity. If you’re looking for a flat or a car, it can wait a bit. Multi-cloud (and sometimes even multi-region) sounds smart until you price it, model the risks, and realize: it’s usually not worth it. Reliability is an architecture problem, not a cloud problem.
Visualization from Jason Roberts with x-axis on "Doing" and y-axis on "talking". The best is the intersection between them
An image with a Slack message explaining to a team why engineer A and B were promoted. Spoiler: two different set of reasons.
2. Engage early on with your peers to get their support. Do you know the old adagio that there's a pre-meeting where the real afterward meeting gets settled? It's similar 3. Prepare for the calibration committees. 4. Make the reasons for promotion public. I strongly advocate for acknowledging and explaining why individuals are promoted. Culture isn't just about what's displayed on the walls. It's about what is encouraged, appreciated, and rewarded within the workplace. It's essential to recognize that there are multiple paths to promotion, encouraging diverse approaches to work and behaviors. That approach creates a positive cycle where employees understand that the management team values different skills and are less likely to imitate others to achieve success, such as prioritizing releasing high-profile features.
An engineer standing in an auditorium for his promotion. People clap him.