I want to specially thanks to Jose Emilio Labra, who gave me this amazing opportunity to share my experiences with the students.

Now, let’s jump into it.

When I started my career, I believed that professional growth was a simple matter of time. I thought that after about five years of cranking out code, someone in the company would magically come to pat me on the back and say:

Marcos, we’re going to promote you; it’s your time to lead.

Fortunately, I realized that the real world doesn’t work like that at all.

In today’s issue, I want to share my most sincere experience on how you actually grow and build a career in a tech product company. We will cover:

• The myth of automatic promotion and the two main career paths.

• The radical importance of openness to change.

• Why you must act like the role you want before you get it.

• The vital need to make your work visible to management.

If you’re aiming for a promotion and want to understand how things really work behind the scenes, this edition is for you.

The Myth of Automatic Promotion and the Two Paths

As I was saying, growth in the tech industry has nothing to do with the time you spend warming a chair. In the past, it seemed like the only natural destination for an experienced developer was to become a manager, whether you liked leading people or not.

Luckily, that has changed. Today, you have two main paths to scale:

• The Technical Track (Individual Contributor): This is your path if your passion is to stay close to the code and architecture. You evolve into high-impact roles like Tech Lead, Staff Engineer, or higher, where your focus is on solving strategic architectural challenges without involving yourself in the hierarchical management of people.

• The Management Track (Engineering Manager): Your responsibility shifts. Your core focus is no longer coding, but genuinely caring about the career development of your engineers, aligning product goals, and ensuring your team has what it needs to perform at its best. It’s a different mindset.

Attitude is Everything: Openness to Change

If you just graduated or even if you are already a Senior, there is something fundamental you must internalize: openness to change.

In job interviews, it is assumed that you have a solid programming foundation. What truly sets you apart is your reaction when asked:

I know you master Java, but if the project requires it, would you be willing to code in Rust?

People who show open-mindedness:

yes, I will learn whatever is necessary.

These are precisely those who end up making huge leaps in their careers.

Act Like the Role You Aspire To

I’m going to be direct:

👉🏼 No one is going to come out of nowhere to say:

we’re promoting you,

So then you start acquiring responsibilities.

Especially from Senior roles onwards, you must act like the role you want to obtain before it is officially granted to you.

☝🏼 You must proactively demonstrate that you are capable of making design decisions, arguing at a technical level, and leading de facto. It is the only way to make it clear that the position already belongs to you morally.

Make Your Work Visible

This is, by far, the point where we technical profiles fail the most. I know, for those reading this newsletter, this already sounds familiar to you.

Still.

In an early-stage startup, it’s easy for your manager to see the quality of your work directly. But when the organization scales, your Engineering Manager will be swamped with obligations; they will no longer have eyes to see the daily grind of the whole team.

👉🏼 You have to make it noticeable. It depends exclusively on you.

Strategically leverage your 1-on-1s or your evaluations. Don’t improvise; bring data. Show charts: Look at how the number of bugs in production has dropped since I implemented my initiative,” or “I’ve managed to reduce our infrastructure cost by 12%.” If you don’t value your own effort, no one else is going to come to tell management how great you’ve done.

✨ Takeaways

Let’s wrap up. Load these concepts into your backpack:

• Growth is measured by impact, not years: Seniority does not guarantee promotions.

• Choose your path: Decide if you provide more value solving technical challenges (Individual Contributor track) or empowering other people (Engineering Manager track).

• Embrace flexibility: Your adaptability to new ecosystems is your main competitive advantage.

• Act in the role before you have the title: Lead at the level of the position you want to prove you are ready.

• Visibility is vital: Document, quantify your successes, and proactively present them to your manager in your 1-on-1s.

I hope this edition has given you the focus you need to boost your next professional step with energy. Do you have something to share about it? drop me a message!

Long time since I brought you fresh ideas from other experts from real life, and I come once again with a special guest . I let Julia introduce herself.

Julia is a Senior Localization Engineer at McAfee and the founder of Black Ice (black-ice.ai), a semantic governance platform built for multilingual AI pipelines. With a background in Siri localization at Apple and certification as a sworn translator, she brings a rare mix of linguistic depth and engineering to the question of how meaning travels across languages at scale. She writes The AI-Ready Localizer on Substack for localization professionals, engineers, and product teams navigating the shift to AI-assisted workflows.

Julia gave me an account to give a try at her Black-Ice.ai product, and I can tell it’s really cool, really good user experience, and it’s already cracking!

I want to recommend Julia’s newsletter to all those Engineers, Product Managers, and UI Platform leads who are working on localization challenges.

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

I must confess that I’m really excited about what Julia brings to you. I already read it in advance and found it super useful, to the point that I want to apply it in my Engineering Organization.

If you’re building a SaaS product, you likely have multi-language support. This post is for you, so you don't f*ck up and show 'Hola' to Japanese readers.

Without taking any more time, I hand over to Julia.

Somewhere in your codebase right now, there is a hardcoded string.

Maybe it’s an error message added at 6pm on a Thursday. Maybe it’s a toast notification someone copy-pasted and forgot to wrap. Maybe it’s a button label that’s been there since the MVP and nobody has touched it because it works.

It will ship to your French users as English. And nobody will catch it, because your CI pipeline has no idea it exists.

This is the problem. Let’s talk about how to fix it structurally, not by asking developers to be more careful, but by making the pipeline do the work.

What i18n scanning actually is

i18n scanning is static analysis for your translatable content. The same way a linter catches an undeclared variable or a type checker catches a mismatched return type, an i18n scanner catches:

• Strings rendered directly to the UI without going through a translation function

• Translation keys referenced in code that don’t exist in any locale file

• Translation keys present in locale files that are never referenced in code (dead strings)

• Locale files missing keys that exist in the source language (incomplete translations)

• Strings built by concatenation that are structurally untranslatable

• Plural forms handled incorrectly — or not handled at all

None of these require running the application. They are all detectable from static analysis of your source files and your translation resources. Which means they all belong in CI.

The four failure categories you will actually encounter

Before talking about tools, it helps to be precise about what you’re scanning for. These are the categories that cause real production issues.

1. The hardcoded string

// This will never be translated.
// Your German users will see "No results found" regardless of their locale.
function EmptyState() {
  return <p>No results found</p>
}

// This will be translated, because it goes through the i18n function.
function EmptyState() {
  return <p>{t('search.empty_state')}</p>
}

This is the most common failure and the easiest to catch. A scanner walks your JSX/TSX, finds string literals being rendered directly as text content or passed as props like label= or placeholder=, and flags them.

The tricky cases are strings that aren’t visually obvious: error messages thrown in catch blocks, strings constructed in utility functions far from any component, aria-label attributes, document titles set imperatively with document.title.

2. The untranslatable concatenation

// Looks fine. Completely untranslatable.
const label = "Hello, " + user.name + ". You have " + count + " messages.";

// The problem: word order is not universal.
// Japanese puts the subject last. Arabic has six plural forms.
// Hungarian uses postpositions, not prepositions.
// You cannot translate the fragments independently.

// Correct approach: ICU MessageFormat
const label = t('greeting', { name: user.name, count: count });
// en.json: "greeting": "Hello, {name}. You have {count, plural, one {# message} other {# messages}}."
// ja.json: "greeting": "{name}さん、{count}件のメッセージがあります。"

This is harder to catch automatically because you need to identify strings being concatenated and then rendered, not just any string operation. But AST-based tools can detect the pattern. The signal you’re looking for is: a template literal or string concatenation appearing inside JSX render output or passed to a translation function as a dynamic argument.

3. Key drift

// Code references this key:
t('user.profile.save_button')

// But your en.json has:
{
  "user": {
    "profile": {
      "saveButton": "Save changes"   // camelCase, not snake_case
    }
  }
}

// Result: silent fallback to the key string itself.
// Your button now reads "user.profile.save_button" in production.
// This has happened to everyone. Usually noticed by a user, not a developer.

Key drift happens when code and locale files evolve independently. A rename in one place without the other. A key added during development but never put into the JSON. This should be a hard CI failure — a missing key is a broken string in production.

4. Incomplete locale files

// en.json — your source of truth
{
  "onboarding.step1.title": "Let's get started",
  "onboarding.step1.body": "Tell us about yourself",
  "onboarding.step2.title": "Set up your workspace"   // ← new key, added last sprint
}

// fr.json — what went to translators two sprints ago
{
  "onboarding.step1.title": "Commençons",
  "onboarding.step1.body": "Parlez-nous de vous"
  // onboarding.step2.title is missing
  // Your French users see English here. Or nothing, depending on your fallback config.
}

This is the most common failure in fast-moving products. New strings ship to production in the source language while translations are in progress. Whether this is acceptable depends on your release strategy, but it should always be visible — a metric, a check, a warning. Not a silent gap.

The tools

There are two broad categories: linters that analyse your source code, and validators that analyse your translation resource files. You need both.

For source code analysis (catching hardcoded strings and bad patterns)

• eslint-plugin-i18n-json and eslint-plugin-i18next are the most widely used for i18next-based projects. They flag untranslated string literals in JSX, missing translation function wrappers, and some concatenation patterns.

• @formatjs/eslint-plugin-formatjs does the same for react-intl/formatjs, with additional checks specific to ICU MessageFormat syntax.

• Custom ESLint rules via AST are often necessary for project-specific patterns — for example, strings passed to third-party component props that your off-the-shelf plugin doesn’t know about.

The thing to accept early: no scanner catches everything. They catch the patterns they were written to recognise. Your job is to configure them to match your actual codebase patterns, not to expect full coverage out of the box.

For translation resource validation (catching key drift and incomplete locales)

• i18next-scanner extracts keys referenced in your source and compares them against your locale files. It can output a report of missing keys, unused keys, and coverage per locale.

• @formatjs/cli does key extraction and can enforce that all extracted keys are present in your message files.

• A simple custom script — walk the locale files, compare key sets, output diff — is often worth writing for your specific structure, because your project’s locale file layout is probably not exactly what any off-the-shelf tool expects.

What the pipeline actually looks like

Here is a practical CI pipeline structure. Not every team needs all of this on day one, but this is the shape of a mature setup.

PR opened / push to branch
         │
         ▼
┌─────────────────────────────┐
│  Stage 1: Lint (fast, < 30s) │
│                             │
│  eslint i18n rules          │
│  → fail on hardcoded strings│
│  → fail on bad concat       │
│  → fail on invalid ICU      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 2: Key validation    │
│                             │
│  Extract keys from source   │
│  Compare against en.json    │
│  → fail on missing keys     │
│  → warn on unused keys      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 3: Coverage report   │
│                             │
│  Compare en.json vs         │
│  all other locale files     │
│  → fail if coverage < N%    │
│  → post coverage table      │
│    as PR comment            │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 4: Sync to TMS       │
│  (on merge to main only)    │
│                             │
│  Push new/changed source    │
│  strings to translation     │
│  management system via API  │
└─────────────────────────────┘

A few things worth highlighting in this structure:

Stage 1 and Stage 2 should be hard failures. A hardcoded string is a broken feature for non-English users. A missing key renders as the key name in production. These are bugs, not warnings.

Stage 3 should be configurable by locale. You might tolerate 80% coverage for a language you recently launched and 100% for your primary markets. The important thing is that the gap is visible and tracked, not silent.

Stage 4 is where the pipeline connects to your translation workflow. Most mature TMS platforms have APIs and CI integrations. The pattern is: on merge to main, push new source strings to the TMS; the TMS notifies translators; translated strings are pulled back on a schedule or via webhook before the next release. The pipeline doesn’t block on this — it triggers it.

The pre-commit layer (before CI even runs)

CI catches things before they merge. Pre-commit hooks catch things before they’re even pushed, which is faster feedback and less noise in PR reviews.

Using lint-staged with your i18n ESLint rules, you can run string checks only on files changed in the current commit — keeping it fast enough that developers don’t disable it.

// .lintstagedrc
{
  "*.{js,jsx,ts,tsx}": [
    "eslint --rule 'i18next/no-literal-string: error' --no-eslintrc"
  ]
}

The rule of thumb: everything that can be caught locally should be caught locally. CI is the safety net, not the primary feedback loop.

The one failure nobody talks about: the source string itself

All of the above assumes your English source strings are well-formed and translatable. Often, they aren’t.

// This string will reach your translators exactly like this.
t('save_confirmation', { defaultValue: "Changes saved! 🎉" })

// Problems:
// 1. The emoji may render incorrectly or be culturally inappropriate in some locales.
// 2. "Changes saved" is ambiguous — saved where? As in rescued, or persisted?
// 3. No context about where this appears, what triggered it, or what "changes" means.

A scanner cannot catch these problems. But a string linting step on the source values themselves can catch some of them:

• Emoji in UI strings (flag for review)

• Strings over a length threshold that will break UI in text-expansion languages (German expands ~30%, Finnish can expand ~60%)

• Strings with no translation context/comment attached

• Strings that appear to be sentences but end without punctuation (or vice versa — inconsistent punctuation is a translation signal that something is wrong)

This is the layer most teams never build. It’s also the layer that most directly improves translation quality — because it improves the source before anyone translates it.

Where things break down even with a good pipeline

Having the tooling is not the same as the tooling working. A few failure modes that survive even well-structured pipelines:

The coverage threshold that never moves

Teams set a coverage gate at 80%, ship, and never revisit it. The threshold stops being a quality signal and starts being a number the pipeline checks so everyone can feel fine. Review your thresholds per locale, per quarter.

The scanner that never covers your whole codebase

ESLint i18n rules are easy to configure for your main app code. They are less often configured for your component library, your internal tooling, your admin panel, your email templates. Each of these is a separate surface with its own untranslated strings. Map your surfaces before you assume you’re covered.

The TMS sync that runs but nobody checks

Strings push to the TMS, but the translation workflow on the other side is not set up to handle them promptly. New strings sit untranslated for weeks. By the time translations come back, the feature has been live in English-only for two release cycles.

The pipeline does not fix a broken translation workflow. It just makes the handoff cleaner. The workflow itself needs ownership.

Key naming that carries no meaning

// This is the key you'll be debugging in eighteen months:
t('label_47')

// This is the key that communicates intent to translators and future engineers:
t('checkout.order_summary.total_price_label')

No scanner enforces key naming conventions, but your CI can. A custom ESLint rule that validates key format against a regex is ten lines of code and saves significant cognitive overhead over time.

Final thoughts: language is a build artifact

Here is the mental model shift that makes all of this click.

Your translation files are build artifacts. Like your compiled code, your test coverage report, your bundle size analysis — they have a correct state, and that state can be verified automatically.

A missing translation key is a build error. An untranslated string rendered to a French user is a broken feature. A locale file that hasn’t been synced to the TMS is stale code.

Once you treat it this way, the pipeline work becomes obvious. You already have automated checks for code correctness, test coverage, and bundle size. i18n coverage belongs in the same category, enforced the same way.

The teams that get this right are not the teams that care more about localization. They are the teams that stopped treating localization as someone else’s problem and put it in the pipeline where it belongs.

Before you go, a small meta-note. The i18n pipeline I described above is one I’m actively building with AI. I use Claude and a multi-agent setup to handle different stages of the workflow: scanning for hardcoded strings, extracting keys, flagging concatenation patterns. Then a semantic layer via Black Ice checks terminology consistency, style, and market availability — so a term that works in en-US gets validated before it assumes it works in de-DE or ja-JP. Writing about i18n infrastructure while building it with the same tools is, I’ll admit, a very specific kind of fun.

🫂 Thanks Julia!

Marcos back!

I want to send a deep Thank You to for sharing her experience on the Product Platform area and localization. To learn more from Julia, subscribe NOW to her newsletter 👇

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

🔖 Follow-up readings

The AI-Ready Localizer

Building Globally: A Practical i18n Guide

Internationalization (i18n) isn’t just a language feature. It’s a design constraint, a code architecture choice, and a product strategy…

Read more

10 months ago · 22 likes · 1 comment · Julia | Taking you global

When you create the software, sometimes it’s difficult to find your blind spots. But time puts things in perspective, and so you can learn from your mistakes.

In today’s email, I want to share with you the 4 signals that your software is badly designed.

Rigidity

👉🏼 Rigidity is the tendency of software to be difficult to change, even in simple ways.

A system is rigid when a change in one module triggers a cascade of changes in other dependent modules.

The symptom: If you request a change estimated to take two days and it ends up taking two weeks because “one thing led to another,” you have a rigid system.

The cause: It’s usually excessive coupling. Everything is so tightly coupled that you can’t move one piece without it affecting the entire board.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have an OrderProcessor class with a massive switch statement for calculating shipping costs. If it’s “UPS,” it does one thing; if it’s “FedEx,” it does another. When you want to add “DHL,” you have to modify that class, forcing you to recompile and retest the entire order module.

The Solution: Strategy Pattern (or the Open/Closed Principle). Instead of an internal switch statement, you create a ShippingStrategy interface. Each carrier (UPS, FedEx, DHL) implements this interface. The OrderProcessor now only receives one strategy and calls calculate().

Result: To add a new carrier, you simply create a new class. You don’t touch the existing code.

Fragility

👉🏼 Fragility is the tendency of software to break in many places every time a change is made.

Unlike rigidity, the problem here isn’t the effort of the change itself, but the lack of control over the side effects.

The symptom: You fix a bug in the payments module, and mysteriously, the inventory report generator stops working.

The cause: This usually occurs when there are hidden dependencies or highly intertwined logic where modules know too much about each other’s inner workings.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have a global variable or a Singleton that stores the “System Configuration.” A developer changes the date format in that configuration for a specific report, and suddenly, the “Payroll” module stops processing payments because it expected the old format. The system broke in a place unrelated to the original change.

The Solution: Encapsulation and Interface Segregation.

Don’t allow everyone to access a global object. Divide the configuration into smaller interfaces (e.g., PayrollConfig, ReportConfig). Each module only sees what it needs.

Result: A change in the reports only affects the reporting interface, keeping payroll safe.

Immobility

👉🏼 Immobility is the inability to reuse software in other projects or even in other parts of the same project.

It occurs when the design is so entangled with its environment that extracting a feature is more costly than rewriting it.

The symptom: You need a validation function that you already implemented in another module, but when you try to copy it, you realize that it also includes the database, the user interface, and three external libraries.

The cause: A design that doesn’t separate business rules from implementation details (such as the database or the framework).

🧐 Yeah, let’s see an example, and how you would solve it.

The Scenario: You created a brilliant algorithm to validate ID numbers (national ID/tax ID). However, the algorithm is written within a UserRegistrationForm class that inherits from a UI library (like React or the Android SDK) and also directly calls the database to check for duplicates.

The Solution: Layered Architecture (Clean Architecture).

Extract the algorithm into a Pure Object Component (POJO) or Use Case. This code should not know anything about buttons or databases. The database is passed to it as an interface (Dependency Inversion).

Result: Now you can copy that validation file and paste it into any other project without carrying over the “garbage” from the interface or the database.

Viscosity

👉🏼 Viscosity refers to the resistance the system offers to doing things “right.”

It is divided into two types:

• Software viscosity: When it is much easier to add a “hack” or a dirty patch that follows the original design and keeps the architecture clean.

• Environment Viscosity: This occurs when the development environment is slow or inefficient (endless compilation times, tests that take hours). This tempts developers to resort to shortcuts to avoid the formal process.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You need to add a field to a form. The “clean” design requires creating a database migration, updating the entity, updating the DTO, and updating the mapper. That takes 1 hour. But you can simply save that extra “hidden” data in a generic text field called “observations” in 5 minutes. If the system takes a long time to compile or testing is slow, you’ll choose the dirty way.

The Solution: Automation and Infrastructure Refactoring.

If the problem is with the environment (slow compilation), you need better machines or to modularize the project. If it’s with the software, you need tools like Lombok or automatic mappers (AutoMapper/MapStruct) that reduce repetitive code (boilerplate).

Result: Doing it right should be almost as fast as doing it wrong. If the right way is easy to follow, developers will follow it.

Alright! Let’s wrap up for today. These four signals (Rigidity, Fragility, Immobility, and Viscosity) are not just theoretical concepts; they are the “smells” that indicate your system is asking for help.

✨ Takeaways

Today’s email has been really software engineering-oriented. Long time since I dedicated one email to this, hope you like it from time to time.

• Design for change: A rigid system is a slow system. Use patterns like Strategy to decouple logic from execution.

• Protect your boundaries: Avoid global states and hidden dependencies to keep fragility under control.

• Decouple from the framework: Your business logic should be able to live anywhere. If it’s stuck in a UI component, it’s immobile.

• Make the “right way” the “easy way”: If doing it right takes too much effort, the system will eventually fill with hacks. Invest in your environment.

☝🏼 Remember: Bad design is not a life sentence. Identifying these signals is the first step toward refactoring and moving toward a more Incremental Architecture.

I’d love to hear from you. Have you identified any of these signals in your current project? Which one do you find the most difficult to fix?

Drop a message in the comments or reply to this email. I read and reply to all!

Best,
Marcos.

👉🏼 It is shipping it with confidence.

Because releasing software should not feel like a coin toss, especially not on a Friday at 6 p.m., when everybody is already mentally halfway into the weekend, and the margin for dealing with surprises is much smaller than we would like to admit.

If every release feels risky, the problem is usually not the release itself. The problem is the system behind it.

In today’s issue, I want to share a different way of looking at that feeling of uncertainty that appears right before going to production, and why, in most cases, it is not something you fix at release time, but something you design away much earlier in the process.

Let’s begin with the elephant in the room.

The invisible weight behind every release

👉🏼 Releases do not become stressful in isolation.

They accumulate friction over time, through a combination of small issues that individually seem manageable, but collectively create a system that is harder to reason about and, therefore, harder to trust.

Some of those signals usually look like this:

• Ownership is not completely clear, so when something goes wrong, there is a small but real hesitation about who should act first.

• Parts of the system are only fully understood by one or two people, which silently increases the perceived risk of touching them.

• Logs exist, but they do not really explain what is happening, forcing you to reconstruct the story under pressure.

• Alerts either come too late or too often, which makes them easy to ignore when they actually matter.

• Environments behave slightly differently, in ways that are not always obvious until something breaks.

None of these things breaks a release on their own.

But together, they create a system where every change feels heavier than it should, and that weight tends to show up exactly when you least want it to: right before going to production.

Confidence is not a feeling, it is a property

👉🏼 Many teams treat confidence as something emotional, something that needs to be discussed or agreed upon before releasing.

Do we feel safe releasing this?

But confidence is not something you convince yourself of in a meeting.

It is something your system gives you, almost by default, when the right properties are in place.

A system that behaves well tends to share a few characteristics:

• It is easy to understand, which means that most engineers can reason about what a change will do before it happens.

• Responsibilities are clear, so when something goes wrong, there is no ambiguity about who owns the next step.

• It explains itself through logs and signals that help you understand what is happening without guesswork.

• It behaves consistently across environments, reducing the number of surprises when moving to production.

When those pieces are in place, confidence stops being a discussion and becomes an outcome.

Where most teams get it wrong

👉🏼 The common mistake is trying to “fix the release” instead of fixing the system that produces that release.

That usually leads to adding more layers around the moment of deployment:

• More checks.

• More approvals.

• More manual verification.

• More last-minute coordination.

All of these can help in the short term, and sometimes they are necessary.

But they rarely address the root of the problem.

Because the release is just the moment where all the properties of your system are tested at once, under real conditions and real pressure.

• If the system is hard to understand, the release will feel risky.

• If the system is inconsistent, the release will feel unpredictable.

• If the system is fragile, the release will feel stressful.

Trying to fix the release without fixing the system is like trying to move faster on a road full of potholes; you might get away with it a few times, but the underlying problem is still there.

A simpler way to think about it

Instead of asking:

Is this release safe?

It is often more useful to ask:

Does our system make safe releases the default?

That shift may seem subtle, but it changes where you put your effort.

It moves your attention:

• From the moment of deployment 👉🏼 to the way the system is built.

• From last-minute checks 👉🏼 to everyday engineering practices.

• From reacting to problems 👉🏼 to designing systems that are easier to trust.

And that is where most of the leverage actually is.

Now, some homework for you.

A small exercise

Think about your last release, not just in terms of code, but in terms of experience.

Try to recall the moments where you slowed down, hesitated, or double-checked something “just in case”, even if everything looked correct on the surface.

Ask yourself:

• Where did I hesitate, even slightly?

• What did I feel the need to double-check before moving forward?

• Which part of the system made me feel uncertain or uncomfortable?

Those moments are not random but signals.

They are pointing to parts of your system that are asking for more clarity, more consistency, or better feedback.

👉🏼 If you start paying attention to those signals, release after release, you are not just making the next deployment safer. You are gradually building a system that is easier to understand, easier to operate, and ultimately easier to trust.

Shipping software will never be completely risk-free, but it should not feel like guesswork either.

And when it does, it is usually telling you exactly where to look.

Having this relationship forged through the years following you, if the price were acceptable, I would pay for it.

— Senior Software Engineer

I’m still open for feedback. Please, pass by 👇🏻

Now, let’s get back to today’s issue.

Everything started with a message from when we were finishing our Master's degree:

Marcos, what if we apply to this open possition at CERN together?

And I said

Yeah, don’t know… my english is really poor, you know?… don’t know if it’s worth it anyway… mmm… okeysh, let’s do it (what can I loose).

That was my Flashpoint, when everything started.

But let’s put a bit of context here.

“Stepping out of your comfort zone” is a phrase that has been worn out by overuse. It often sounds as if you aren’t constantly jumping into the void, you aren’t progressing.

But that’s not true in my experience, and I don’t believe in universal rules either.

Context matters, and a lot. What is a bold move for one person might be an irresponsible decision for another, depending on their current life stage.

However, there are moments when staying where you are is simply limiting your own growth. That’s where uncertainty comes in.

I know that could sound tough, but I always tell you I bring you real-life experiences, and real life is like that.

The context: From stability to chaos

About 13 years ago, my plan was linear: finish my degree in Oviedo, keep working there, and have a predictable life. It was a comfortable bubble.

But in 2013, the crisis hit hard in Spain. The company I was working with decided to let me go, and suddenly, that “stability” vanished. My first reaction was to look for the closest thing to what I already had: another job in Asturias, close to home, without overcomplicating my life.

That’s when Ángel, a good friend, sent me a link: a job opening at CERN.

“What am I even doing here?”

My tech stack at the time was PHP and MySQL. When I read “CERN,” my imposter syndrome kicked in immediately: “What am I going to do there? I build websites, not particle physics.”

Does it ring a bell to you?

But I asked myself a question that changed my perspective:

Why not?

Sometimes, that’s the only technical validation you need to apply for a role.

I passed the interviews and, three months later, I was landing in Geneva with two suitcases and a paper map in my hand. I was out of my comfort zone, and the feeling wasn’t one of “empowerment”; it was pure fear.

Reality at CERN: No instruction manual

I joined as a DevOps Software Engineer to work on the OpenStack infrastructure (the data center’s private cloud). But the real shock wasn’t technological; it was methodological.

In high-level environments, nobody sits next to you to tell you what to do step-by-step.

• The mission: “Improve the UI of this system.”

• The roadmap: It didn’t exist. You had to build it yourself.

That level of autonomy forces you to operate in a space where you can’t rely on routine. You either learn to navigate ambiguity, or you sink.

I’m not ashamed to admit that I didn’t know how to do that. Damn, I was thinking

Shit!, I want to come back home tomorrow!

But something changed inside of me. I managed to evolve. I managed to really understand why I was there, and the out-of-control situation helped my brain to figure it out.

What you gain when you let go of control

If you decide to take the leap (when your context allows it), two fundamental things happen for an engineer:

1. Your learning capacity multiplies out of necessity. You don’t learn because you want to add a checkmark to your CV; you learn because you have no other choice to get the job done and, of course, because that’s your goal!. You learn how to “learn fast,” which is the ultimate skill.

2. You ask for forgiveness instead of permission. When there’s no set path, waiting for 100% of the information is death by analysis paralysis. You start making decisions, failing fast, and correcting on the fly.

☝🏼 A necessary clarification

I don’t want to romanticize this. You don’t have to move abroad or work at CERN to “grow.”

These decisions only make sense if the timing is right. In my case, being laid off and having few strings attached created the perfect scenario. If I had different responsibilities or a different family situation, the risk might not have outweighed the benefit.

Stepping out of your comfort zone doesn’t have to be a radical change. It can be:

• Leading a technical initiative for the first time.

• Switching to a team where you don’t master the stack.

• Giving a talk in front of people who know more than you do.

✨ Final thought

Real growth happens when you operate slightly above your level of certainty. Not in absolute chaos (which is just noise), and not in total comfort (which is stagnation).

The useful space is right in the middle, where you can still think clearly, but you can no longer rely solely on what you already know.

The next time an opportunity comes your way that gives you a bit of vertigo, before dismissing it, ask yourself:

Why not?

I’m pretty sure you have a similar case. I would love to hear from you. Reply to this email or drop a comment in Substack, I read them all!

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

The Optimist Engineer has always been about helping engineers grow through better judgment, stronger technical thinking, and clearer decisions in real situations.

Over time, I realized that some topics deserve more depth than a weekly newsletter can give.

That is why I am preparing a paid version of The Optimist Engineer.

The free newsletter will continue as it is: useful ideas, lessons, and reflections on software engineering, technical leadership, and career growth.

The paid version will go further for readers who want to:

• go deeper into real engineering and career decisions,

• see more concrete examples and practical frameworks,

• understand not only what I think, but why I think it,

• and get a closer look at the lessons I learn while working.

This is not about publishing more for the sake of publishing more.

It is about creating a space for readers who want to move from reading ideas to applying them with more confidence.

There will be two main premium elements:

• First, a monthly deep-dive with a free section and a premium section. The public part will give you the core idea. The premium part will go deeper, with more detail, examples, visuals, and practical material. And note that I say “deep”, which does not necessarily mean “longer”.

• Second, a series of short audio notes called Thinking Out Loud. These will be small, frequent reflections from my day-to-day work: compact lessons, observations, and micro-learnings that are too immediate for a full article, but still worth sharing.

“Insightful, well-structured content that blends technical expertise with real-world experience.” — Angel Suarez, PhD, Product Development Manager

If you have found value in The Optimist Engineer so far, this new version is for readers who want to go deeper into the kind of thinking that can help them make better decisions in their own work.

So here is the simple question:

👉🏼 Would you be interested in paying for a premium version of The Optimist Engineer?

And if so, what kind of premium content would be most valuable to you?

Just hit reply, I read every response.

Thanks for being here and for reading The Optimist Engineer.

Marcos
The Optimist Engineer

I want to share something a bit different today.

Over the past months, I’ve been spending a lot of time thinking about The Optimist Engineer. What it is, what it’s becoming, and what I want it to be in the future.

When I started writing, the goal was simple:

👉🏼 Share useful ideas and real-world lessons that could help other engineers grow.

And honestly, I didn’t expect it to resonate the way it has.

Some of your replies, messages, and conversations have made me realize that this is not just a newsletter anymore. It’s something people actually find useful in their day-to-day work.

And that’s where this thought started.

Lately, I’ve been wondering what it would look like to take this one step further.

I’ve also shared these thoughts with , a friend of mine. Talking them through with someone I trust has helped me reflect more honestly on what this could become.

Not in terms of writing more.

But in terms of going deeper. Being more intentional. Sharing more of the thinking, the trade-offs, and the real decisions behind the work.

And with that idea, a question naturally appeared:

Would it make sense at some point to create a paid version of The Optimist Engineer?

To be honest, this is not an easy thought for me.

Part of it is practical.

I’ve never set up something like this before, and things like taxes, fiscal setup, and all the “non-writing” parts feel… unfamiliar and a bit intimidating.

And part of it is more personal.

There’s always that question in the back of my mind:

what if I build it… and no one is actually interested in paying for it?

I don’t have a clear answer to that yet.

What I do know is that I care a lot about keeping this space useful, honest, and worth your time.

So for now, I’m just exploring the idea. Thinking about what it could look like, and whether it would make sense at all.

I’ll share more thoughts on this soon.

Thanks for being here, and for reading The Optimist Engineer.

Marcos
The Optimist Engineer

What does a Tech Lead actually do during the week that a Senior Engineer doesn’t?

It’s easy to get lost in meetings, but true technical leadership is exercised through high-leverage technical tasks.

Today, I want to focus on the two “power moves” that will make you stand out: Architecture Reviews and Strategic Tech Debt Management.

1. Architecture Reviews: From Gatekeeper to Facilitator 🏛️

Many engineers think an Architecture Review is about being the “smartest person in the room” who says “yes” or “no” to a design. Wrong.

A Lead uses reviews to:

• Identify cross-team impacts: Does this change in the Monolith affect the new modular services we are building?

• Teach trade-off analysis: Don’t just point out a flaw; ask the team, “If we choose this database now, how hard will it be to migrate in 6 months?”

👉🏼 Leadership here is about Architecture Incrementalism.

You aren’t looking for the “Final Perfect Version”; you are ensuring the team takes a step forward without creating a legacy nightmare tomorrow.

2. Tech Debt: Stop Complaining, Start Managing ⚖️

We all have technical debt. Let’s not complain about it but manage it.

👉🏼 Growing into leadership means moving away from “we should rewrite this” toward “we will improve this incrementally.”

Here is how you lead through debt:

• The Debt Radar: Don’t just fix bugs. Identify which parts of the code are “high-interest debt”, the ones that slow down every single sprint.

• Negotiation: Your job is to translate “clean code” into “business value” for product managers. “If we spend two days refactoring this module, we will deliver the next three features 20% faster.”

Knowledge Pills 💊

If you want to start acting like a Tech Lead today, pick one of these tasks:

• Shadow a Review: Ask a Lead if you can join their next architecture sync. Don’t just watch the tech; watch how they ask questions to guide the team.

• The “Boy Scout” Rule at Scale: Don’t just leave the code cleaner; leave the architecture clearer. Document one undocumented decision this week.

• Categorize your Debt: Next time you see a mess, don’t just fix it. Tag it. Is it “Deliberate Debt” (we rushed for a deadline) or “Outdated Debt” (the system evolved)?

Wrap up ✨

👉🏼 Technical leadership is about reducing friction for your team.

When you master architecture reviews and debt management, you aren’t just “coding”; you are building an environment where everyone else can code better.

I’d love to hear your thoughts!

Which of these two tasks do you find more challenging: defending “Refactoring Time” to your manager, or giving feedback on a peer’s architecture without sounding like a “hater”?

Drop a comment below. Let’s build a better engineering culture together!

Stay optimistic and keep building.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

One of the most common questions I get from Senior Engineers is:

How do I actually prove I’m ready for a Lead role?

Most people think it’s about writing more code or being the fastest at closing JIRA tickets. But here is the truth:

👉🏼 Leadership isn’t about the code you write; it’s about the decisions you enable.

The transition from Senior to Lead requires a fundamental mindset shift. You need to stop thinking in terms of “tasks” and start thinking in terms of “systems” and “impact.”

In today’s email, I share with you 3 pills of knowledge for you to thrive in this ride.

The Mindset Shift: From “How” to “Why” 🚀

When you are a Senior Dev, you focus on the how:

• How do I implement this function?

• How do I fix this bug?

When you step into Tech Leadership, you must pivot to the why and the what:

• The Individual Contributor (IC) builds the bridge.

• The Tech Lead decides where the bridge should go and ensures the whole team knows how to maintain it.

This shift is where most engineers struggle, but there’s a perfect “training ground” to practice this: System Design.

By the way, if you are looking for good System Design learnings, subscribe for free right now to the work done by 👇🏻

The System Design Newsletter

Download my system design playbook on newsletter signup for FREE

By Neo Kim

Leadership in Action: The ETL Example 🛠️

Let’s look at a practical example we’ve discussed in this other email: Designing an ETL (Extract, Transform, Load) architecture.

A Senior Developer might jump straight into the code, picking the trendiest library to move data from point A to point B. But a Tech Lead approaches it differently. They don’t just build an ETL; they make leadership decisions through design:

1. Contract over Code: They define the “Contract” between systems. They think about how this data pipeline affects the Data Science team or the Frontend.

2. Trade-offs as Strategy: They don’t look for the “perfect” tool. They weigh cost vs. scalability. “Do we need real-time streaming, or is a simple batch process enough for our current business stage?”

3. Mentorship through Architecture: They design the system so it’s easy for other developers to contribute without breaking things.

When you document these decisions, explaining the why behind your architecture, you are already performing the role of a Tech Lead. You are providing clarity, reducing risk, and empowering the team.

Knowledge Pills for Your Growth 💊

If you want to accelerate your path to leadership this month, try these three things:

• Own the “Non-Happy” Path: Don’t just design for when things work. Lead by defining how the system fails (observability, retries, alerts).

• Write for Others: Start writing RFCs (Request for Comments). If you can convince your peers that your architecture is the right one, you are leading.

• Stop Being the Hero: If you are the only one who can fix a specific system, you aren’t leading; you are a bottleneck. True leaders build systems that don’t need them to survive.

Wrap up! ✨

👉🏼 Technical leadership is a muscle.

You build it every time you take a step back from the IDE to look at the bigger picture. Whether you are refactoring a monolith or designing a new data pipeline, ask yourself: “How does this decision make my team better?”

Now, I want to hear from you!

What is the biggest challenge you’ve faced when trying to move from “doing” to “leading”? Is it the lack of time, or perhaps not knowing how to start the conversation with your manager?

Leave a comment below, I read and reply to every single one!

Stay optimistic and keep building.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Follow-up readings 🔖

☝🏼A Schema Registry acts as the central source of truth for data schemas, helping teams manage schema evolution, enforce compatibility rules, and facilitate seamless communication between distributed services.

In today’s issue, I will address:

• What a Schema Registry is.

• Benefits of Using a Schema Registry.

• Use Cases Where Schema Registries Are Essential.

• When Schema Registries Are Not Worth It

• Major Schema Registry Solutions Comparison.

Let’s start.

🧐 What a Schema Registry is

☝🏼A Schema Registry is a centralized repository for storing and retrieving data schemas.

👉🏼 It is designed to handle version control, ensuring that any evolution in the data structures is tracked and managed.

By maintaining a clear contract between producers and consumers, the registry enables reliable serialization and deserialization of data formats such as Avro, Protobuf, and JSON Schema, among others.

In a microservices architecture, during the sync and async communication, you have to ensure that the data you will write and read is compatible with your services.

👉🏼 Basically, the producer of the data could use a version of the data, version 1.2.0, and the consumers could use the same or an older version, like 1.1.0, without breaking either side. That’s the magic that a Schema Registry does for you.

☝🏼 Thinking about your code. The different Schema Registries offer SDKs for many languages, so you can serialize and deserialize data using the API offered by the SDK.

For example, when using an asynchronous API through Apache Kafka, you will have to configure your consumer with the deserializer class offered by the SDK from the Schema Registry you have chosen.

I already anticipated one of the major benefits of using a Schema Registry, but let’s explore more.

💡 Benefits of Using a Schema Registry

I could enumerate some, like:

• Centralized Management: It provides a single source of truth for all data contracts, simplifying maintenance across microservices. And having a single source of truth in a distributed system means a lot!

• Schema Evolution: The registry supports versioning and controlled evolution, which allows for backward, forward, or full compatibility as business requirements change.

• Data Quality and Consistency: Enforcing compatibility rules helps prevent errors that might occur due to mismatches in data structure between services.

• Reduced risk of breaking change: With clear contracts defined, teams can build services independently while ensuring they communicate correctly using standardized data formats.

• Enhanced Monitoring and Governance: It provides audit trails and version histories, enabling teams to track changes and troubleshoot issues more efficiently.

How does it sound to you?

But still, is a Schema Registry something you really need? Let’s explore the use cases.

🎯 Use Cases Where Schema Registries Are Essential

1. Schema evolution without breaking producers or consumers

In event-driven systems, data models evolve over time. Fields are added, renamed, deprecated, or reorganized. In a distributed architecture where producers and consumers evolve independently, these changes can introduce incompatibilities if they are not managed properly.

👉🏼 A schema registry allows schemas to be versioned and compatibility rules to be enforced so that changes can be introduced without breaking existing services.

Without a registry:

• Each team manages its own data model in code.

• Schema changes can break existing consumers, and problems are often discovered only at runtime.

• Teams need to coordinate deployments to avoid incompatibilities.

With Schema Registry:

• Schemas are stored in a centralized and versioned location.

• Compatibility rules, such as backward or forward compatibility, can be enforced.

• Incompatible changes are detected before the producer can publish messages.

2. Explicit contracts between teams

In microservices architectures or streaming systems, events act as interfaces between different services or teams. For these interactions to be reliable, the structure of the messages must be clearly defined and accessible to all participants.

👉🏼 A schema registry allows the data model to become a formal, versioned contract that producers and consumers can rely on.

Without a registry:

• The schema usually lives in code or informal documentation.

• Consumers need to infer the message structure themselves.

• It is common to see mismatches between documentation and the actual messages being produced.

With Schema Registry:

• The schema becomes a central source of truth.

• Producers and consumers rely on the same contract definition.

• Versioning allows the contract to evolve in a controlled way.

3. Automatic validation of messages

A common issue in data platforms or event-driven systems is the presence of messages with incorrect structures or missing fields. These problems can cause failures in consumers or even break entire data pipelines.

👉🏼 A schema registry enables automatic validation to ensure that messages comply with the registered schema before they are published or processed.

Without a registry:

• Producers can send messages with inconsistent structures.

• Consumers must implement manual validation logic.

• Errors are often detected late, after the message has already entered the system.

With Schema Registry:

• Messages are validated against the registered schema.

• Producers cannot publish invalid data.

• Data quality and consistency across the system are improved.

At this point, you may think:

Damn! I need to put a Schema Registry right now!

Wait, and let’s see when it does not make sense.

❌ When Schema Registries Are Not Worth It

1. Only one producer and one consumer that are tightly coupled

When the producer and the consumer belong to the same system, the same repository, or the same team, schema evolution can be managed directly in the code and through coordinated deployments.

👉🏼 In this situation, introducing a registry adds an additional operational dependency without solving any real decoupling problem.

Without a registry:

• The schema lives in the same repository as the producer and the consumer.

• Changes to the data model are deployed in a coordinated way.

• Integration tests validate that both sides remain compatible.

With Schema Registry:

• An additional service must be operated and maintained.

• Serialization configuration and schema management introduce extra complexity.

• There is little practical benefit because the system is already coordinated.

2. The system is still in a prototype or exploration phase

During the early stages of a project, data models tend to change quickly while ideas and architectural decisions are being validated. At that stage, the priority is iteration speed rather than strict governance of data contracts.

👉🏼 Introducing a registry too early adds friction to development and slows down the evolution of the system.

Without a registry:

• Schemas can evolve rapidly together with the code.

• Changes can be made without formal compatibility processes.

• The team can iterate and refactor freely.

With Schema Registry:

• Schema changes require version registration and compatibility validation.

• Additional steps are added to the development workflow.

• Development speed decreases in a phase where experimentation is important.

3. Messages do not represent structured data

A Schema Registry is designed to manage and validate structured data with clearly defined fields. If messages contain opaque payloads such as binary blobs, compressed files, or encrypted content, there is no meaningful structure to register or validate.

👉🏼 In this situation, introducing a registry does not provide any technical benefit.

Without a registry:

• Messages are treated as opaque payloads.

• Consumers handle the interpretation logic.

• Only basic metadata may be validated if needed.

With Schema Registry:

• There is no real structure to register or validate.

• Compatibility rules cannot provide meaningful guarantees.

• Infrastructure is added without delivering functional value.

Before finishing for today, let me give you a comparison table for the Schema Registries I’ve analyzed recently.

📊 Major Schema Registry Solutions Comparison

This table provides an overview of key features and capabilities of each Schema Registry solution, making it easier to compare and select the best fit for specific needs.

✨ Takeaways

Let’s wrap up for today!

A Schema Registry acts as a central source of truth for data contracts in distributed systems. In microservices or event-driven architectures, where multiple producers and consumers evolve independently, maintaining a centralized repository of schemas allows all services to share a clear and versioned definition of the message structure.

One of its most important benefits is enabling schema evolution without breaking producers or consumers. Through versioning and compatibility rules such as backward or forward compatibility, teams can introduce changes to data models while ensuring that existing services continue to function correctly.

In addition, a Schema Registry significantly improves data quality and consistency. By automatically validating messages against the registered schema before they are published or consumed, it prevents malformed or incomplete data from entering the system and causing failures that are often difficult to detect at runtime.

However, it does not always provide value. When there is only one tightly coupled producer and consumer, or when a system is still in a prototype phase where data models change frequently, introducing a Schema Registry can add operational complexity without solving a real problem.

That’s it for today!

If you are building event-driven systems or microservices, sooner or later you will face the challenge of keeping data contracts consistent across services.

A Schema Registry can solve that problem, but as we saw, it only makes sense in the right context.

Have you used a Schema Registry in your architecture? What worked well, and what challenges did you face?

Leave a comment below, I read and reply to every single one!

Stay optimistic and keep building,

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵.

Share

🔖 Related readings

System Design Classroom

Event-Driven Architecture (EDA) is exciting until you deal with event versioning.

Or you can use an Adapter but with a twist. Yes, like in 90% of the problems in Software Development, there is a Pattern that will help you find a smart solution…

Read more

2 years ago · 62 likes · 9 comments · Raul Junco

Javarevisited Newsletter

24 Microservices Patterns for Experienced Developers

Hello guys, if you are working in Microservice projects then it make sense to learn different Microservices design pattern and principles, not just to make your architecture more robust but also to understand existing projects…

Read more

2 years ago · 36 likes · javinpaul and Soma

The Software Frontier

System Design Simplified: A Beginner's Guide to Everything You Need to Know (Part 9.1)

Hello everyone, Lorenzo here! (As always, running a bit behind schedule—but I promise, this one will be worth the wait…

Read more

a year ago · 4 likes · Lorenzo Bradanini

Today’s issue features a special guest . Here is Jorge’s introduction.

Hi! I’m Jorge Castaño, a Tech Lead helping software engineers grow technically and step into leadership with confidence. I share lessons from leading engineering teams to help you avoid the common mistakes of your first leadership roles.

I want to recommend Jorge’s newsletter for all those Spanish-speaking Software Engineers seeking growth and Engineering Leaders looking for learning resources.

Vivir del Software

Manual de Supervivencia Developer | Consejos de carrera para destacar en el mundo del Software | ¿PEC? Te suscribes | Gratis incluso si eres DevOps

Por Jorge Castaño

Without taking any more time, I'll hand the word 🎤 over to Jorge.

Congratulations, you made it. You finally have your senior developer position. It’s been a tough road.

But if you thought this was the end, I have bad news: you can’t retire yet. With any luck, you still have 30 years of daily meetings ahead.

Reaching the senior floor is not the last stage of your career, which is why today I want to talk to you about the 3 possible paths that open up in front of you.

The mindset shift

Sorry to keep bringing bad news, but the first thing you need to take the next step is to change the way you think. To reach senior, you learned in depth how programming works, which algorithms are most efficient, and which designs best fit each situation. You focused on the technical side.

Many of us have tried to progress using the same tools: more technology, more specialization, more technical depth. But now that’s no longer enough. #sad

The next level is not about knowing more. It’s about learning that your impact no longer depends solely on what you produce with your own fingers. The next step means making decisions, guiding your team, and multiplying the work of others.

It’s an uncomfortable change that requires letting go of everything that defines us: being good programmers. The challenge is no longer measured by the tickets you close; it’s more diffuse. But it’s also bigger, since every decision you make has a greater impact.

The three paths

Ok, my next role involves a greater impact on my team, but how?

Well, there are 3 possible directions. None is better than the others; you’ll have to figure out which one you want to walk.

The technical track (Individual contributor)

You’re still an engineer, but your influence is no longer limited to your own code. At the early levels — Tech Lead — you still have a concrete team, clear deliverables, and you keep writing code. Enjoy it.

As you move toward Staff / Principal Engineer, the game changes: you define technical direction, reduce uncertainty in problems others don’t even know how to start, and influence without hierarchical authority.

Climbing the technical track may mean you code less and less, but you’ll be very close to the solutions being implemented. And that feels almost the same as building them yourself. Almost.

Engineering Management

This is the path that scares and attracts people the most at the same time. You leave code as your main tool — not necessarily forever, but as a priority — and people become your job. Your success is no longer measured by what you produce, but by what your team produces.

This role requires completely different skills: listening, communication, and difficult conversations. It can be daunting because we go from being programmers to being managers. But watching your team grow and being able to help them directly is also a rewarding job.

This track change requires training — don’t think you’ll suddenly be able to handle such a different role without help. The problem is when your company doesn’t support you through it, which is most of the time. #sadder

Product Manager

Possibly the least obvious path for a developer, but an increasingly common leap in the AI era. If you find yourself asking why things get built, this is your move.

Moving into product means starting to operate in the space of what and why before how. The intersection of what the user needs, what the business wants, and what the team can build. You’ll need to prioritize, say no, and explain why.

Developers who move into product have an advantage that no non-technical PMs can replicate: they understand the real cost of decisions. But be careful: it’s dangerous to be stuck on the how when your job now is to define the what.

How to choose your path?

There’s no right answer, but there are right questions. Take some time with this, because thinking is hard work.

The most common trap is choosing by elimination or by inertia: “I don’t see myself managing people, so technical track” or “I was offered a manager role and took it.” That’s not choosing, that’s going with the flow. #saddest

Three questions to help clarify:

What gives you the most energy today?

Not what you’re good at, but what’s your fuel? Solving a complex technical problem, unblocking someone on your team, or understanding why a product isn’t working.

What are you willing to leave behind?

Every path involves a real trade-off. The technical track means letting go of direct control. Management means letting go of the code. Product means letting go of technical certainty. What loss can you live with?

Where do you want to be in three years?

Picture your day-to-day. What your meetings look like, what problems you’re solving, who you’re talking to. Choose carefully, but don’t delay the decision. Worst case, you can always go back to the technical track.

That’s it! Think about those three questions calmly before you decide your next step.

Here’s a prompt to talk it through with your favorite AI:

I’m a Senior developer thinking about my next career step. I want to explore three possible paths: the technical track (Tech Lead, Staff or Principal Engineer), Engineering Management or Product Manager.

Ask me questions one at a time to help me figure out which path fits me best. Don’t give me the answer upfront. First I want to explore what gives me energy, what I’m willing to leave behind, and where I see myself in three years.

At the end, give me your honest take on which path seems most aligned with what I’ve shared, and why.

Thanks, Marcos, for allowing me to speak to your community.

If you want to talk more about this or anything else, feel free to reach out on Linkedin.

🫂 Thanks Jorge!

Marcos back!

I want to send a deep Thank You to Jorge Castaño for sharing his experience with all of us. To learn more from Gábor, take a look at his newsletter 👇🏻

Vivir del Software

Manual de Supervivencia Developer | Consejos de carrera para destacar en el mundo del Software | ¿PEC? Te suscribes | Gratis incluso si eres DevOps

Por Jorge Castaño

Thanks for your support of my work here, really appreciate it!

If you enjoyed this article, then click the 💜. It helps!
If you know someone else will benefit from this, ♻️ share this post.

How much easier would things be if those decisions were written down, clear, and useful for whoever joins later?

In today’s email, you will learn how to stop your technical decisions from disappearing into Slack threads and endless PRs.

The real problem: technical decisions that disappear

Most problems in software systems don’t come from syntax errors.

They come from forgotten reasoning:

• A decision is made on a call.

• Someone summarizes it in Slack.

• Three months later, nobody remembers why that path was chosen.

Then someone proposes a “better” solution.

And the debate starts again.

Rework. Friction. Endless PR comments.

👉🏼 RFCs are the antidote to collective technical amnesia.

They create memory.

What an RFC actually is in your day-to-day work

Forget Internet standards.

In your team, an RFC is simply a short, structured document that explains:

• Why this change is needed

• What is being proposed

• What trade-offs exist

• What could go wrong

That’s it.

👉🏼 It’s about raising the quality of technical thinking before code is written.

And that alone changes the level of conversation.

Why writing RFCs builds authority and helps you persuade

☝🏼 Let’s be honest: Authority in engineering does not come from seniority alone. It comes from clarity and transparency.

Writing RFCs builds both in public.

👉🏼 You demonstrate structured thinking and invite participation.

Anyone can have an opinion in a meeting.

Very few people can:

• Clearly define the real problem.

• Separate assumptions from facts.

• Lay out alternatives.

• Explain trade-offs.

• Anticipate risks before someone else mentions them.

An RFC forces you to do exactly that.

And there’s something even more important: Many technically sound proposals fail because they arrive fully baked. When developers are not involved early, they don’t feel ownership. And when people don’t feel ownership, they resist.

👉🏼 Sharing an RFC as a draft changes the dynamic. It becomes a conversation instead of a decision announcement.

When you should write an RFC

☝🏼 Not every change needs one.

But write an RFC when the decision:

• Changes the architecture.

• Introduces a new or expensive dependency.

• Modifies a public API.

• Affects multiple teams.

• Has long-term impact beyond a single ticket.

👉🏼 Just to give you a real example: The last time I wrote an RFC was to propose how to implement the AGENTS.md framework in the repos of the Engineering Organization.

AI Native Compass

From AGENTS.md to sub-agents: structure and best practices

If you work in Platform Engineering or on a development team, you need to understand one thing: subagents ≠ MCPs…

Read more

3 months ago · 4 likes · Marcos F. Lobo 🗻🧭

Now, an important part.

How to handle feedback without turning it into an opinion war

☝🏼 RFCs don’t eliminate disagreement but they structure it.

To deal with this situation, a few simple rules help:

• Separate facts from preferences.

• Set a time window for feedback.

• Escalate only when needed.

• Document the final decision clearly.

And one important principle: No silent vetoes.

👉🏼 If someone blocks the proposal, ask them to write a counter-proposal using the same structure.

Where to write RFCs

I like to use Git to publish my RFCs because I find it a good tool for:

1. Reach my audience, a.k.a. developers.

2. A Pull Request permits comments and contributions.

So, if you want to start writing RFCs, my suggestion for you is:

• Create a new repository.

• Where the README.md file explains what the repo is and how to create RFCs.

• Also, you will have an RFC template that the people can (must) use to contribute their RFCs.

That’s it!

So far, you have some clarity about the RFCs. Now, let me give you the template I’m using nowadays. Click the button below to receive it for free 👇🏻

🎁 Get RFC template for free

✨ Summary

RFCs are not ceremonies. They are not corporate theater. And they are definitely not paperwork for the sake of process.

They are thinking tools.

They force you to slow down just enough to clarify the problem before jumping to the solution. They turn opinions into arguments. They transform isolated ideas into shared decisions. And over time, they build something most engineering teams lack: technical memory.

Writing RFCs will not make your code compile faster. But they will make your decisions stronger. They reduce friction. They create alignment. They make discussions sharper and shorter. And they make your reasoning visible.

And, look:

• If you want to grow as an engineer, keep writing code.

• If you want to grow in influence and authority, start writing decisions down.

Hope you enjoy today’s email. I know I made some bold arguments, and I hope you consider them when you plan your next proposal.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

In detail, today you will learn:

• The goal of an MCP.

• Components and responsibilities.

• Delivery options.

Before jumping into it, I just wanted to let you know that I am writing another newsletter on how to move from Cloud Native foundations to AI‑powered platforms. There, you will find more details about how to work with AI in the enterprise world. You can subscribe here 👇🏻

AI Native Compass

From Cloud Native to AI Native

By Marcos F. Lobo 🗻🧭

Let’s continue now.

🎯 Goal of an MCP

The MCP defines a standardized way for environments and tools (IDEs, CLIs, agents) to request context, such as files, metadata, secrets, telemetry points, policies, etc., from a Context Provider (an agent or service).

This context is used to feed LLMs/Models that perform assistance tasks (autocompletion, test generation, security analysis, etc.) without exposing the entire repository or unnecessary secrets.

🧱 Components and Responsibilities

• IDE Plugin / MCP Client

  • User interface, event hooks (cursor, selection), UI for context approval.

  • Communicates with the Agent via local socket (Unix socket/named pipe) or localhost HTTP/gRPC.

• MCP Agent

  • Orchestrates context gathering (files, git, build graph, dep).

  • Applies policies, redaction, and minification.

  • Caches results and maintains provenance history.

  • Interacts with secret/telemetry providers.

  • Calls models (local or remote) or forwards the response.

• Model Provider / LLM

  • Can be a cloud endpoint (OpenAI, Anthropic, Azure) or a local model (Llama, Mistral).

  • The Agent must be able to redirect prompts and enforce size limits.

🚀 Delivery options for MCP servers

At the time of delivering an MCP server, the deployment decision is not just technical. The aspects you have to consider are:

• Latency.

• Security.

• Developer experience.

• Operating costs.

• Governance.

The main options are discussed in more detail below.

Native Binary

An executable that the developer installs locally and that runs as a system process.

Advantages:

• Maximum performance and low resource consumption.

• Direct access to the filesystem, Unix sockets, and OS resources.

• Immediate startup (no cold start).

• Better integration with IDEs and local tools.

Disadvantages:

• Need for cross-platform builds (Mac, Windows, Linux).

• More complex version and upgrade management.

• Distribution and binary signing require a robust pipeline.

When to choose it:

• Teams with a strong focus on Developer Experience.

• Need for minimal latency.

• Environments where local access to the repository is critical.

Docker Container

The Agent runs as a Docker container locally.

Advantages:

• Full consistency across operating systems.

• Simplifies Agent dependencies and libraries.

• Easy versioning (image tags).

• Compatible with enterprise environments where Docker is already standard.

Disadvantages:

• Additional containerization overhead.

• Volume permission management (can be tricky).

• Slightly more complex UX (requires an active Docker container).

I personally don’t find these advantages really critical, but I wanted to add them from an objective point of view.

When to choose it:

• If all developers already use Docker.

• If you want to minimize “works on my machine” issues.

Cloud Service

The Agent runs as a shared service (internal or external SaaS). Clients connect remotely.

Advantages:

• Centralized policies and drafting.

• Unified observability.

• Easy to implement RBAC and auditing.

• No complex local installation required.

Disadvantages:

• Higher latency (network round-trip times).

• Privacy risks if the context contains sensitive code.

• Greater security complexity (TLS, IAM, isolation).

When to choose it:

• Large organizations with compliance needs.

• Globally distributed teams.

• When strict traceability is required.

✨ Summary

In today’s email, you get an overview of the MCP server, its architecture, and the best approaches to deliver it to your customers.

Architecturally, a typical MCP-based application has three clear building blocks:

• The IDE plugin/client (UI hooks and event triggers).

• The MCP Agent (context gathering, policy enforcement, redaction, caching, and orchestration).

• The Model Provider (local or cloud-based models).

Each component has distinct but complementary responsibilities.

Choose wisely the way to deliver your MCP. Nowadays, delivering MCP servers via Docker is my preferred choice because it offers a good balance between performance and version management.

I would love to hear about your experiences implementing MCP servers. Reply to this email or put a comment in Substack.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Your CEO, CTO, and even your CPO are telling you:

Use the AI as much as possible!

Or this other (my favourite)

So will be able to deliver faster than before!

I will not jump into this debate (today), but into another: the development of the in-house services that implement the Model Context Protocol, to be used by AI Agents in the IDE of the developers.

I’ve seen many folks in Platform Engineering teams start writing MCP-based services meant to be used by the dev teams, and I wondered:

Hey, does this actually solve a problem for the dev teams?

In today’s issue, I want to share with you my vision about when an in-house MCP-based service makes sense.

Before jumping into it, I just wanted to let you know that I am writing another newsletter on how to move from Cloud Native foundations to AI‑powered platforms. You can subscribe here 👇🏻

AI Native Compass

From Cloud Native to AI Native

By Marcos F. Lobo 🗻🧭

Now, let’s get back to our business.

First of all, is this an automation?

Platform Engineering teams are meant to provide frameworks, CI/CD workflows, libraries, processes, and best practices to the Software Engineering teams so they can ship value to customers fast.

Platform Engineering teams have a great responsibility: choose the right solution so that Software Engineering teams will embrace and onboard the solution smoothly.

Since Software Engineering teams work with IDEs, and thanks to the existing integration between IDEs (VS Code, IntelliJ) and AI Agents, or existing IDEs like Cursor or Windsurf, one of the steps that could make sense is:

Let’s create an MCP-based service so developers can use it from their IDEs.

This is a great approach.

However, I’ve seen many Platform Engineering teams failing on this. Why?

👉🏼 They implemented an MCP-based solution when the feature teams needed just an automation.

Do not mix AI with automation; they are different things.

So, next time you think the solution is an MCP-based service, ask yourself the following:

Can the work be done by an automation?

Is an in-house MCP-based service needed?

Look at this huuuge list of MCP servers available, many of them are official from their providers.

So, another question to ask yourself?

Will my MCP-based service solve a problem that isn’t already solved by existing MCPs?

I’ve intentionally made that question plural.

Connecting multiple MCP-based services to tools like Cursor or Windsurf already allows an AI Agent to solve problems that span multiple sources.

In fact, AI Agents can already orchestrate across the configured MCPs to resolve those problems.

So the real question is:

Why add another MCP that acts as a wrapper?

Maybe yes!, maybe no!

I’ve raised a couple of reflections that now your brain is trying to plug and play with the rest of your ideas. In order to help you, I will now list when it makes sense to create an MCP and when it does not.

When does an in-house MCP-based service not make sense?

• Small organizations (1–2 teams) where the operational overhead of the MCP outweighs the benefits.

• Top priority: developer speed and minimal friction (you prefer direct adapters in the IDE).

• High team autonomy: with very different rules and an aversion to centralization, the MCP will become a source of political friction.

• When the cost of maintaining adapters/compatibility outweighs the benefits, e.g., too many vendors with unstable APIs.

When does an in-house MCP-based service make sense?

• You have >=10–20 teams with different policies and want global consistency (rulesets, RBAC, auditing).

• You need correlation/dedupe between findings from multiple scanners (SAST, SCA, linters, Sonar, etc.) to prevent one bug from appearing as three.

• Compliance/audit requirements: logging who automated what, blocking pull requests based on corporate policy, and evidence retention.

• You’ll want to enforce cross-functional policies, like legal or privacy rules affecting all repositories, and enforce controlled downgrades when providers fail.

Let’s wrap up for today.

✨ Summary

Keep this in mind:

👉🏼 Just because you can implement an MCP-based service to solve a problem doesn’t mean you should.

From there:

• Make an assessment of the problem you need to solve.

• Is it something you can solve with automation?

• Be sure you have the right expertise in the team to implement these kinds of tools.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Money is important, more and more every day, and when you are in the cloud, holding the money is a real challenge 💸.

That’s why, in today’s issue, I will give you an overview of OpenCost, a CNCF project.

But first things first, what OpenCost is?

It’s an open-source, vendor-neutral project that brings real-time cost visibility and allocation to Kubernetes and cloud infrastructure so engineering teams and platform teams can make data-driven decisions about efficiency and showback/chargeback.

Nice definition, right? For me, that kind of definition are okeysh, but I really need to understand what it does.

🤔 What OpenCost actually does

• Measures & allocates cloud and Kubernetes costs in near real-time (CPU, memory, storage, network, GPU, etc.).

• Maps cloud billing to Kubernetes concepts, so you can answer “how much did team X spend last week?” or “which deployment is causing the spike?”

• Supports multi-cloud and on-prem via integrations with AWS/Azure/GCP billing APIs and customizable pricing models.

Another thing I see super useful for real life is that OpenCost can give you the money you burn by namespace. Why is it important for me? Because, usually, the resources from the different dev teams are deployed in separate namespaces, hence, each dev team can see how much their stuff costs.

From there, the next step is obvious. Having namespace costs allows you to:

• Allocate expenses directly to teams or products (if each team uses its own namespace).

• Quickly identify which namespace is consuming the most resources or money.

• Integrate with showback/chargeback processes within your platform.

Last but not least, I think it’s important to mention that OpenCost is Kubernetes-native: you typically deploy it into your cluster(s) (Helm charts available), and it relies on existing metrics sources (Prometheus) and cloud billing data for price lookups.

🎯 Problems it solves

When you start deploying your SaaS product into a Kubernetes clusters you face many challenges. Some of the ones related to costs are:

• Opaque Kubernetes spend. Kubernetes abstracts resources, but that abstraction hides who/what is actually driving costs. OpenCost restores accountability.

• Ownership breaks down in shared Kubernetes platforms. Kubernetes clusters are shared by design. Cloud providers bill at the account or subscription level, but teams think in terms of services and products. Without a clear ownership model, questions like “which team is driving this cost?” are hard to answer. Manual mappings and spreadsheets 😱 appear as workarounds.

• Kubernetes hides the true cost of “idle”. Over-provisioning, shared nodes, and autoscaling make it hard to understand idle capacity and inefficiencies. OpenCost surfaces these hidden costs, allowing platform teams to reason about efficiency in concrete, measurable terms.

🧐 State of the project

OpenCost is a CNCF project that progressed from Sandbox into Incubating. It was accepted into CNCF in mid-2022 and promoted to Incubating in October 2024, reflecting growing community adoption and governance maturity.

The project is actively maintained (GitHub repo, releases, and community contributors) and has continued to publish roadmaps and year-in-review notes describing frequent releases and expanding integrations.

Recent public updates indicate priorities around refining cost models, improving supply-chain security for cost data, and adding features to better track emerging workloads (for example: AI/ML usage costs).

✨ Summary

Many companies include the cost assessment before implementing the solution. Others (lucky you) just jump into implementation, and then the problem of understanding the cost comes.

In any case, whether you made an estimation, or you just don’t know, nowadays (always?), you must have visibility on the costs of the applications and resources deployed in your Kubernetes, and OpenCost is one of the options available.

That’s all for today!

I would love to hear about your experiences using OpenCost or any other tool for measuring the costs of cloud applications. Drop me a comment or reply to this email; I will read it and come back to you!

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

👉🏼 You need to be seen doing the work of the role you want.

Over the last few months, I’ve written several articles about Staff Engineer, technical leadership, ownership, and breaking out of silos.

I’ve now condensed all that practical advice into a one-page playbook you can actually use.

☝🏼 It’s a set of behaviors, habits, and templates you can start applying this week.

What’s inside the playbook?

• The core mindset behind Staff roles: scope and consistency.

• 8 practical habits Staff Engineers repeat over time (delivery, cross-team impact, metrics, mentoring).

• Ready-to-use templates: weekly stakeholder update, experiment write-up, meeting ritual.

• What to bring to your 1:1s: a simple evidence-based dossier for promotion conversations.

• A weekly checklist to stay focused and avoid “invisible work”.

Why I built it

Because Staff Engineer is not a title you wait for: It’s a pattern of visible behavior you build over time.

And most engineers don’t fail because they lack skill; they fail because their impact is scattered, siloed, or invisible.

👉 Download the playbook

You can download the one-page Staff Engineer Playbook here:

📦 Download the playbook for free

Let’s make it practical

Once you’ve read it, reply to this email with:

“#X → my hardest habit”

(where X is the habit you struggle with the most)

I’ll reply with 3 concrete actions you can take next week to start building Staff-level evidence.

Stop waiting to be “ready”.

Start behaving like the role you want.

Hope you enjoy this playbook!

Be safe,
Marcos

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

What can I do for getting promoted for the role I want?

If you are working in a tech product company, with around 800 or 1K employees, you have to know that you will not get a promotion just because “the time came”.

👉🏼 Instead, you have to demonstrate you can do the job before getting promoted.

I will not discuss here whether this is a good practice or not. It’s just the reality.

In today’s email, I will focus on the journey to the Staff Engineer role, and I will share with you 3 actions that are a must for you to get promoted to Staff Engineer.

The prerequisite here is to catch the opportunity to lead a project. In my experience, this can happen in two ways:

This opportunity can come to you from upper management. For example:

Silvia (you), there is a project for reducing costs in our obserbability system, and I want you to lead it.

Or you build the opportunity. For example:

Hey Barbara (your manager), I’ve validated a POC for feature teams own and deliver their own infrastructure, which will make them 2x faster to production with the same quality than today.

In the real world, this last one takes more time than just a sentence like that, but I hope you see the point.

Once the opportunity is on you, these are the 3 actions I found successful in many cases for the person get promoted to Staff Engineer.

Ownership end-to-end

You are THE person for a project, from the beginning to the end.

As simple as it sounds. You will be the person whom managers will ask in case they have questions or require information.

You clearly understand the problem and the expectations of the stakeholders.

You are responsible for everything on the project. If you have dependencies, you will have to manage them and coordinate the priorities across all of them.

To be able to get the full level of ownership, I start asking this 3 questions as many times as I need to really feel I have control of the project.

1️⃣ What is the problem we want to solve?

• What are the use cases?

• What is the pain?

2️⃣ What’s the benefit for the company?

Is it cost saving, efficiency, reducing incidents in production…?

You have to know the priorities at the company level, so you can align the solution in that direction.

3️⃣ Who is the customer and what are the dependencies?

This could be either the customers of the company or internal customers, like developers, marketing, etc.

If you are praying for not having dependencies, sorry. If the project is meant to be done by a Staff Engineer role, for sure, you will have dependencies… and most likely outside of your organization. But this is good in the sense that, once you succeed (because you will 😉), you demonstrate you can coordinate with external people and coordinate successfully.

Communication

Oh dear, this is the most important part of this framework; Bring visibility to your stakeholders and managers.

You can communicate at any time:

• When progress

• When blockers

• …

☝🏼 Overcommunicating is better than a lack of communication.

Ensure you understand how your stakeholders like to get communication, such as:

• When (daily, weekly, …). I would recommend you start weekly and, if your sta

• The format. I usually like to be precise, using the framework:

  • TL;TR

  • Context

  • Current status

  • Next steps

• Via email, Slack, meeting, Confluence page, …

🎁 At the end of this email, I give you a Pro Tip about communication. But, for the moment, let’s continue to the last point of this framework.

Plan

You most likely prepared a plan to deliver work for your team before reaching this big project. The idea here is the same, but on a wider scale, including your external dependencies.

1️⃣ Brainstorming / Kickoff

Join your team and your dependencies (if possible), and explain the project. Also, prepare a brainstorming session for the key problems of the project. This will bring ownership from all.

This part could sound easy, but it could become tricky because you may face some people that generates noise or hijack the session (most likely with no intent to). Polish your human skills to sail the brainstorming session to your north star and so achieve your goal:

1. Communicate.

2. And get feedback.

2️⃣ Technical Story Mapping

This is something that you will find very useful. I have pending an email for a deep dive into Technical Story Mapping. Until then, I can tell you this is an exercise on which:

• Identify the categories of work.

• The work to do on each category.

• Prioritize the work.

• Coordinate with your dependencies.

The previous brainstorming is really useful for this.

I like the tool Miro for Story Mapping, but you can use any other tool that allows you to print “boxes, stickers, and text”.

3️⃣ Continuous sync

For this, return to the part I wrote about communication, because it’s the same, but with a difference: here, you don’t need (or want) the stakeholders.

This is more for the Workforce or Virtual Team (however you call it) that will work on the project you lead.

The format I like the most is a Weekly Ops meeting for the project, where you:

• Explain where we are.

• Check the status of your dependencies.

• Identify blockers, and the owner who can solve them.

• Next steps

✨ Summary

Let’s wrap up for today.

• Promotions to Staff Engineer are not about tenure, they are about demonstrating you can already do the job.

• The journey starts by leading a meaningful project, either assigned by leadership or proactively created by you.

• Success at this level requires three core actions.

• Take full end-to-end ownership, from problem definition to delivery and dependency management.

• Communicate early and often, giving visibility into progress, risks, and next steps.

• Create and execute a clear plan that aligns teams, dependencies, and priorities.

The key idea is simple: act like a Staff Engineer before you get the title.

Don’t forget about the Pro Tip! 👇🏻

🎁 Pro Tip

For every single meeting you have during the development of the project, you should:

1. Prepare an agenda with the goal, context, and expected outcomes.

2. Once the meeting ends, reply with the meeting notes and action items (a meeting without action items is a waste of time, meaning that an email could solve it).

3. Record the meeting notes and action items in a place where you can get back to them in the future, in case you have to remember a decision.

This saved me a couple of times already, mainly when someone comes to challenge your plan when you are in the middle of its implementation.

🔖 Follow-up readings

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Based on that, and taking into account our use case, we decided to implement an AWS Serverless approach, more concretely, using an AWS Step Function.

In today’s email, I want to share with you what the Software Architecture I tend to use in this kind of application is, so that you can apply it as well.

Before continuing, if you like my work and you want to support it, I would appreciate it if you could share this newsletter with your peers via:

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Or just forward this email. Thanks in advance!

Getting back to our business…

If you read me for a while, you know that I like to reduce complexity as much as possible.

👉🏼 Making things simple is complex.

Input, Output, and Use Case

As simple as it sounds.

For each of the lambda functions within a Step Function, the Software Architecture that works well for me is:

• input. In this package, you will implement the code for reading from the outside world. For example, if your app has to download a configuration file from an S3 bucket, call a REST API endpoint, etc., you will implement it here. Within this input package, I would advise having a sub-package per technology from which your app will read, so you encapsulate each.

• output. In this package, you will implement the code for pushing data outside of your app. For example, if your app needs, after your business logic, to write a file into an S3 bucket, this is the right place. Same as for input, I would advise having a sub-package per technology from which your app will write, so you encapsulate each.

• Use Case. Assuming you have a single use case (since this is an ETL), you can resolve your “orchestration” from one single use case, which uses the different inputs, executes the business logic, and uses the outputs.

A question that I recently got about this Software Architecture was the following:

What happens if, from one of the APIs I use in the input package, I need another dataset? Could I just implement a new function in the input package for that and leverage the existing code?

☝🏼 That means a new domain. It does not matter if you read data from one or many APIs, but the domain matters.

For example:

• If you are gathering information about Observability, it does not matter if you gather that from Datadog or New Relic; what matters is the concept of Observability (the domain) for you.

• If you are gathering information about Applications, it does not matter if you gather that information from Datadog as well; what matters is the concept of Applications (the domain) for you.

Another example:

• If you are gathering information about Bugs, it does not matter if you gather that information from Jira or others; what matters is the concept of Bugs (the domain) for you.

• If you are gathering information about Tests executions, it does not matter if you gather that information from Jira as well; what matters is the concept of Tests executions (the domain) for you.

Then, you need to implement a new Lambda Function (in the context of the Step Function) that resolves the ETL for each of the domains.

If you still want to reuse code (which I would recommend), when using Step Functions, you can leverage AWS Lambda layers. They allow you to share common code across multiple Lambda functions within the same workflow.

As you can see, this is not exactly a hexagonal architecture, but an adaptation from it.

I would love to hear from you and about Software Architecture in general, and for ETLs in particular. Write down a comment, I'll read you.

Cheers!

Marcos, where do you find the time writing, besides working as Tech Lead for a company and have an actual life outside of the keyboard?

I explained how I organize myself for finding time for writing, even though I’m not a writer per se. To that, he told me:

Marcos, you should write about that. I’m pretty sure it can help more people.

And I took his advice, and so here we go today.

In today’s email, I will explain to you why I write about software development and how I find time for writing about it.

Before continuing, if you like my work and you want to support it, I would appreciate it if you could share this newsletter with your peers via:

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Or just forward this email. Thanks in advance!

Now, let’s start with the Why.

Why do I write about Software Development?

It helps me to settle down my experiences.

Writing about Software Development helps me by:

1. Put in perspective my experiences and learnings.

2. Learn from my own experiences.

And, as far as the feedback I get from you, it helps others who will walk through my same track at some point.

Another question that Ángel raised:

But, Marcos, how do you find to topics to write about?

I write about what happens in my real work life, or about close friends I trust, which makes it very easy to find topics. Fortunately (?), in my daily work, many things happen, many learnings, every single day.

Because of that, the topics flow very smoothly.

How do I organize my time for writing?

In the train, I have 4 hours of commuting home.

I know, it’s a lot. Let me give you context.

Almost three years ago, because of personal decisions, I started commuting longer than before: by train, two days a week (I have a hybrid position), two hours from home to work, and two hours back.

I saw an opportunity in this new situation of my life, and so I started writing this newsletter, The Optimist Engineer.

Yeah, I know, I could use those four hours for something more human, like sleeping, or getting a dopamine boost from the infinite scroll of any social media app.
And I’ll confess that I do that sometimes, just not during the four hours of commuting.

I use my train rides back home to write. I invest two hours, twice a week, in writing a new newsletter. As I write these lines, I’m traveling at 298 km/h by train, in the middle of nowhere on the map of Spain.

I can tell you this aspect of my life has made me become consistent during these 3 years; since 2024, I have been writing a new issue of this newsletter per week. That’s a lot for me, I can tell you. In the past, I started this blog, which I gave up because I was not able to find a regular moment for writing.

The pain of having to commute 4 hours, twice a week, helped me to become constant.

If you want to start writing, my advice is:

1. Write about something that comes naturally to your mind. For me, it’s very easy to write about things that happen on a daily basis.

2. Find your slot. Same as for going to the gym, find a slot where you can write. I write for 2 hours, twice a week, only, that’s why my newsletter issues are no longer than 4 or 5 minutes of reading!

Hope this helps others, as my friend Ángel expected. If yes, I would love to hear from you and about your struggles. Write down a comment, I'll read you.

Happy New Year to everyone!

I usually take the last two weeks of the year to get rest, and I want to take this moment to thank you for this exciting year 2025 and your support along the ride.

Seriously, thank you. I wish you the best for the coming year.

You will receive my next email in the first week of January 2026.

If you have read my newsletter for a while, you know that I’ve been deeply immersed in the Product Platform Engineering world for the last 8 years. In case you want to go deep into what a Product Platform Engineering Team is, I recommend the following reading 👇🏻

In today’s email, I go one step beyond, and you will learn the technical principles on which a Product Platform Engineering Team should be based.

The main idea of today’s email is this:

You need to define a way of working so your team can release their applications, libraries, and frameworks quickly.

Otherwise, the DEV teams will find a way to achieve the same on their own.

To achieve this, you must focus on the following steps, in order:

1. Programming language and framework to use

This is extremely important to me; it can be the difference between taking half a day or a full week to deliver a new feature to teams using the framework.

You have to pick up a language and framework/libraries that enable your team to deliver fast.

A Product Platform team must be pragmatic from day one. The language should let you achieve high performance with minimal code. Likewise, the framework must offer transparent support for observability: logging, metrics, and tracing should be first-class citizens.

How to choose it? I recommend that you make the decision based on:

1. What is the most common language/framework used in the Engineering organization?

2. Are there enough people in the market knowledgeable about that language/framework?

3. Is the language/framework mature enough to provide an easy way to have things like observability out of the box?

☝🏼 Crucial: the team must be proficient in the chosen language and framework. Don’t pick a language that only one person in the company understands.

2. Avoid pointless debates that don’t help the development teams

Some people will argue tabs vs spaces, others will push Google’s linter, and others want a custom rule set. Some prefer squash merges, others don’t.

These are details that add no value to your real customers: the development teams. Why waste time opening debates about it?

☝🏼 Let’s focus on the business value and the priorities.

Development teams want new features or ways to deliver those features, the same goal as your end users.

3. Use the same CI/CD as the development teams

Be close to the development teams’ pain.

☝🏼 Their pain must be your pain.

If they struggle with the CI/CD system, you should experience the same constraints because that alignment will make your platform more useful and realistic.

• If you implement CI/CD functionalities for development teams, your team should use them as well.

• If your team uses something else, you have to use it too.

You have to understand their struggle so you can propose solutions for them.

4. Hold yourselves to the same standards as the development teams

You might not be running business traffic, but that’s not an excuse to lower standards.

Best practices, such as:

• Pair Review / Programming

• TDD

• Software Architecture that speaks (Screaming Architecture mentioned in the Clean Architecture book)

• Security updates

• Among others that are demanded for development teams, so they can deliver high-quality products.

☝🏼 Apply the same level of scrutiny for support, monitoring, and reliability to the Product Platform team as you do to the development teams. That closeness helps you understand their perspective and provide better support.

Some examples of this are:

• Monitoring: development teams have monitors and alerts when services fail, then your QA Enablement team should too.

• Support: development teams rely on a support network to help each other, then build the same for your team.

Those are the minimal commitments to reach in any Product Platform team.

☝🏼 Ensure you put in place a way of working as a team before implementing solutions for the DEV teams.

Hope you find this email useful, and I would like to hear your vision about how to build Platform Engineering teams. I read you in the comments.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky