Remember when we used to joke about a new JavaScript framework dropping every week?

AI saw that and said, “Hold my transformer.”

Now we get new models, research papers, AI-assisted coding tools, and agentic systems—every week. By the time you grasp one, three more show up, and yesterday’s favorite is already deprecated.

So you open another tab, skim another newsletter, and save another tweet thread for later. You tell yourself, “I’ll start once I catch up.”

But you never do.

Because in AI, catching up isn’t a milestone. It’s an illusion.

Let’s talk about how to actually make progress.

The Never-Ending AI Hype Loop

We’ve seen this cycle before in tech. Frontend developers know it well.

A new framework launches. It’s faster, smaller, and more elegant than anything before. Tech social media lights up. Blog posts declare it the future. Everyone piles in.

Then reality sets in. The docs are vague, the edge cases break, and actual teams hesitate to adopt it in production.

The hype fades, replaced by the next big thing. And the cycle repeats.

AI follows the same loop now, only it moves faster:

1. The drop: A new model or tool launches. Everyone calls it a game-changer.

2. The hype: Threads, tutorials, and hot takes flood your feed.

3. The stall: You try it, get stuck, and move on.

4. The chase: Something else drops. You jump again.

Eventually, you’re drowning in bookmarks but haven’t shipped a thing.

At some point, you have to ask yourself: What are you actually learning by jumping tool to tool?

In many cases, the answer was nothing that sticks.

The Readiness Trap

You’re not stuck. You’re stalling.

You want to learn AI engineering the right way. Not hacks or shortcuts but real foundations: models, prompt (or context) engineering, RAG, evals and workflow automation. So you start collecting. A course here. A repo there. A bookmarked talk. A long explainer.

The list grows. So does the pressure to feel “ready.”

But learning isn’t the problem. It’s the waiting. You’re caught in what Ira Glass calls the taste–skill gap: your eye for quality grows faster than your ability to create. So you delay. You prepare. But never quite start.

Meanwhile, people shipping half-baked AI hacks are learning faster. They ship. Break things. Fix them. Improve. You’re still curating resources.

Are you stuck in pre-work?

• You’ve watched more AI talks than you’ve written lines of code.

• Your “AI” folder has subfolders named To Read and Read Soon.

• You compare tools by features you’ve never actually tried.

• You feel behind but couldn’t name a single problem you’re trying to solve.

If two or more landed, you’re in the trap.

The way out? Pick something small and real and let the work pull the learning.

Fundamentals Over FOMO

The more you scramble to keep up, the less you actually learn.

When you’re chasing every shiny new model, tool, or framework, you’re not deepening your skill. You’re skimming. And in fast-moving fields like AI, shallow learning is indistinguishable from none at all.

There’s a name for this: the information-action ratio. Coined by media theorist Neil Postman, it describes the widening gap between what we learn and what we actually apply. Most AI content today widens that gap. We consume more than we apply, so our sense of progress becomes distorted.

Chip Huyen, author of AI Engineering, calls it out clearly: “The more we want to not miss out on things, the more things we will miss.” That’s the FOMO paradox. When you chase every shiny new model or framework, you stay shallow.

Instead of chasing the latest trend, choose fundamentals: learn how LLMs work, how retrieval-augmented generation helps, when to fine-tune, how to build an MCP server, and how to build agents. These concepts are not going away next week. They’ll still matter next year.

And solving the problem is still more important than picking the coolest tool. Many teams build AI wrappers that feel clever but solve nothing. Skip the tech flex. Go for clarity.

You don’t have to know everything. Just enough to solve something real.

Momentum Over Mastery

Here’s the uncomfortable truth: the fastest learners in AI aren’t the smartest. They’re the ones who ship.

They don’t wait to master prompt engineering before building a bot. They build the bot, watch it break, and then learn what they actually needed. That’s the cheat code: learn just in time, not just in case.

There’s even science behind this. Behavioral economists call it the IKEA effect: we place more value on what we build ourselves, even if it’s clumsy or imperfect. That ugly script you cobble together will teach you more than a dozen tutorials. And you’ll care more about it simply because you made it.

Real learning begins when your bot breaks in the wild. That’s feedback, not failure.

While others worry about falling behind, you’re moving. And movement beats mastery every time.

Not sure where to start? Try one of these micro-wins:

• Build a GPT that summarizes meeting notes.

• Use an LLM to extract structured data from messy email threads.

• Add autocomplete to a form everyone hates.

• Spin up a tiny agent that knows only your internal docs.

You don’t need a thesis project. You need a feedback loop.

Final Thoughts

You’re not falling behind. You’re stuck in a system built to make you feel that way.

AI moves fast, but your job isn’t to chase it. It’s adopting it.

The people who learn fastest aren’t the ones who read the most. They’re the ones who try, fail, and adjust. Every ugly script that breaks teaches you more than another unread tutorial.

You don’t need to catch up. You need to start.

Pick a problem. Build something tiny. Let it break.
And if you’ve already started? Keep going.
You’re ahead of more people than you think.

Stop hoarding. Start shipping.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

A small team. A smart model. A few powerful workflows.

That’s all it takes to ship a working product in 2025.

No backend. No frontend. Just logic wired together with a few drag-and-drop nodes in a workflow automation tool. From idea to revenue, the gap has never been smaller.

This isn’t a thought experiment. It’s live in production across startups and enterprises. Product engineers, platform teams, and CTOs are all trading glue code for AI-first automation.

Zapier and Make are excellent choices for quick, no-code wins. When you need deeper logic, full ownership, and predictable costs, n8n hands you the keys to the stack.

Let’s break down what’s happening, why it matters, and how to get ahead.

What Is an AI Workflow?

An AI workflow is a chain of tasks triggered by events, powered by logic, and enhanced by intelligence.

Think of it as a pipeline that listens, thinks, and acts:

• A new request comes in → that’s the trigger

• An LLM analyzes the content → that’s the reasoning layer

• A response gets sent or a record updates → that’s the action

Unlike traditional automation, AI workflows don’t just move data; they understand it. That’s the difference. Models like GPT‑4 or Claude can classify, summarize, translate, extract, or decide what comes next.

At their core, AI workflows are modular systems that blend APIs, logic, and models into flows that scale. No need for a full team. Just a trigger, a few smart nodes, and a clear goal.

You can think of it as automation with a brain.

The Problems AI Workflows Solve Today

Remember the glue work that used to take days? The manual hand-offs, the spreadsheet shuffling, the ticket triage? AI workflows wipe it out in minutes. You can ship a working prototype before your coffee cools.

Plug in a language model and your automation goes from reactive to intelligent. Now it can:

• Summarize documents on demand

• Tag or triage support requests

• Draft context-aware email replies

• Score leads or detect tone in feedback

• Route tasks based on reasoning, not rules

Want more power? Build agentic workflows. Let AI decide what happens next. The Model Context Protocol (MCP) makes it possible for workflows to think and act like tools with intent.

People are already putting this into action. Here are a few examples worth borrowing from:

• A solo founder built an AI resume reviewer that screens CVs with Claude Sonnet 4 and ranks them in Airtable, all without code.

• Another flow uses GPT-4 to auto-tag support tickets, fetch relevant docs with RAG, and draft first replies, cutting response time in half.

• An open-source project combines OpenAI, Notion, and Telegram into a personal AI journaling assistant, fully powered by n8n.

This isn’t a side project trend. AI workflows are becoming the new backend for actual businesses, letting small teams automate the work others still do by hand.

Why It Matters to Engineers and Leaders

AI workflow automation isn’t about replacing developers. It’s about amplifying them.

With tools like n8n, engineers skip boilerplate and focus on product logic. They can prototype in hours, automate the busywork, and ship faster without waiting on infrastructure glue.

For engineering leaders, AI workflow automation is a force multiplier. It lowers the cost of experimentation, shortens delivery cycles, and reduces the chaos between tools and teams. It frees engineers to focus on meaningful work and reduces the cognitive load of repetitive tasks.

Best of all, teams can now add AI features without spinning up a dedicated ML squad. That means more velocity without more headcount.

Ignore this shift and you’ll fall behind. Embrace it and you unlock real leverage across your org.

The Tools Powering the AI Workflow Boom

We’ve had workflow builders for years. Zapier gave everyone a no-code “if-this-then-that” button. Make added a visual canvas so power users could branch, loop, and route data. Both still shine for quick wins, especially when the builder doesn’t write code. But their pay-per-step pricing and fixed logic start to pinch as workflows grow.

Then the open-source upstart n8n arrived.

“Think it. Build it. Extend it.” n8n is simple enough to launch a working automation in hours, yet powerful enough to scale with your business. No step limits. No rigid templates. Just full control over how your logic flows.

Self-hosted or cloud. Unlimited steps. Custom JavaScript and Python nodes. A drag-and-drop editor that now speaks GPT-4 out of the box. It even connects AI agents and tools letting a workflow reason, decide, and act.

AI engineers love n8n because it never says “no.” Leaders love it because it turns glue work into speed.

n8n isn’t a no-code toy. It’s a low-code powerhouse. Code when you need it, UI when you don’t.

Here’s how the three most popular tools stack up.

Each tool has its strengths. The right choice depends on how much control you want, how much code you’re comfortable with, and how far you plan to scale.

Getting Started with AI Workflows

AI workflow automation can feel like magic. But the on-ramp is more IKEA than rocket science: pick your kit, follow the steps, and snap each piece into place. Whether you code or not, you can build your first AI workflow before your coffee cools.

Choose Your Path

If you’re non-technical, start with Zapier or Make. Their drag-and-drop editors and large template libraries let you build simple automations in minutes.

If you’re technical but new to automation, test-drive n8n Cloud. You get a visual canvas and can drop into JavaScript or Python when your logic needs more power.

If you’re an engineer who wants full control, self-host n8n. You own the stack, avoid per-step fees, and can connect to private APIs or on-prem data without red tape.

Learn the Basics

• Workflow fundamentals: Zapier Learning Center and Make Academy are great for learning the core mental model of automation.

• n8n in action: Explore the n8n Workflows Library and GitHub repos like awesome-n8n-templates or n8n workflows for real, forkable examples.

• Deeper dives for builders: Check out the n8n Docs, the r/automation Reddit community, and YouTube channels focused on AI workflow automation.

One Small Step

1. Spin up an n8n cloud account or run npx n8n in your terminal to try n8n locally.

2. Select “Test a simple AI Agent example” or import a starter AI template from the n8n gallery.

3. Add your OpenAI key if your workflow uses the OpenAI Chat Model component.

4. Tweak the logic to fit your workflow.

5. Hit save and watch the busywork disappear.

AI workflow automation is no longer reserved for Big Tech or PhDs. It’s here, it’s fast, and it’s surprisingly fun to learn.

Final Thoughts: The AI Workflow Stack

The classic stack was backend, frontend, and database. The modern one adds AI, workflows, agents, and automation. These are the tools that let small teams move faster than ever.

Ignore this layer and you’ll ship slower and spend more hours on repetitive work. Embrace it and you’ll prototype in hours, reduce overhead, and focus on real product value.

If you haven’t tried AI workflow automations yet, the gap between you and the frontrunners widens every day. Start with one nagging task, wire it up, and feel the leverage.

Already using it? Double down. Keep n8n in your toolbox, share what you build, and push the limits of what a single flow can do.

Automate or be automated. Your move.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

Now LLMs keep asking for context, and the old APIs just shrug. Your systems are neatly locked behind endpoints built for humans, not machines. That means a constant mess of fragile connectors and “just one more” integration.

The Model Context Protocol (MCP) solves this with one clever move. It doesn’t replace your APIs. It finally makes them usable by AI, connecting your products to the next generation of intelligent assistants and agents.

Here’s how it works, and why every AI engineer and engineering leader should care.

What Is MCP And Why It Matters?

Think of MCP as a universal adapter for AI applications, similar to what USB-C is for physical devices. It’s an open standard, introduced by Anthropic that lets AI plug into any tool, database, or service with one simple connector. No more writing custom code every time you want to connect your AI models to different data sources and tools.

For years, every new model or data source meant another delicate integration. Before long, you’re drowning in breakpoints, custom connectors, and yet another round of authentication hassles. MCP fixes this. Build once, and your AI systems can finally collaborate, freeing your team to focus on the work that matters.

Here are some key differences between MCP and traditional API integrations:

Why bother with MCP? It lets you build AI agents and complex workflows on top of LLMs, minus the integration headaches. Since agents often need to work with data and tools, MCP offers a growing set of pre-built integrations your models can use right away. You also get the freedom to swap out LLM vendors when it suits you, plus best practices for keeping your data secure inside your own infrastructure.

Instead of juggling custom API integrations for every data source, developers can now build against a single standard. As MCP gains traction, AI systems will keep their context across tools and data, paving the way for a more flexible and scalable architecture.

MCP isn’t here to take over APIs. In fact, most MCP servers work by wrapping existing APIs. For example, the GitHub MCP server exposes high-level tools like “repository/list” for AI, but under the hood, it’s making regular REST API calls to GitHub. MCP and APIs aren’t rivals, they’re layers in the modern AI stack. MCP gives you an AI-friendly interface on top, often using familiar APIs as the foundation.

MCP Architecture

The Model Context Protocol (MCP) follows a clear client-server model. The idea is simple: keep the AI “brain” separate from the data and tools it needs, and control what it can reach.

At its core, MCP lets a host application connect to as many servers as needed, each one exposing different capabilities. The protocol uses JSON-RPC 2.0 messages to establish communication between:

• MCP Host: This is the AI-powered app or agent, like Claude Desktop, an AI IDE like Cursor or VS Code with Copilot, or any tool that wants to access outside data. The host runs the LLM and decides what to ask for.

• MCP Client: The connector managed by the host. It sets up a dedicated line to each MCP server, relaying requests and responses in both directions. The LLM never talks directly to the outside world. Every call and response is filtered and controlled.

• MCP Server: A lightweight program that exposes a specific set of capabilities. Servers can connect to files, databases, APIs, or any system you care about. Each one describes what it can do in a standard way, so the AI always knows what’s possible.

This architecture enables safe, two-way communication between AI and external sources. The AI can fetch data, trigger actions, or stream updates, all through a standardized, stateless protocol. You can run servers locally to keep things private or connect to remote services over HTTP. Either way, you avoid tangled code and scale up integrations without the usual hassles.

MCP draws inspiration from the Language Server Protocol, which made it easy to add new programming languages to any development tool. Now, MCP brings the same simplicity to AI applications, letting you add new data and tools with minimal effort. Define what’s allowed, plug in your tools, and let MCP handle the heavy lifting. The result: cleaner, safer, and much more flexible AI integrations.

MCP Core Capabilities

Every MCP server exposes three core building blocks: tools, resources, and prompts. These simple parts make rich interactions possible between clients, servers, and language models. Here’s what each one does:

Tools: The Actions

Tools are the actions your AI can take in the outside world. Think sending a message, running a database query, creating a new ticket, or kicking off a deployment. Each tool is uniquely identified by a name and includes metadata describing its schema. No guesswork, no fragile scripts.

Resources: The Data

Resources are the data or content the AI can access. This could be files from Google Drive, rows from a database, issues from GitHub, or any other information you want your model to see. Resources ground the AI in real context, letting it read, reference, and summarize actual data instead of making things up.

Prompts: The Guidance

Prompts are reusable instructions or templates that steer the AI through more complex tasks. They act like recipes, guiding the model step by step, whether it’s debugging code, filling out a report, or updating CRM records. Good prompts keep the AI focused, consistent, and less likely to go off track.

Not every MCP server uses all three building blocks. Many just focus on tools. What matters is that AI agents can query any MCP server at runtime to see which features are available and use them right away. Each server publishes a catalog, so agents can discover and use new capabilities without changing any code. This is how MCP keeps your workflows flexible and ready for the future.

MCP Adoption

MCP is gaining momentum across the industry. Since Anthropic open-sourced the protocol in November 2024, adoption has moved quickly. Within months, companies like Block, Replit, Windsurf, and Sourcegraph were using it to power new AI workflows and assistants. By spring 2025, OpenAI, Google, and Microsoft had joined in, making MCP a true industry standard.

Today, thousands of MCP servers and connectors are active, with new ones appearing each week. The Model Context Protocol servers repository on Github is the main hub. There you’ll find official reference servers and a growing collection of community-built connectors for Google Drive, Slack, GitHub, databases, cloud services, and more. These projects let AI agents pull files, post messages, run code searches, or automate workflows.

It’s not just Big Tech. Open-source contributors have added servers for tools like Algolia, Chroma, Apify, Sentry, and even for creative services like text-to-speech and image generation. This means your AI agent can already connect to hundreds of real-world apps and data sources without custom code.

With both tech giants and open-source communities building on MCP, the pace is only speeding up. For AI engineers, the message is simple: if your systems are not MCP-ready yet, the ecosystem is growing fast enough to get you there. The sooner your products speak MCP, the sooner you’ll be ready for what comes next in AI.

From API-First to MCP-First

APIs made our products accessible to developers. Now, MCP is making them accessible to AI. API-first thinking still matters, but it only gets you halfway in a world where agentic AI wants to do real work.

Being “MCP-first” means designing your products so AI can use them right out of the box. You provide an MCP server, and suddenly AI assistants, copilots, and bots can plug in.

For instance, Amazon, famous for its API-first culture, is moving toward a true MCP-first approach. The company is adding MCP support to its tools and open-sourcing MCP servers for AWS, making it easy for anyone to get the most out of AWS wherever MCP is used.

Why shift to MCP-first?

• AI as a first-class user: MCP-first products let AI agents use your service as easily as any developer, making your platform accessible in an AI-driven world.

• Faster integration: Enable others to add your service to AI workflows in minutes, not weeks. No more patchwork integrations.

• Future-proofing: With major players on board, one standard connector works everywhere, cutting down on vendor lock-in and plugin friction.

• Smarter products: Expose your features through MCP and let AI automate tasks, create workflows, or combine your product’s strengths with others.

• Easier internal automation: MCP makes it simple for enterprises to connect internal tools and let AI handle busywork, without brittle scripts or shadow IT.

MCP sits alongside your APIs as the standard way for AI to plug into your world. Just as APIs became essential during the mobile and SaaS booms, MCP is now essential for the AI era.

Final Thoughts

The industry learned API-first thinking the hard way. Now MCP is quietly rewriting the rules for the next generation of AI. This isn’t just another protocol; it’s a practical standard that’s already changing how products and teams connect their systems to real intelligence.

Look at the pace of adoption. A handful of reference servers and open-source SDKs has turned into a growing ecosystem, backed by cloud giants and scrappy startups alike. MCP cuts down integration challenges, limits lock-in, and gives AI agents the kind of access that actually gets work done.

If you run a product or engineering team, now’s the time to make your world legible to AI. Treat MCP as a key part of your strategy, not an afterthought. You don’t have to scrap your APIs, but if you want your product to keep up with tomorrow’s agents and workflows, get it MCP-ready.

AI is about to become your sharpest user. MCP makes sure it plays by your rules.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

You ask your AI assistant a question. It confidently returns an outdated answer. The problem? The model was never given access to the latest information.

Large language models are powerful, but they’re not omniscient. They operate within a knowledge boundary: what was baked into their training data, what they’re prompted with, and what they can access in real time. When the answer falls outside that boundary, you hit what I call a knowledge gap.

The good news? You’ve got tools. Three of them: RAG, CAG, and fine-tuning. But they’re not interchangeable. Choosing the wrong one can cost you speed, money, or worse, trust.

Let’s break them down, compare them side by side, and explore real-world use cases to see where each one shines.

RAG: Retrieval-Augmented Generation

Retrieval-Augmented Generation (RAG) works by dynamically retrieving relevant documents at inference time and injecting them into the model’s context.

Unlike basic keyword search, which looks for exact matches, RAG uses vector-based retrieval: it compares the semantic meaning of your question to the meaning of chunks in your knowledge base. Even if the phrasing is different, it can still find relevant content.

Once the most relevant chunks are retrieved, they’re combined with the user query and passed as a single prompt to the LLM. The model then generates a grounded response using both the retrieved content and the original question.

It’s a blend of semantic search and language generation: find the right chunks, let the model explain them.

Here’s how the process typically works:

1. Ingestion: Knowledge sources are loaded and split into smaller chunks using heuristics like headings, sentences, or token limits. This step is done ahead of time and ends once the chunks are indexed. The quality of chunking directly impacts retrieval accuracy later on.

2. Embedding: Each chunk is passed through an embedding model, which transforms the text into dense vector representations (embeddings) that capture semantic meaning. Popular embedding models include OpenAI’s text-embedding-3-small and open source options like all-MiniLM-L6-v2.

3. Indexing: These vectors are stored in a vector database such as Weaviate, Pinecone, Chroma, or PostgreSQL with pgvector. This setup enables fast similarity searches using algorithms like cosine similarity or dot product to efficiently find the most relevant chunks.

4. Querying: When a user asks a question, it is embedded using the same embedding model and compared against the stored vectors to find the most semantically similar chunks. This step happens in real time and determines which pieces of context will be passed to the model for answering.

5. Prompting: The top-ranked chunks are inserted into the LLM’s prompt, enriching the user’s original query with factual, retrieved context. This helps both proprietary models (like ChatGPT, Claude, or Gemini) and open-source ones (like Mistral or LLaMA) generate responses that are more accurate, specific, and grounded in the source material.

This allows the model to answer questions using external knowledge, even if that information wasn’t included in its original training data.

Strengths:

• Well-suited for large, frequently changing knowledge bases

• No model retraining required; update your documents and reindex

• Fast to deploy and relatively easy to maintain with the right tooling

Weaknesses:

• Retrieval failures are silent; irrelevant chunks can slip in undetected

• Adds latency from embedding, vector search, and prompt assembly

• Heavily dependent on chunking quality and search accuracy

Think of RAG as the model using semantic Google. Ask it about “revenue growth,” and it might retrieve chunks discussing “quarterly performance” or “sales trends.” Different words, same idea.

CAG: Cache-Augmented Generation

Cache-Augmented Generation (CAG) preloads a static knowledge base into the model’s internal attention cache (KV cache) and reuses that memory during inference. Instead of embedding and retrieving documents at runtime like RAG, CAG processes and stores them ahead of time. The result is faster, retrieval-free responses.

The approach was introduced in the paper “Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks” as a simpler and faster alternative for use cases where the knowledge is small, stable, and essential. The model doesn’t need to search. It already remembers.

Unlike prompt caching or external memory logs that replay past inputs or outputs, CAG works entirely inside the model. It uses the model’s own attention mechanism to preload documents into memory as key-value pairs. No external systems involved. No retrieval step required.

Here’s how it works:

1. Preloading: A selected set of documents is preprocessed and encoded to fit the model’s context window. These are transformed into attention-level key-value pairs that capture how the model internally interprets them. This cache is saved for reuse.

2. Inference: When the user submits a query, the model reuses the cached knowledge along with the prompt. Because the context is already in memory, it can respond instantly. No need to retrieve, rank, or re-embed.

3. Resetting: As the session evolves, new tokens are added. The model can discard only those recent additions while keeping the original cached knowledge intact, maintaining speed without reprocessing everything.

Strengths:

• Latency is minimal, since the model skips retrieval entirely.

• Responses are highly reliable, with no risk of selecting the wrong chunk.

• Infrastructure is simpler, as there’s no need for vector databases or embedding pipelines.

• Best suited for small, trusted knowledge sets that fit comfortably within the context window.

Weaknesses:

• Context window limitations restrict how much knowledge can be preloaded.

• Updates are manual and infrequent, making it less effective for dynamic domains.

• Only works with models that support long context windows and cache control.

CAG is like photographic memory for models. It sees your documents once, remembers how it interpreted them, and reuses that understanding instantly, without having to look things up again.

Fine-Tuning: Rewriting the Brain

Fine-tuning takes a pretrained language model and continues its training on a specialized dataset. Instead of retrieving knowledge or preloading it, you embed the information directly into the model’s weights. The result is that the model doesn’t just remember your domain—it thinks like it. This changes how it interprets questions, makes decisions, and even writes.

Using supervised learning, you feed the model high-quality examples with both inputs and expected outputs. This allows it to learn domain-specific patterns, terminology, tone, and reasoning. Unlike RAG or CAG, fine-tuning doesn’t depend on the context window or runtime augmentation. Once trained, the knowledge lives inside the model and is always available.

This approach is especially useful when you need deep subject-matter expertise or tight alignment to brand voice, regulatory tone, or unique logic. However, it requires a significant upfront investment in data curation, compute resources, and evaluation.

Here’s how it works:

1. Prepare training data: Collect high-quality examples that reflect the behavior you want. These should include questions and ideal answers, written in the desired tone, style, and domain language.

2. Update the model’s weights: Use supervised training to teach the model from this dataset. Instead of adding information at runtime, you embed it into the model itself by adjusting its internal parameters.

3. Deploy the fine-tuned model: After validation, the model runs independently. It can now respond to domain-specific queries with speed and consistency, without needing prompts or retrieval. The knowledge is built in.

Strengths:

• Fine-tuning integrates knowledge deeply into the model’s behavior.

• Allows the model to recognize and generalize from domain-specific language and workflows.

• You can fully customize tone, output style, and reasoning patterns.

• There are no runtime augmentation steps or limitations from context length.

Weaknesses:

• Fine-tuning requires a large, high-quality dataset to be effective.

• Training and updating the model can be expensive and time-consuming.

• If not done carefully, it may cause the model to forget important general knowledge.

• Once fine-tuned, changes are baked into the model and are difficult to audit, undo, or adapt quickly.

Fine-tuning is like brain surgery for your model. It’s deliberate, precise, and irreversible. It’s the right approach when the problem runs deep, but overkill for surface-level fixes.

Comparing RAG, CAG, and Fine-Tuning

Here’s a quick side-by-side comparison to help you choose the right technique based on speed, flexibility, and complexity.

This table isn’t just a checklist. It’s a reflection of priorities.

RAG gives you flexibility.
CAG gives you velocity.
Fine-tuning gives you accuracy.

Choose the approach that best fits your knowledge needs and how much control you want over the model.

Real-World Use Cases

Let’s ground the theory in practice.

Below are five real-world problems and the techniques that solve them best. This way, you can see how RAG, CAG, and fine-tuning perform when it really matters: on the job.

1. Internal Helpdesk Chatbot

Problem: Employees need instant answers about time-off, expense reports, or device policies. The documents rarely change and fit in a small space.

Best fit: CAG
Preload the docs once, reuse them every time. Low latency, no external retrieval needed. RAG would be overkill. Fine-tuning is unnecessary unless you want the bot to mimic your CEO’s tone.

2. Customer Support Assistant

Problem: You're supporting multiple products with constantly changing documentation. Accuracy matters, and the knowledge base is large.

Best fit: RAG
Retrieves the freshest content at runtime. Updating is as simple as reindexing new docs. CAG would hit context limits. Fine-tuning would be a maintenance nightmare.

3. Specialized Legal Assistant

Problem: The model must understand contracts, statutes, and respond in legally precise language.

Best fit: Fine-tuning
You need the model to reason like a legal expert, not just repeat facts. CAG can't handle the scale. RAG might retrieve irrelevant precedent without deep context understanding.

4. SaaS Sales Assistant

Problem: The model needs to speak in your brand’s tone while pulling current product details, pricing, and offers.

Best fit: Fine-tuning + RAG
Fine-tune for tone and positioning. Use RAG to plug in up-to-date specs. CAG can't scale with constant product updates.

5. Clinical Decision Support

Problem: Doctors need accurate, comprehensive answers based on patient records, treatment guidelines, and drug interactions. They also tend to ask complex follow-up questions during consultations.

Best Fit: RAG + CAG
Use RAG to retrieve the most relevant documents from large medical databases. Then pass those into a long-context model using CAG to create a temporary working memory for each case. This hybrid approach combines breadth, accuracy, and responsiveness, making it well suited for real-time clinical decisions.

The best solutions often blend strengths from each. Choose what fits, and combine when needed.

Final Thoughts: Aligning Solutions with Needs

Large language models are impressive, but they don’t know everything. When answers fall outside their pretraining, you need a strategy to close the gap without breaking the system, or the budget.

RAG, CAG, and fine-tuning offer three distinct paths forward. RAG is versatile and scalable, ideal for fast-moving knowledge. CAG trades flexibility for speed, perfect for stable, high-trust domains. Fine-tuning rewires the model itself, offering precision and deep domain adaptation, at a higher cost.

There’s no universal winner. Your ideal approach depends on how much your knowledge moves, how fast you need answers, and how much control you want over the model’s voice and reasoning.

Need scale? Retrieve it.
Need speed? Cache it.
Need precision? Fine-tune it.

You don’t have to pick just one. The best solution is often a combination.

So next time your model says, “I don’t know,” don’t panic. You have options. Choose the one that fits.

Share

Related Readings

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

Software is changing (again).

If you watched Andrej Karpathy’s “Software in the Age of AI” talk this week, you know exactly what I mean. We’re living through a transformation as fundamental as anything since the birth of programming.

Here’s how the game has changed (and keeps changing at lightning speed):

• Software 1.0: Code drives computers. You wrote every line, and the machine did exactly what you told it. Nothing more, nothing less.

• Software 2.0: Weights drive neural nets. Instead of explicit code, you curated data and trained networks. Programs became collections of parameters, not instructions.

• Software 3.0: Prompts drive LLMs. Your program is now a conversation. You speak in plain English, the LLM interprets, reasons, and builds. Want sentiment analysis? No code, no weights, just a question: “Is this review positive or negative?” The AI answers on the spot.

This isn’t just new syntax. It’s a new way to create, build, and ship products.

So what does it actually take to thrive as a modern AI Engineer in 2025?

Here are the building blocks, leverage, and mindset you need to master.

AI Building Blocks

The essentials AI building blocks you need to build real AI systems.

1. Prompt Engineering

Great AI engineers write more than “good prompts.” They design robust, layered instructions that consistently guide LLMs toward useful, safe, and context-aware outputs. They use context windows, chain-of-thought reasoning, and few-shot examples to get precise results. Prompting isn’t a trick; it’s a new form of system design.

Example: When summarizing dense technical docs, you don’t just ask for a summary. You craft a prompt that splits content, guides the model step by step, and grounds answers in the actual text.

2. Agent & Workflow Orchestration

AI is no longer a single Q&A box. Engineers are wiring up AI Agents: modular bots that remember, reason, and act across multiple steps. Frameworks like LangChain and AutoGen let you chain tools, manage state, and build true AI-driven workflows.

Example: A customer support agent isn’t just a chatbot. It fetches account data, pulls up ticket history, escalates issues, and follows up, autonomously. The engineer orchestrates this, not by reinventing the wheel, but by assembling the right agents and tools.

3. Retrieval-Augmented Generation (RAG)

RAG is how you connect AI to live, fresh data. By plugging in vector databases (like Pinecone, ChromaDB or Supabase), LLMs can search internal wikis, pull current docs, or personalize responses with user data. This makes AI practical, not just clever.

Example: Deploy a financial advice bot that references the latest regulations and client portfolio data in real time. Thanks to RAG, engineers can now achieve that without fine-tuning the base model.

4. Evals & Guardrails

Production AI isn’t a science fair. The best engineers use observability tools and evaluation suites (OpenAI Evals, LangSmith) to catch regressions, monitor drift, and benchmark outputs. Guardrails, such as Rebuff, Guardrails AI or custom scripts, block unsafe or nonsensical answers, protect privacy, and enforce compliance.

Example: If your healthcare AI assistant could give bad advice, you set up red teams, test for dangerous outputs, and wire in automatic filters. Safety isn’t an add-on; it’s built-in.

5. Model Context Protocol (MCP)

Stacks change fast, and models are evolving by the month. The Model Context Protocol (MCP) acts as the “USB-C for AI systems”: a universal connector for swapping in new LLMs, tools, or data sources without breaking your workflows. It’s plug-and-play for the AI age, not rip-and-rewrite.

Example: With an MCP server, your AI agent can securely access and update Linear issues, projects, and comments, all through a single standardized interface with no custom integrations required.

AI Leverage

The smartest engineers don’t just use AI to build products. They use AI to accelerate their own work. The single biggest productivity breakthrough today? AI coding tools.

AI Coding Tools

AI coding tools have rapidly evolved from simple autocompletion to full-on engineering accelerators. What started with GitHub Copilot now includes a new generation of platforms like Cursor, Windsurf, and agentic assistants such as Anthropic’s Claude Code and OpenAI’s Codex.

These tools don’t just finish your sentences; they draft entire modules, generate and update tests, refactor code, and spot logic bugs in real time. The best of them can debug, iterate, and even suggest architecture improvements, freeing engineers to focus on the bigger picture.

The real power emerges when skilled engineers combine these tools with deep product sense and strong fundamentals. AI coding tools take care of the repetitive and mechanical tasks, while you handle design choices, architectural strategy, and customer value. This partnership radically shortens the gap from idea to working software.

Example: Need to launch a new service? Instead of building every layer by hand, you prompt Claude Code or Cursor to scaffold the backend, generate tests, and troubleshoot errors, so you spend less time fighting syntax and more time solving real user problems. In a world where speed is everything, those who master AI coding tools move from prototype to production at a pace the old guard can’t match.

One caveat: this space is evolving at breakneck speed. What was cutting-edge last year is table stakes now. To stay ahead, you need to keep a close eye on the latest releases because every new iteration brings smarter, faster, and more capable coding partners.

AI Mindset

How you need to think to win, adapt, and lead in the age of AI.

Product Instinct

You do not just build features. You build solutions people actually want. You thrive in ambiguity, rapidly prototype, and obsess over real-world feedback. The difference between an impressive demo and a beloved product is clear to you, and you always close the gap thanks to your product mindset and business sense.

Example: You notice users are dropping off during onboarding. You simplify the process, collect feedback, and keep iterating until new users stay and succeed.

High Agency

You own outcomes. If something is broken, you fix it. You do not wait for instructions or permission. You take action, drive alignment, and make progress. That’s high agency in action.

Example: A key API fails just before launch. Instead of waiting for someone else to step in, you investigate, patch the issue, and update the team before anyone else asks.

Relentless Learning

AI moves faster than any tech before it. You make curiosity a habit, chase new releases, read papers, and experiment beyond your comfort zone.

Example: A new, more powerful LLM framework drops. You dive into the docs, run your own benchmarks, and quickly figure out how to use it to speed up your next project.

Adaptability

Yesterday’s playbook will get you left behind. You unlearn as fast as you learn. You are ready to pivot when best practices shift. Comfort is the enemy of progress. In the era of AI, adaptability is key to thrive.

Example: Your team’s go-to library is suddenly deprecated. You research alternatives, help your team migrate, and turn a disruption into an upgrade.

Ethical Awareness

With AI, your work shapes real lives. You draw clear boundaries, think hard about consequences, and hold yourself and your systems to a higher standard.

Example: Before rolling out a new AI-powered feature, you test for bias and privacy risks, raise concerns, and make changes so your product is safe and fair.

Final Thoughts: Thriving as an AI Engineer

Software is changing fast, and so is what it takes to succeed. Becoming an AI engineer is not about collecting tools or chasing hype. It is about mastering the building blocks, using leverage to multiply your impact, and sharpening a mindset that lets you lead and adapt.

The pace of change will only accelerate. Today’s innovation will be tomorrow’s standard. The engineers who stand out are the ones who keep learning, adapt quickly, and focus on delivering real value.

AI will keep raising the bar, but it will also keep expanding what is possible. If you master the fundamentals, make the most of AI coding tools, and stay focused on growth, you will not just keep up. You will help shape what comes next.

The edge belongs to those who build, learn, and lead. Stay sharp. Set the pace, and thrive.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

Monolith or microservices?

Ask any technical leader and you’ll hear passionate arguments for both. After working at three fast-growing startups that became unicorns in no time, I’ve learned this: most successful products begin as monoliths. Starting with a monolith is usually the right call, at least until growth forces your hand.

But once your product takes off, everything shifts. One day you’re building a new API. The next, your API is melting down under a tidal wave of signups you didn’t see coming. Growth brings new problems: performance issues, slow build times, tightly coupled code, and engineers tripping over each other in the same codebase.

The usual advice? Split everything into microservices. But before you hire an army of SREs and watch your Series A or B funding vanish into your AWS bill, consider another option: the modular monolith.

What is a Modular Monolith?

A modular monolith is a single application organized into clear, self-contained modules, each focused on a distinct part of the business. These modules have well-defined boundaries, explicit responsibilities, and communicate through intentional interfaces. Everything runs and is deployed together, but the internal structure is clean and deliberate. This approach helps keep complexity under control as your codebase grows.

The Architectural Spectrum

Think of modular monoliths as the middle ground between the two extremes most teams debate:

• Classic Monolith: Everything tightly coupled, all code intertwined. Changes in one area can break another.

• Modular Monolith: One deployable app, but with clear module boundaries and minimal dependencies between them.

• Microservices: Each business capability in its own independent service, running as a separate process, often with its own database.

A City, Not a Maze

Think of your system as a city. At first, it’s a bustling town square: everyone is packed into the same space, sharing roads and utilities.

As the city grows, you carve out neighborhoods, each with its own vibe and borders. Everyone still lives within the same city limits, but life becomes more organized and manageable.

Eventually, some neighborhoods grow large enough to become their own towns with separate city halls and infrastructure.

That’s how engineering teams evolve: from a simple monolith, to a modular monolith, and finally to a microservices architecture.

Pros and Cons of Modular Monoliths

Building a modular monolith is a popular choice for teams seeking structure and agility without diving headfirst into the complexity of microservices. But like any architectural decision, it comes with its own set of trade-offs. Let’s take a clear-eyed look at both sides.

Pros

1. Simple Deployment: You ship everything as a single unit. No juggling dozens of deployment pipelines or keeping service versions in sync.

2. Clearer Code Organization: Modules bring structure and discipline. Teams can work on different business areas without stepping on each other’s toes.

3. Easier Refactoring: Need to make a sweeping change? Internal module boundaries are easier to shift than a constellation of microservices.

4. Lower Operational Overhead: One runtime, one set of logs, one monitoring setup. You avoid the overhead of running a distributed system.

5. Natural Path to Microservices: If you ever need to split out a module, the clear boundaries you set today make tomorrow’s migration less painful.

Cons

1. Difficult to Define Module Boundaries: Getting boundaries right is hard. It often takes several iterations and real-world use before your modules feel natural. Shifting these lines later can be disruptive.

2. Performance Overhead: Isolating modules can mean more API calls and less efficient data access. Without careful design, what used to be a fast database query can become a slow, chatty operation.

3. Limited Scalability and Deployment Flexibility: Since everything is deployed as a single unit, you can’t scale or deploy modules independently. When certain parts of your system outgrow the rest, you may eventually hit a wall.

Modular monoliths offer a practical blend of structure and simplicity, giving you many of the benefits of microservices without the early complexity or cost. As with any software architecture or system design, long-term success depends on discipline, clarity, and knowing when to adapt.

Designing a Modular Monolith

Designing a modular monolith isn’t just about splitting code into folders. It takes intention, discipline, and smart strategies to keep your system manageable and ready for the future. Let’s break it down into three critical areas: boundaries, communication, and data.

Modules Definition: Drawing the Right Boundaries

Getting boundaries right is everything. Start with your business domains. Use Domain-Driven Design (DDD) techniques to map each core business capability to its own module. For example, keep billing, user management, and inventory as separate units, not simply as technical layers.

Avoid the temptation to cut corners. Each module should own its functionality end to end, including data, logic, and interfaces. The closer your modules reflect real-world business boundaries, the healthier your system will be as it grows.

Review boundaries regularly. As your understanding deepens or requirements shift, do not hesitate to refactor and move responsibilities around. It is better to evolve early than to let messy boundaries fester.

Communication Strategies: Letting Modules Talk

How modules communicate matters. There are two main approaches:

1. Synchronous Communication: Module API Calls
   Modules usually call each other’s functions or methods directly within the same application, using in-process APIs or service interfaces instead of network or REST calls. This is simple and gives immediate responses, but it can increase coupling and make error handling harder as dependencies grow.

2. Asynchronous Communication: Internal Event Bus
   Modules can also use an internal event bus that works within the same application, often in-memory. Examples include Node.js EventEmitter, .NET’s MediatR, or Phoenix.PubSub in Elixir. This adds flexibility, since modules can publish and listen for events independently, but it can make debugging and ensuring consistency more difficult.

Choose your strategy based on the needs of each interaction. In practice, most modular monoliths use a mix of both.

Data Isolation: Deciding on Database Architecture

Data ownership is a cornerstone of good modular design. Your choices here affect maintainability, scalability, and how easily you can move to microservices in the future.

There are several levels of data isolation, each with increasing complexity and cost:

1. Separate Tables: Each module owns its own tables in a shared database. This is the simplest and least costly approach, but there’s still a risk of accidental cross-module queries.

2. Separate Schemas: Each module gets its own database schema. This creates stronger boundaries, helps prevent data leaks, and simplifies migrations, though it adds some overhead compared to shared tables.

3. Separate Databases: For maximum isolation, give each module a dedicated database. This approach significantly increases operational complexity, but makes it much easier to extract modules to microservices later.

4. Different Persistence Technologies: Some modules may benefit from specialized data stores such as key-value, time-series, or document databases. Using the best technology for each module is fine, as long as you keep boundaries clear and avoid coupling through the database.

Pick the level of isolation that fits your team’s size, maturity, and future plans. The more isolation you build in now, the easier it will be to extract modules later.

When (and When Not) to Use a Modular Monolith

Modular monoliths aren’t a universal solution, but for many projects they hit the sweet spot between chaos and complexity. The trick is knowing when they’re a good fit, and when it’s time to look elsewhere.

When to Consider a Modular Monolith

1. Your Domain Is Too Complex for a Classic Monolith: If your business logic sprawls across multiple concerns and teams keep bumping into each other, a simple monolithic codebase won’t scale. Modular monoliths help organize and manage that complexity.

2. You Have Multiple Teams Working on the Solution: As soon as you have several teams, modularity helps avoid merge chaos, code collisions, and ownership confusion. Teams can move faster and actually take responsibility for their modules.

3. You Want an Evolutionary Path Toward Microservices: If you think microservices might be in your future but don’t want the pain and overhead today, start modular. Building a well-structured modular monolith gives you the flexibility to evolve and split out services when you really need to.

When to Rethink Using a Modular Monolith

1. You Need Independent Scaling or Deployments Now: If parts of your system must scale or deploy independently right away, a single deployable unit will get in your way.

2. You Have a Polyglot Tech Stack or Specialized Persistence Needs: If your domains demand different programming languages or databases, trying to force them all into one app adds unnecessary friction.

3. You Already Have Mature, Well-Defined Boundaries: If your domains are stable, teams are fully autonomous, and boundaries are set in stone, jumping directly to microservices may make sense.

Modular monoliths offer clarity, structure, and a natural path to growth. You avoid operational overhead until you truly need it.

From Modular Monolith to Microservices

No architecture lasts forever. Even the best modular monolith can outgrow itself. The good news: if you’ve built strong boundaries and discipline into your modules, migrating to microservices is far less daunting.

Signs It’s Time to Split the Monolith

• Bottlenecks and Slow Deployments: Teams are waiting on each other to ship changes, and deployments feel risky.

• Scaling Challenges: One part of your app is struggling under heavy load, but you can’t scale it independently.

• Team Autonomy: Teams want to move at their own pace, deploy on their own schedule, or experiment with new technologies.

• Reliability and Isolation: A bug or outage in one domain can bring down the entire system or create undesirable side effects.

How to Extract Modules Into Services

1. Pick a Candidate Module: Start with a well-defined module that has clear responsibilities and stands out as a good candidate for extraction. This is often the largest or most complex module, like Module C in the first diagram. Prioritizing the most critical module delivers the biggest impact and helps validate your migration process.

2. Decouple Communication: Change internal module calls to explicit REST APIs or event-driven patterns. After extraction, the new service (Service C) exposes its own API and interacts with the system through REST or a distributed event bus. At this point, the event bus is external and is often referred to as a message broker or streaming platform. Technologies like Kafka, RabbitMQ, or NATS support communication between independently deployed services.

3. Migrate Data Ownership: Move the module’s data to its own storage. In the diagram, Service C manages its data in a dedicated NoSQL database, such as MongoDB or DynamoDB. The other modules continue using the original SQL database, like PostgreSQL or MySQL, each with its own schema. This separation lets each service choose the database that best fits its needs.

4. Set Up Separate Deployment: Deploy the new service independently, giving it its own runtime, deployment pipeline, and monitoring. This allows you to update and scale the service separately, while the rest of the monolith continues to run as before.

5. Iterate Gradually: Migrate modules in small, deliberate steps rather than all at once. Use lessons from your first extraction to improve future migrations. Let actual pain points and business priorities guide which modules become services next. This approach reduces risk and helps your architecture evolve naturally alongside your team.

A modular monolith is not a dead end; it is a launchpad. The better you design today, the less painful migration will be tomorrow. Take it one step at a time, and let business needs, not hype, set the pace.

Best Practices and Common Pitfalls

A modular monolith thrives on discipline and clarity. Done well, it delivers years of maintainability. Take shortcuts, and you’re back to a tangled mess. Here’s how to get it right, and the traps to avoid.

Best Practices

• Enforce Real Module Boundaries: Use strong interfaces and keep shared code to a minimum. Regularly review dependencies to spot and eliminate accidental coupling. Tools like Boundary for Elixir and Packwerk for Ruby can help enforce modular boundaries automatically.

• Document and Communicate: Every module should have clear documentation and an explicit owner. Make sure all teams understand how modules interact and where responsibilities begin and end. Use CODEOWNERS files to assign explicit owners to modules, directories, or files.

• Visualize and Monitor Complexity: Use module dependency graph tools like Madge for JavaScript/TypeScript or SonarQube for multiple languages to see how your modules interact. If you notice too many dependencies pointing to a single module, it’s a sign to revisit your boundaries and keep the architecture healthy.

Common Pitfalls

• Making Modules Too Small: Splitting code into tiny pieces adds overhead and confusion. The solution? Use Bounded Contexts. Each module should represent a meaningful business capability.

• Teams Not Prioritizing the Work: Modularization or migration only succeeds when every team is actively involved and committed. If teams aren’t engaged or don’t see this work as a priority, the effort will stall.

• No Leadership Buy-in: Without real commitment from senior leadership, modularization will eventually halt. This work often means prioritizing technical changes over new features, at least temporarily. If leadership isn’t on board, wait.

A bit of structure, shared understanding, and honest measurement will keep your modular monolith clean, and ready for whatever comes next.

Real-World Modular Monoliths

You don’t have to take this on faith. Some of the world’s most successful tech companies have embraced the modular monolith pattern to balance growth and maintainability. Here are three popular ones.

Shopify

Shopify runs a massive Rails-based monolith with over 2.8 million lines of Ruby and 500,000 commits as of September 2020. The codebase is carved into modular “components” to manage complexity and accelerate delivery. The team enforces clear boundaries, enables selective testing, and streamlines onboarding.

Basecamp

Basecamp champions the “majestic monolith” since 2003, organizing its codebase by feature and responsibility, resisting distributed systems until truly necessary. Their philosophy keeps abstractions minimal and architecture clear, as detailed by DHH in “The Majestic Monolith”.

GitLab

GitLab maintains a modular monolith containing over 2.2 million lines of code. They’re actively modularizing it using tools like Packwerk to define bounded contexts, enforce boundaries, and prepare for future service extraction. This disciplined architecture boosts engineer productivity, enhances code clarity, and enables gradual decoupling.

If modular monoliths can work for companies at this scale, there’s a good chance they can work for you.

Final Thoughts: Build for Today, Plan for Tomorrow

Software architecture decisions are often less certain than we admit. Modular monoliths show that simple, disciplined solutions can be more effective than chasing trends. They help teams manage complexity, organize code, and focus on delivering real value instead of hype.

Every system grows and changes in ways you can’t fully predict. The most resilient architectures leave space for learning and adaptation. Modular monoliths let you build something strong today while keeping options open for tomorrow.

In the end, good architecture is less about grand plans and more about everyday discipline. It comes down to how your team communicates, how often you revisit boundaries, and how you handle the small decisions that add up over time.

If your system feels unwieldy, you may not need to start over. You might just need clearer boundaries, better habits, and the patience to improve things one step at a time.

Build with intention. Refactor with care. Your future self and your team will thank you.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

Impressive? Sure. Transformative? Not really. Answers alone do not drive change.

Now imagine this: An AI that keeps the conversation alive. It asks clarifying questions. It remembers last week’s blockers. It nudges you toward the next step. That’s not a chatbot. That’s an AI agent.

In this article, I’ll show you exactly what Agentic AI is, how it works, and how you can build your own agent from scratch, fast.

What Is Agentic AI?

Agentic AI is artificial intelligence that acts on its own. It can make decisions, adapt to changes, and pursue goals with minimal human input. Instead of just responding to commands, it takes initiative, solves problems, and learns from experience.

Think of it as AI with agency. Traditional chatbots wait for prompts. An agent, by contrast, can observe a situation, set its own internal goals, and take steps toward those goals without needing to be micromanaged.

Put simply, Agentic AI is autonomy with purpose. It can:

• Act with intention rather than wait passively for user input

• Perceive and adapt by asking follow-up questions, clarifying vague instructions, or suggesting next steps

• Problem-solve within boundaries and tools you define, choosing its own tactics

• Persist through loops until it considers the task complete

Here’s a mental shortcut:

Autonomy tells the AI it may act.
Agency tells the AI it should act toward a clear objective.

Contrast that with a standard LLM exchange:

User: “I want to be a better delegator.”
ChatGPT: “Here are five tips.”

An AI agent digs deeper:

Agent: “What part of delegation feels hardest right now?”
User: “I worry tasks won’t meet my standards.”
Agent: “Describe a recent example when this worry became reality.”
(The loop continues until a concrete plan emerges.)

Most LLMs respond once and stop. Agents don’t stop until the job is done.

The Agent Loop

The secret sauce that turns a one‑off chatbot into an autonomous helper is a simple, repeatable cycle known as the agent loop. In practice each turn of the loop covers six steps:

1. Construct the prompt: Combine the current goal, any tool descriptions, and recent feedback into a single prompt string.

2. Query the LLM: Send the prompt to your model of choice and receive a structured response.

3. Parse the response: Extract the action in a machine‑readable form: for example an API name plus arguments.

4. Execute the action: Call the API or any other tool, run code, or perform whatever real‑world step the agent selected.

5. Capture feedback: Get the results from the action taken, which could include success messages, error codes, or data.

6. Decide to continue or end: Based on the feedback, determine whether to continue the loop (a new prompt) or to end the process.

A few practical tips:

• Give the agent clear tool choices: (“You may call clarify, teach, evaluate, or finish”). Clear options make parsing trivial.

• Store only what matters: Memory grows every loop; trim or summarise older steps to keep token costs low.

• Stay in charge: Your outer loop controls when to break, throttle, or sandbox actions. The agent suggests; your code decides.

Master this pattern and you can bolt an LLM onto almost any workflow, from spreadsheet updates to expense processing to leadership coaching.

Prompts and Memory

To turn a language model into an agent, you need to automate two things:

1. Prompting programmatically: Instead of a person typing questions and reading answers, your code handles the conversation loop. It builds prompts from context, sends them to the model, parses responses, and decides what to do next.

2. Managing memory explicitly: Language models don’t remember past calls. You must give them memory by resending important context each turn, and deciding what’s worth including.

Prompting in Practice

An agent's prompt is more than a static instruction. It's a growing conversation that evolves with every turn. Each message is labeled by a role to guide how the model understands and responds:

• system: Sets the rules for the AI. It defines the model's behavior, tone, and boundaries. You use it to tell the AI how it should act.

• user: Represents everything the human says. This includes questions, goals, clarifications, and answers.

• assistant: Captures what the AI said in the previous message. It keeps the conversation coherent and helps the model stay consistent.

These roles form the structure of the agent's memory. They allow the AI to track context, follow up intelligently, and make informed decisions with each interaction.

Here’s an example:

<system>
You are a leadership mentor. 
<user>
I want to be a better delegator. 
<assistant>
What part of delegation feels hardest right now? 
<user>
I worry tasks won’t meet my standards.

Each step adds to the thread. Your agent appends a user message, calls the model, then appends the assistant’s reply, and repeats.

To keep this loop working:

• Keep prompts concise and structured.

• Use consistent message roles (system, user, assistant).

• Trim the history when it gets too long.

Managing Memory

Most agents rely on two types of memory:

• Conversation memory holds the recent message history. This is what you resend to the model on each turn to maintain context and continuity.

• Code-level state stores important internal values the model doesn’t need to see. This might include things like raw API responses, counters, or scores.

A typical way to maintain conversation memory looks like this:

self.memory.append({"role": "assistant", "content": response_content})
full_prompt.extend(self.memory)

This pattern keeps the prompt grounded in the full interaction history, allowing the agent to make decisions based on everything said so far.

Building the Mentor Agent in Python

I’ve been tinkering with AI agents lately, and I wanted to show you how to build one from scratch using Python, LiteLLM, and Google Colab.

Why These Tools?

• Google Colab: Zero setup. Just open a notebook and run. Perfect for sharing experiments or workshops.

• LiteLLM: A clean wrapper that lets you talk to GPT-4o (or other models) with minimal boilerplate. Great for building agents quickly.

• Python: The lingua franca of AI. Enough said.

Let’s walk through the setup.

Step 1: Set Up Your Environment

Let’s start with the basics, installing the right library and loading your API key securely:

!pip install litellm --quiet

import os
import json
from litellm import completion
from google.colab import userdata

In this project, I’m using OpenAI’s GPT-4o via API. But thanks to LiteLLM, you can swap in other providers like Anthropic, Google Gemini, Mistral, or even local models.

To follow along with OpenAI, get your API key from platform.openai.com and securely store it in Colab.

To securely store your API keys in Google Colab, use the Secrets tab in the left sidebar. This allows you to save sensitive values like API keys without hardcoding them into your notebook.

Once stored, you can access them in code like this:

api_key = userdata.get("OPENAI_API_KEY")
os.environ["OPENAI_API_KEY"] = api_key

This keeps your secrets safe, avoids exposing them in shared notebooks, and works seamlessly across sessions. No need to call set() in the notebook, just manage them through the UI.

Step 2: Configure the Agent (Role, Memory, Tools)

We’re not building a chatbot or a coder. We’re building a mentor. That means we need to be explicit about how it should behave.

In this step, we define the agent’s goal, initialize its memory, register its tools and, most importantly, set its role as a leadership mentor. This gives the model clear boundaries and purpose from the very start.

class LeadershipMentorAgent:
    """
    A simple AI Agent that acts as a leadership mentor.
    """
    def __init__(self, goal):
        """
        Initializes the agent with a goal, memory, and a set of tools.
        """
        self.goal = goal
        self.memory = []
        self.max_loops = 10 # Set a maximum number of interactions
        # A registry of available "mentoring" tools for the agent.
        self.tools = {
            "clarify": {
                "function": self.clarify,
                "description": "Asks the user a question to get more details about their goal. Use this if the goal is vague.",
                "args": {"question": "The clarifying question to ask the user (string)."}
            },
            "teach": {
                "function": self.teach,
                "description": "Explains a leadership concept, theory, or strategy to the user. Use this to provide knowledge.",
                "args": {"concept": "The concept to explain (string)."}
            },
            "evaluate": {
                "function": self.evaluate,
                "description": "Asks the user a question to see if they understood a concept. Use this to check for comprehension.",
                "args": {"question": "The question to evaluate understanding (string)."}
            },
            "finish": {
                "function": self.finish,
                "description": "Ends the mentoring session with a summary or concluding remarks.",
                "args": {"summary": "A final message for the user (string)."}
            }
        }

    # These functions define the agent's "actions". They interact with the user via the console.
    def clarify(self, question: str) -> str:
        """Asks the user for more information."""
        print(f"🤖 Mentor: {question}")
        user_response = input("You: ")
        return f"User's response: '{user_response}'"

    def teach(self, concept: str) -> str:
        """Explains a concept to the user."""
        # In a real app, you might fetch this from a knowledge base.
        print(f"🤖 Mentor: Let's talk about '{concept}'. A key aspect of this is...")
        # Mock explanation
        if "feedback" in concept.lower():
            print("Effective feedback is specific, actionable, and delivered with empathy. It focuses on behavior, not personality.")
        else:
            print("It's important for a leader to understand this principle to guide their team effectively.")
        return "Concept explained."

    def evaluate(self, question: str) -> str:
        """Checks if the user understood the concept."""
        print(f"🤖 Mentor: {question}")
        user_response = input("You: ")
        return f"User's response to evaluation: '{user_response}'"

    def finish(self, summary: str) -> str:
        """Ends the conversation."""
        print(f"🤖 Mentor: {summary}")
        return "Session concluded."

    def _construct_prompt(self) -> list[dict]:
        """
        Constructs the prompt for the LLM with instructions, tools, and history.
        """
        # The system prompt defines the agent's persona and logic.
        system_prompt = f"""
        You are an AI Leadership Mentor. Your purpose is to help the user with their goal: "{self.goal}".
        You will guide them by asking questions, teaching concepts, and evaluating their understanding.

        You have access to the following tools:
        {json.dumps(self.tools, indent=2, default=lambda o: o.__doc__)}

        Follow this thought process:
        1.  Start by understanding the user's goal. If it's unclear, use 'clarify'.
        2.  Based on their goal, use 'teach' to explain a relevant leadership skill.
        3.  After teaching, use 'evaluate' to check if they grasped the concept.
        4.  Based on their responses, decide the next step. Either teach a new concept or continue clarifying.
        5.  When the user's initial goal has been addressed, use 'finish' to end the conversation.
        6.  Your responses MUST be in a valid JSON format.

        Example of a tool-using response:
        {{
            "action": "teach",
            "args": {{"concept": "Giving constructive feedback"}}
        }}

        Example of a concluding response:
        {{
            "action": "finish",
            "args": {{"summary": "Great work today! We've covered the basics of feedback."}}
        }}
        """

        full_prompt = [{"role": "system", "content": system_prompt}]
        full_prompt.extend(self.memory)
        # Add the goal as the first user message if memory is empty
        if not self.memory:
            full_prompt.append({"role": "user", "content": f"My leadership goal is: {self.goal}"})

        return full_prompt

Step 3: Implement the Mentor Agent Loop

Now the agent comes to life. This isn’t just a one-off prompt and response. It’s an interactive, iterative session, guided by the agent loop we described earlier:

Prompt → LLM → Response → Action → Feedback → Completed?

But this time, the loop is tailored for mentorship. Each turn, the agent:

1. Revisits the user’s leadership goal

2. Decides whether to clarify, teach, or evaluate based on the current context

3. Interacts directly with the user through the console, making the session feel personal

4. Captures feedback after each action to inform its next decision

5. Concludes with a final summary once the goal has been addressed or the session is complete

This structure gives the agent just enough autonomy to feel thoughtful, while keeping it grounded in the mentoring role you defined.

Here’s the full loop that powers the experience:

    def run(self):
        """
        The main agent loop for the mentoring session.
        """
        print(f"🎯 Mentor Agent activated. Goal: {self.goal}\n")
        loop_count = 0
        while loop_count < self.max_loops:
            loop_count += 1
            print(f"--- Interaction {loop_count}/{self.max_loops} ---")

            # 1. Construct the prompt
            prompt = self._construct_prompt()

            # 2. Query the LLM for the next action
            print("🤔 Mentor is thinking...")
            try:
                response = completion(
                    model="gpt-4o", # Using a more capable model for nuanced tasks
                    messages=prompt,
                    temperature=0.7,
                    max_tokens=512
                )
                response_content = response.choices[0].message.content.strip()
            except Exception as e:
                print(f"An error occurred with the LLM call: {e}")
                break

            self.memory.append({"role": "assistant", "content": response_content})

            # 3. Parse the LLM's response
            try:
                parsed_response = json.loads(response_content)
                print(f"✅ Mentor's decided action: {parsed_response['action']}")
            except (json.JSONDecodeError, KeyError):
                print(f"🚨 Error: Invalid JSON from LLM: {response_content}")
                feedback = "Invalid response format. Please use the 'action' key in a JSON object."
                self.memory.append({"role": "system", "content": f"Feedback: {feedback}"})
                continue

            # 4. Execute the chosen action
            action_name = parsed_response.get("action")
            action_args = parsed_response.get("args", {})

            if action_name in self.tools:
                tool_function = self.tools[action_name]["function"]
                try:
                    result = tool_function(**action_args)
                    # 5. Capture feedback for the next loop
                    feedback = f"The user's response was: '{result}'"
                    print(f"🔧 Feedback captured.\n")
                    self.memory.append({"role": "system", "content": f"Feedback: {feedback}"})

                    # 6. Decide to continue or end
                    if action_name == "finish":
                        print("\n🏁 Mentor session has ended.")
                        break
                except Exception as e:
                    print(f"Error executing tool '{action_name}': {e}")
                    break
            else:
                feedback = f"Unknown tool '{action_name}'. Please choose from available tools."
                self.memory.append({"role": "system", "content": f"Feedback: {feedback}"})

        if loop_count >= self.max_loops:
            print("\n⚠️ Mentor reached maximum interactions. Ending session.")

Step 4: Start the Mentoring Session

Once everything is in place, just run the script to launch your mentoring session:

if __name__ == "__main__":
    try:
        user_goal = input("Welcome! What leadership goal would you like to work on today?\nYou: ")
        if user_goal:
            agent = LeadershipMentorAgent(goal=user_goal)
            agent.run()
        else:
            print("No goal provided. Exiting.")
    except KeyboardInterrupt:
        print("\nProcess interrupted by user. Exiting.")

The agent will greet you, ask for your leadership goal, and guide you through a structured session. It will clarify your intent, teach relevant concepts, evaluate your understanding, and help you plan one concrete next step.

You can go through multiple rounds until your goal is addressed or the session ends naturally.

You can view the full AI agent code on GitHub:
→ github.com/rafapaez/leadership-mentor-agent

Step 5: See It in Action

Now that everything’s wired up, here’s how the agent performs in a real session. This sample shows how it clarifies your goal, teaches key concepts, and responds dynamically based on your input:

Welcome! What leadership goal would you like to work on today?
You: time management
🎯 Mentor Agent activated. Goal: time management

--- Interaction 1/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: clarify
🤖 Mentor: Can you describe a specific time management challenge you are facing in your leadership role?
You: to many interruptions
🔧 Feedback captured.

--- Interaction 2/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: teach
🤖 Mentor: Let's talk about 'The concept of time blocking, a method where you allocate specific chunks of time for different activities, and set boundaries to minimize interruptions.'. A key aspect of this is...
It's important for a leader to understand this principle to guide their team effectively.
🔧 Feedback captured.

--- Interaction 3/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: evaluate
🤖 Mentor: How would you use time blocking to manage interruptions during your day?
You: I'll start blocking focus time slots
🔧 Feedback captured.

--- Interaction 4/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: teach
🤖 Mentor: Let's talk about 'The concept of setting boundaries and communicating your schedule to your team or colleagues, which involves letting them know about your focus times and the best times to approach you for discussions or questions.'. A key aspect of this is...
It's important for a leader to understand this principle to guide their team effectively.
🔧 Feedback captured.

--- Interaction 5/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: evaluate
🤖 Mentor: How will you communicate your focus times to your team to help manage interruptions?
You: I'll be transparent with my availability
🔧 Feedback captured.

--- Interaction 6/10 ---
🤔 Mentor is thinking...
✅ Mentor's decided action: finish
🤖 Mentor: Great progress! By using time blocking and communicating your focus times transparently, you can effectively manage interruptions. Keep implementing these strategies to improve your time management.
🔧 Feedback captured.


🏁 Mentor session has ended.

You can continue the session for multiple rounds until the agent decides the goal has been addressed, or you stop it manually.

Final Thoughts: Stop Reading, Start Building

Reading about agents is useful. Building one changes how you think.

You’ve now seen a real agent loop. Not a toy, not a slide deck example. Just a clear goal, a handful of tools, and a bit of logic to let the model lead with purpose.

The Leadership Mentor Agent isn’t perfect. But it’s real. It clarifies, teaches, and adapts. You can fork it, remix it, and ship something better this afternoon.

This isn’t about theory. It’s about practice. Stop scrolling. Open your editor. Build your agent.

Not just to write code, but to build something that collaborates. Guides. Mentors.

That future isn’t far off. You just started it.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

The startup was finally taking off. Then the platform went down.

PostgreSQL deadlocks piled up. A reconciliation procedure had locked key tables for too long. The code was fine.

The architecture was not.

This wasn’t just a technical hiccup. It was an expensive outage.

And it could have been avoided with better system design thinking, especially at the leadership level.

Today, system design is no longer a “nice-to-have” for engineering leaders. It’s the foundation for scaling your team, making sound decisions, and avoiding the kind of silent risks that later explode in production.

In this post, I’ll walk you through the fundamentals of system design. Not to turn you into an architect, but to help you ask sharper questions, spot red flags earlier, and lead with clarity and confidence.

Part 1: Master the Fundamentals

What Is System Design, Really?

System design is the art of architecting software that not only works, but also scales, stays reliable, and evolves over time.

It’s not about fancy diagrams. It’s about trade-offs. Constraints. Long-term thinking. Leadership.

Why Should You Care?

Because every roadmap decision hides a system design decision.

Ship a “simple” feature without understanding system load or latency impact? You’ll find out the hard way in production.

Design isn’t a technical afterthought. It’s a strategic, organizational bet.

Core System Design Principles: The SPARCS Framework

Every scalable system relies on six core principles. Together, they form the acronym SPARCS:

Scalability

Can the system grow with your users and data?

Think in two dimensions: horizontal scalability (adding more machines) and vertical scalability (upgrading existing resources). Poor scalability creates bottlenecks that limit your growth.

Performance

Is the system fast enough under real-world conditions?

Performance depends on smart load balancing, efficient caching, algorithmic choices, and reducing latency at every layer. Sluggish systems erode user trust and hurt conversions.

Availability

Will the system be up when users need it?

Even short outages can have real impact. High availability requires monitoring, failover mechanisms, redundancy, and a clear understanding of your “nines” (e.g. 99.9% uptime = 8.7 hours of downtime per year).

Reliability

Does the system behave correctly over time, even when things go wrong?

Reliability is about correctness under pressure. This includes redundancy, graceful degradation, retries, and fault-tolerant design that protects critical paths.

Consistency

Is the data accurate and up to date across all parts of the system?

In distributed systems, consistency is tricky. The CAP Theorem reminds us that in the presence of a network partition, we must choose between consistency and availability. Choose the model: strong, eventual, or something in between, that fits your use case.

Security

Is the system protected against threats, misuse, and data leaks?

Good security is layered. It includes HTTPS or SSL/TLS for encrypted communication, firewalls to limit exposure, access controls like RBAC (Role-Based Access Control), and secure handling of credentials. One breach can destroy user trust and derail your product.

Leadership takeaway: You don’t need to master every dimension. But you do need to ask: “Which qualities matter most for this system, right now?”

Part 2: Map the Building Blocks

Think of modern systems like cities. Your job isn’t to know every street. It’s to understand the map.

As a leader, you don’t need to design every component but you do need to recognize the critical layers, ask the right questions, and ensure there’s clear ownership.

Here are the building blocks that matter most:

The Front Door

• Clients (Web, Mobile):
  The user’s first interaction with your system. Page load speed, offline support, and responsiveness all start here.
  Examples: React, Flutter, Next.js, Android/iOS SDKs

• API Gateway or Load Balancer:
  Routes and secures traffic. It hides your internal topology, enforces authentication, and distributes load across healthy instances. If this fails, your system becomes unreachable.
  Examples: AWS API Gateway, NGINX, HAProxy, Kong

Stateless Compute

• App Servers:
  Handle business logic and scale horizontally by design. Just make sure they don’t rely on local state or file storage.
  Examples: Node.js with Express, Spring Boot, Django, Ruby on Rails, Phoenix (Elixir)

• Containers:

  Package applications and their dependencies for consistent deployment across environments.

  Examples: Docker, contarinerd. Typically orchestrated with Kubernetes, Amazon ECS, or Nomad for scalability and automation.

• Serverless Functions:
  Great for bursty, unpredictable workloads. They scale on demand but come with cold-start delays and a cost model that can surprise finance teams.
  Examples: AWS Lambda, Google Cloud Functions, Vercel Functions

Data Stores

• SQL Databases:
  Structured, relational data with strong consistency and support for complex joins. Ideal when you need transactional integrity.
  Examples: PostgreSQL, MySQL, SQLite

• NoSQL Databases:
  Flexible schema and horizontally scalable. Useful for high-throughput use cases, but consistency guarantees may be relaxed.
  Examples: MongoDB, Cassandra, DynamoDB, CouchDB

• Specialized Stores:

  • Blob Storage: For large files like images, videos, and backups.
    Examples: Amazon S3, Google Cloud Storage

  • Key–Value Stores: Lightning-fast access for session data and feature flags.
    Examples: Redis, Memcached, Riak

  • Vector Databases: Used in AI applications for similarity search and embeddings.
    Examples: Pinecone, Weaviate, pgvector with PostgreSQL

  • Graph Databases: Optimized for traversing relationships like social graphs.
    Examples: Neo4j, Amazon Neptune

  • Time Series Databases: Purpose-built for metrics, logs, and timestamped data.
    Examples: InfluxDB, TimescaleDB

In-Memory Acceleration

• Content Delivery Networks (CDNs):
  Serve static assets from edge locations to reduce latency and offload your origin servers.
  Examples: Cloudflare, Fastly, Akamai

• In-Memory Cache Solutions:
  Store hot keys in memory for millisecond-level read performance. Without strict eviction and freshness rules, cached data can become a silent liability.
  Examples: Redis, Memcached, Caffeine

Async Backbone

• Message Queues:
  Allow different parts of a software system to communicate asynchronously. Decouple producers and consumers to absorb traffic spikes and isolate failures.
  Examples: AWS SQS, RabbitMQ, Azure Queue Storage

• Stream Platforms:
  Capture real-time events for analytics and replay. Enable event-driven architectures and eventual consistency models.
  Examples: Apache Kafka, Apache Pulsar, Redpanda

• Schedulers / Cron Jobs:
  Run background tasks at set intervals. Be sure to handle clock drift, retries, and idempotency to avoid duplicate runs.
  Examples: Airflow, Celery Beat, Kubernetes CronJobs, Sidekiq (Ruby), Oban (Elixir)

Observability

• Metrics & Monitoring:

  Track the health and performance of your system. Missing SLOs or unclear dashboards can delay detection.

  Examples: Prometheus, Grafana, Datadog, NewRelic, CloudWatch

• Logging:

  Capture detailed events and errors. Without structure or correlation IDs, logs become hard to use.

  Examples: ELK stack, Grafana Loki, Fluentd, Sentry

• Tracing:

  Follow requests across services to find latency or failure points. Incomplete traces lead to blind spots.

  Examples: OpenTelemetry, Jaeger, Zipkin, Honeycomb, Datadog APM

• LLM Observability:

  Understand how AI features behave in production. Track prompt quality, model outputs, latency, costs, and failure modes.

  Examples: Langfuse, Helicone, PromptLayer, HoneyHive, WhyLabs

• Feature Flags:
  Enable gradual rollouts and experiments. But stale flags become hidden tech debt that complicates future changes.
  Examples: LaunchDarkly, Flagsmith, Unleash

• Service Mesh:
  Standardizes cross-service communication, retries, and mutual TLS. Powerful but complex. Only adopt if you have the operational maturity to manage it.
  Examples: Istio, Linkerd, Consul Connect

Security Layer

• Identity Providers (IdPs):
  Centralize authentication and enable Single Sign-On (SSO). Help enforce security policies like Multi-Factor Authentication (MFA). Be careful: if your IdP fails, all access may be lost unless you have fallback strategies.
  Examples: Auth0, Okta, Azure AD

• Secrets Managers:
  Securely store and manage credentials, API keys, and certificates. Regular rotation and audit trails are essential to avoid leaks.
  Examples: AWS Secrets Manager, HashiCorp Vault, Doppler

Leadership takeaway: Every building block adds complexity. Always ask: Who owns this at 2 a.m.? and What metric proves it’s healthy?

Part 3: Choose Your Architecture Pattern

Every system lies on a spectrum. As you move from left to right, you gain flexibility but also introduce more complexity, coordination overhead, and failure points.

Understanding this spectrum helps you make the right call for your team’s size, your product’s stage, and your platform’s needs.

Classic Monolith

All domains, e.g. authentication, payments, notifications, live in a single codebase and deploy as one unit.

• Pros: Simple development and local setup. Easy to reason about.

• Cons: Difficult to scale across teams. One bug can affect the entire system.

Real-world example: Basecamp famously runs as a monolith using Ruby on Rails, emphasizing simplicity and maintainability.

Modular Monolith

Still a single deployable unit, but with strict internal boundaries between modules. Each module owns its data and communicates through defined in-process interfaces.

• Pros: Preserves simplicity while enabling team autonomy. Avoids most latency and consistency issues.

• Cons: Requires discipline to enforce boundaries. Migration to microservices may still be needed at larger scale.

Real-world example: Shopify uses this model to scale effectively without fragmenting its platform.

Microservices

Each bounded context becomes its own independently deployable service, communicating over the network.

• Pros: Enables teams to deploy, scale, and fail independently. Encourages clear ownership.

• Cons: Brings added latency, operational complexity, and the need for robust governance, observability, and cross-service coordination.

Real-world example: Netflix uses microservices at massive scale to enable team autonomy and resilience in its streaming platform.

Serverless (Functions-as-a-Service)

Instead of managing long-running services, functions are triggered on demand and scale automatically.

• Pros: Minimal infrastructure overhead. Ideal for event-driven workloads and MVPs.

• Cons: Cold starts, vendor lock-in, and limitations for systems that require persistent connections or high-throughput processing.

Real-world example: AWS re:Post (Amazon’s developer Q&A site) uses a serverless architecture built on Lambda, DynamoDB, and API Gateway.

Leadership takeaway: Begin with the simplest architecture that meets your needs, typically a monolith. Move toward modular monoliths, microservices, or serverless only when growth, team independence, or system complexity make it necessary.

The modular monolith often strikes the best balance: it gives you structure, boundaries, and speed, without the full overhead of microservices.

Part 4: Apply the RESHADED Framework

Whether you’re reviewing a system proposal or answering a system design interview, strong thinking beats memorized patterns.

The RESHADED framework is a reliable mental model for structuring your approach. It helps you organize your thoughts under pressure, and just as importantly, teach others how to do the same.

Here’s the breakdown:

Requirements

Clarify the user goals, business objectives, and non-functional constraints.
Get specific: SLAs, uptime targets, latency budgets, and data retention policies.

Estimation

What does the load look like?
Estimate peak queries per second (QPS), monthly storage growth, and read/write ratios. In interviews, speak your assumptions out loud so others can follow your thinking.

Storage Schema

Choose data models that match the system’s access patterns.
Explain why you’d use SQL, NoSQL, or a specialized store, and how you’d handle partitioning, indexing, and consistency.

High-Level Design

Sketch the major components and data flows.
Use boxes and arrows. Stay technology-agnostic so you can focus on responsibilities and interfaces.

APIs

How do the components talk to each other?
Include protocols (REST, gRPC, GraphQL), data contracts, and sample payloads. Discuss latency, idempotency, and versioning.

Detailed Design

Zoom into one or two tricky parts.
Think about caching strategies, failover workflows, sharding approaches, or queue handling. Show depth over breadth.

Evaluation

Test your design against earlier estimates.
Where are the bottlenecks? What metrics will prove the system is working? Consider dashboards, synthetic tests, and chaos drills.

Distinctive Features

Add polish.
What makes this design great, not just good? Look for automation, privacy features, cost controls, self-healing mechanisms, or auditability.

Leadership takeaway: Teach this framework to your senior engineers. It creates a shared language for design reviews, architecture decisions, and high-stakes interviews. Structured thinking scales better than scattered genius.

Part 5: Integrate AI into Your Architecture

AI is no longer experimental. Large language models (LLMs), vector search, and generative pipelines are now part of production systems. As companies move beyond prototypes, engineering leaders need to think carefully about how AI affects system design, architecture, and operations.

This section is your practical guide to understanding where AI fits in your stack, what new components it introduces, and how to manage the unique risks that come with it.

AI is entering every layer of the stack

You’ll find AI-powered features showing up in three main areas:

• User-facing assistants such as chatbots, smart search, auto-replies, and semantic filters.

• Developer productivity tools like code generation (GitHub Copilot, Cursor, Windsurf), test scaffolding, and automatic documentation.

• Semantic insights at scale including summarization, classification, anomaly detection, and root-cause analysis.

New components AI brings to your architecture

Shipping AI means introducing new infrastructure into your stack. These components are often not covered by traditional backend design and require thoughtful integration:

• LLM Gateway
  This is the API layer that sends prompts to either SaaS models like OpenAI or Anthropic, or to self-hosted models like Llama 3 running on Hugging Face or Ollama. It manages routing, retries, and cost control.

• Vector Database
  Stores high-dimensional embeddings used in similarity search and retrieval-augmented generation (RAG). Options include:

  • PostgreSQL + pgvector for small to medium workloads.

  • Pinecone, Weaviate, or Qdrant for specialized, scalable solutions.

• GPU or TPU Cluster
  Used to accelerate model inference, either on-premises or in cloud services like AWS EC2 GPU instances, Azure ML, or Google Vertex AI. These clusters require tuning, load balancing, and cost monitoring to avoid budget overruns.

• Prompt Orchestrator
  Coordinates chains of model calls, tools, and business logic. Frameworks like LangChain, Semantic Kernel, or Haystack power these pipelines. They often suffer from poor observability and debugging challenges if not managed carefully.

• Model Registry
  Tracks versioned models, metadata, and training artifacts. Tools like MLflow, Weights & Biases, or SageMaker Model Registry help teams ensure reproducibility and controlled rollouts.

AI-specific risks every leader should consider

AI systems introduce new failure modes and cost structures. Here are the most common risks and how to manage them:

• Latency variability
  LLM inference is non-deterministic and can vary from 200ms to several seconds. Use timeout thresholds, retries, and circuit breakers. Cache common responses when possible.

• Prompt injection
  Malicious users can craft inputs that bypass filters or manipulate outputs. Sanitize inputs, apply guardrails, and review outputs with classifiers.

• Inference costs
  LLMs can get expensive quickly. A runaway script or open-ended loop can burn through budget in hours. Set usage quotas, alert thresholds, and team-level cost controls.

• Non-deterministic outputs
  Same input, different answer. This breaks tests, confuses users, and complicates debugging. Use temperature control, fallback responses, and evaluate model behavior with golden sets.

• Privacy and compliance
  Personal data in prompts or model outputs can violate GDPR or company policies. Strip personally identifiable information (PII), log activity securely, and use on-prem models for sensitive data.

Building a team that can deliver AI features

AI engineering is cross-functional by nature. Here’s how high-functioning teams are adapting:

• Form hybrid squads with AI/ML engineers, backend developers, and product managers.

• Build fast feedback loops through human evaluation, prompt versioning, and metric dashboards.

• Develop prompt libraries to share successful examples across teams.

• Train your teams on risks, bias mitigation, prompt safety, and ethical design.

Leadership takeaway: AI should not be treated as magic. It is another critical part of your system. Like any other layer, it needs proper architecture, clear ownership, budgets, and observability.

Design for modularity and control early on. That way, when the model changes, the vendor shifts, or costs spike, your system remains stable.

Final Thoughts: Put It Into Practice

System design is no longer the domain of architects alone.

As an engineering leader, your understanding of these principles shapes how your team builds, scales, and responds when things go wrong.

You don’t need to be the smartest person in the room.

You need to ask the right questions. The ones that uncover risk, clarify intent, and raise the technical bar.

Now it’s your turn:
Pick one section from this guide. Go deeper this week. Bring it into your next design review. And lead with clarity.

Share

P.S. I don’t usually write about system design.

Most of my writing focuses on leadership, career growth, and building high-impact engineering teams. But system design is a topic I’m deeply passionate about, and it’s incredibly valuable if you’re aiming to become a Staff Engineer, a highly respected Engineering Manager, or just want to succeed in your next system design interview.

If you found this useful and want more posts like this, covering real-world system design scenarios, or interview preparation examples, drop a comment and let me know.

Your feedback will help shape what I write next.

Leave a comment

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

A lightbulb goes off: a few months ago you mentored Oliver, a backend engineer in another team, when he upgraded that very component for a security patch.

You ping him. He’s packing up for the weekend but answers because you saved him hours back then. Five minutes later he spots the issue and ships a fix.

That’s social capital: past help turned into instant, high-stakes support no process could have matched.

What Social Capital Really Means in Engineering

Social capital is the trust, credibility, and relationships you build with the people you work with. It’s the “social currency” that helps you influence decisions, collaborate smoothly, and move work forward, even when you don’t have formal authority.

Just like financial capital buys tools and resources, social capital buys belief and support.

Tanya Reilly, author of The Staff Engineer’s Path, one of my favourite books, outlines what engineers need to succeed: energy, credibility, quality of life, skills, and social capital.

Think of it like a bank account; you make regular deposits of trust and goodwill so you can draw on them when it matters most:

• Deposits: Quick PR reviews, sharing documentation, mentoring colleagues, nominating peers for kudos.

• Withdrawals: Asking for urgent approvals, securing headcount, driving high-risk migrations.

A healthy balance can support large withdrawals. But when it’s empty, even critical requests may be ignored.

The Three Pillars of Social Capital

Social capital takes time to accumulate. It grows from simple, consistent behaviors that build integrity, add value, and keep your work visible. Think of it in three parts:

1. Trust: Keep your word and tell the truth even when it is uncomfortable. Follow through on commitments, surface risks early, and own your mistakes. Colleagues back engineers they can count on.

2. Credibility: Pair solid execution with clear communication. Show your reasoning, share data, and keep learning. When others see you as competent and thoughtful, they seek your input.

3. Relationships: Invest in people. Offer help without keeping score, celebrate wins, and build rapport beyond day-to-day tasks. Strong ties across teams let you unblock work, find advocates, and amplify impact.

Ignore one of these and your capital fades. Practice all three and you’ll earn trust, support, and influence that grows over time, like compound interest. The small deposits you make consistently can grow into career-changing impact.

Social Capital Is Not Favoritism

Real social capital is built on visible contributions, shared wins, and mutual trust. Favoritism and nepotism rely on bias and closed doors. One rewards effort and credibility; the other protects an inner circle.

Use social capital to lift colleagues, bridge teams, and widen opportunity for everyone. If you find yourself in a company where promotions hinge on favoritism, you face a simple fork in the road:

• Stay and accept the ceiling. Your growth will slow, and any promotion may come down to ugly politics, not performance.

• Leave for a healthier culture. Find a company that rewards both results and genuine relationships.

Choose the path that preserves your values, your integrity, and your long-term growth.

“Titles do matter, and so do growth and career progression.”
— Tanya Reilly, The Staff Engineer’s Path

High Agency Needs Social Capital to Scale

High-agency engineers move fast, take ownership, and push boundaries. They don’t wait for permission; they solve problems, clear roadblocks, and drive impact. But without strong relationships to support them, their efforts can stall. Mountains rarely move alone.

This is what I call the lone genius ceiling. You’re doing great work, but it doesn’t go far if no one’s aligned or aware. When high agency meets low social capital, you burn out fighting uphill battles. When the two combine, influence multiplies and you become a force that shifts entire systems.

This matrix shows the difference:

• Low agency + low social capital → Overlooked Executor

• High agency + low social capital → Lone Wolf, Stalled by Politics

• Low agency + high social capital → Reliable Partner

• High agency + high social capital → Org-Changing Force

You want to operate in the top-right as an org-changing force. That’s where agency turns from effort into leverage. And that’s exactly where social capital does its best work.

Practical Habits for Remote and Async Teams

Remote work has eliminated the casual hallway chat, but it also creates an opportunity: relationship-building can now be intentional, inclusive, and distributed across time zones.

Here are a few small but powerful habits to build connection and visibility:

• Schedule weekly 30-minute virtual coffees with teammates, especially outside your direct group.

• Post short Loom videos to demo features or explain decisions. These scale context without needing a meeting.

• Send “Friday Gratitude” messages to spotlight and thank those who helped you during the week.

• Keep cameras on briefly at the start of meetings to preserve some human presence, then allow flexibility.

Remote and async teams don’t bond by chance. They bond because someone makes the first move. That someone can be you.

Spending and Sustaining Social Capital

Social capital pays off only when you put it to work, so use it where the payoff is real. Tap your network to push key architecture decisions, secure extra headcount, or shield your team when deadlines tighten and scope creeps.

Watch for signs your balance is running low:

• Replies to your messages slow down

• Meeting invites disappear

• People hesitate before helping

Pay down debt by delivering on previous promises, giving public credit, and asking “What can I do for you?” before the next withdrawal.

Spending and refilling are a rhythm. Neglect either side and you risk burnout or silence just when you need allies most.

Scaling Social Capital as You Advance

The way you build and use social capital changes as your career progresses.

Junior engineers start with credibility and connection. Learn names, ask thoughtful questions, and land visible wins so teammates trust both your curiosity and your code.

Mid level engineers widen their circle. Share hard-earned tips, give lightning talks, and review code for neighbors in other squads. Influence grows when the help you offer travels farther than your assigned ticket.

Senior and Staff engineers turn relationships into alliances. Align roadmaps, broker trade-offs between departments, and sponsor rising talent. By now your reputation helps steer decisions that touch the whole organisation.

Managers move from personal capital to team capital. Tactics worth a quick scan:

• Hold skip level chats to build trust across layers

• Rotate project leads so visibility and credit circulate

• Celebrate cross team wins to raise the team’s profile

Act like a social router that links networks, and the entire group gains speed and resilience.

Weekly Micro-Habit Playbook

Small, consistent actions build social capital more effectively than grand gestures. Here’s a simple weekly routine to embed those habits into your workday:

Monday
Micro-Habit: Post a short recap of last week’s achievements
Pillars: Trust, Credibility

Tuesday
Micro-Habit: Offer help on a PR outside your team
Pillars: Relationships, Credibility

Wednesday
Micro-Habit: Schedule a virtual coffee with someone new
Pillars: Relationships

Thursday
Micro-Habit: Document and share a recent learning
Pillars: Credibility

Friday
Micro-Habit: Publicly thank a collaborator
Pillars: Trust

Consistent tiny deposits are like compound interest. Each interaction, thank-you, or bit of help adds to your balance. Over time, that balance grows into something others can't ignore.

Closing Thoughts: From Insight to Action

Social capital is not optional. It is the hidden engine behind influence, execution, and support when it matters most.

But social capital alone isn't enough. Without agency, it goes unused. And without social capital, agency burns out. You need both to create lasting influence and momentum.

Together, they multiply. You move faster, gain buy-in, and bring others with you.

Start small. Pick one habit from the playbook. Share a quick win. Review a teammate’s pull request. Thank someone in public. These small actions build trust, credibility, and relationships.

Over time, they do more than move work forward.
They move you forward.

Your future self, and your future team, will feel the difference.

Share

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

Every company runs on two playbooks.

There’s the “official” one: the glossy handbook HR gives you on your first day. It’s full of company values, respect guidelines, and rules about how to work well with others.

Then there’s the “real” one: the version shared quietly in leadership chats and back channels. It explains how promotions actually happen, how power shifts, and which behaviors get rewarded, not just praised.

If you’ve ever done great work but felt invisible or stuck, chances are you were following the first playbook while others were following the second.

This article offers a glimpse into that second playbook, the one that actually moves careers forward.

Why Great Engineers Stay Stuck

Have you ever seen someone get promoted while someone else, more technically skilled and harder working, stays stuck?

It happens more often than we like to admit.

The high performer who quietly fixes critical systems gets passed over, while someone with broader visibility and stronger internal alliances moves up.

It’s not because the system is broken. (Sometimes it is, but that’s a topic for a future post.) It’s because performance alone is not enough.

Engineers often believe career growth is all about sharpening technical skills. But in reality, moving beyond your current level requires a different toolkit: agency, influence, visibility, sponsorship, and narrative.

If you want to grow, whether toward leadership, staff roles, or more strategic work, you need to operate differently.

The Unwritten Playbook: Five Rules for Career Growth

Here are five truths I’ve learned the hard way over more than 20 years in tech. These are lessons that can shift how you think about career growth and leadership.

1. Decode What Actually Gets Rewarded

Typical issue

You obsess over clean architecture and solid tests, but leadership celebrates the team that ships scrappy MVPs every week. Or you deliver fast, then get penalized because what really matters is uptime and business metrics like activation rate or revenue impact.

Why it happens

What companies say they value isn’t always what they reward. Some glorify speed. Others reward polish or data-driven outcomes. Promotions follow whatever makes execs look good in the next board deck. If you’re optimizing for the wrong thing, great work still misses the mark.

What to do

• Listen closely to what leaders praise in all-hands and review meetings.

• Ask your manager, “When you say impact, what outcomes actually move the needle?”

• Read recent promotion cases or launch posts to spot repeated success metrics.

• Align your work to one or two visible, measurable outcomes like SLOs, KPIs, or revenue impact.

• If you lead a team: Make the value hierarchy explicit so your team doesn’t aim at the wrong target.

“You can observe a lot by watching.” — Yogi Berra

2. Relationships Matter More Than Output

Typical issue

You deliver high-impact work and your metrics shine, yet someone with average skills gets promoted ahead of you. Engineers and new managers often dismiss networking as fluff and focus only on their own code, sprint, or team.

Why it happens

Promotions turn on perception. In calibration rooms, decisions hinge on stories leaders have heard and the advocates in the room. Coffee chats and Slack banter might feel soft, but they shape the narrative when titles get handed out.

What to do

• Map the people who influence your next promotion: directors, VPs, senior PMs.

• Align your roadmap with the outcomes those leaders care about.

• Ask directly: “Would you support me in the next calibration?”

• Schedule one weekly coffee chat outside your team. Track it like a real task.

• If you lead a team: Rotate engineers through cross-functional work to grow their influence organically.

“Your network is your net worth.” — Porter Gale

3. Your Manager Is Not Your Therapist

Typical issue

You share every frustration with your manager, vent about teammates, and expect them to manage your stress. Then review season hits, and the conversation is only about delivery gaps, not feelings.

Why it happens

The manager-employee relationship is not equal. Your manager is responsible for business outcomes, not your emotional well-being. When decisions must be made, results take priority. Blurred boundaries can also signal poor judgment about what belongs in a professional context.

What to do

• Use one-on-ones to talk about strategy, feedback, and blockers, not personal venting.

• Keep complaints factual and offer possible solutions.

• Build a support network outside your reporting line, such as mentors or trusted peers.

• Ask for feedback on your output, not reassurance.

• If you lead a team: Model clear boundaries and refer personal matters to professional resources like coaches or therapists.

“Clear is kind. Unclear is unkind.” — Brené Brown

4. Visibility Beats Hard Work

Typical issue

You stay online long after everyone logs off, polish every edge case, and crush bugs. But months go by with little recognition or credit for your effort.

Why it happens

Results are invisible unless they are shared. Leaders don’t read commit logs. They see dashboards, demos, and (sometimes) meeting notes. When you work quietly, others assume you’re just “keeping the lights on,” not pushing things forward.

What to do

• Share a short weekly update that highlights shipped user value, not hours worked.

• Record two-minute demos and post them before review meetings.

• Tie each update to an outcome like adoption growth or latency drop.

• Ask for clarity checks: “Does this summary make the impact obvious?”

• If you lead a team: Build a culture of demos so visibility doesn’t depend on personality.

“Become a documentarian of what you do.” — Austin Kleon

5. Loyalty Is Not a Career Strategy

Typical issue

You give a company your best years, ignore recruiter pings, and assume strong reviews equal job security. Then a reorg hits, or budgets shrink, and your role disappears overnight.

Why it happens

Companies optimize for quarterly results, not long-term employee tenure. Headcount is a cost, not a promise. Loyalty often flows in one direction. When pressure mounts, even high performers can become expendable.1

What to do

• Block time weekly to learn new tech such as Generative AI.

• Maintain a public portfolio through side projects or open source.

• Share what you learn with your network through posts, notes, or talks.

• Keep your brag document and résumé updated regularly.

• If you lead a team: Support learning time and celebrate external contributions. An employable team is a resilient one.

“The only job security you have today is your commitment to continuous personal improvement.” — Ken Blanchard

Final Thoughts: Turn Insight Into Impact

The biggest blocker in most tech careers isn’t talent. It’s playing by the wrong rules.

The five truths in this article aren’t tricks. They’re the real dynamics behind promotions, influence, and visibility. But knowing them isn’t enough. What matters is how you respond.

High agency is your edge. It’s the difference between waiting for recognition and creating it, between feeling stuck and taking your next step with intent.

Pick one truth and act on it this week. Book a coffee chat. Ask which metric actually moves the needle. Share a short demo. Small moves, taken with agency, compound into career-defining momentum.

Track what works and what doesn’t. Over time, you’ll build your own playbook. One that travels with you, no matter the company or org chart.

Your turn: What unwritten rule has shaped your career? Share it in the comments and help others see the game more clearly.

Leave a comment

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

The way a company interviews you is often the way they’ll treat you once you’re on the inside.

If they waste your time, dismiss your experience, or undervalue your worth during the process, that’s not just a red flag. That is the flag.

You’re not just being evaluated. You’re evaluating them too. And no opportunity is worth compromising your values.

That’s why I’ve set clear boundaries, not out of ego, but out of respect for my time, my dignity, and the work I bring. I believe any serious employer should do the same.

Note: This isn’t about a current job search. It’s a reflection of the standards I’ve developed over years in tech.

My 7 Hard Rules for Every Interview

These are the rules I’ve come to apply through experience. They reflect what I value and need in a hiring process. They may not apply to everyone but they help me filter for the right fit.

1. No LeetCode Drills or Live Coding Sessions

A Personal Experience

Years ago, when I was living in the UK, I interviewed for a Tech Lead Manager role. The first round was an automated coding challenge. I chose Ruby, solved everything, and submitted.

A few days later, I got an auto-rejection. No feedback. No human interaction. Just a cold “no”.

Live coding interviews are no better. I have been asked to code an algorithm for a Trie data structure, on the spot. No one asked how I lead teams, scale systems, or make hard trade-offs. They just wanted to see if I could perform under artificial pressure.

Why I Draw the Line

These interviews test speed and memorization, not engineering judgment. They ignore leadership, communication, and the messy, collaborative work that defines real engineering.

I can write code, design complex systems, and lead engineers. But engineering leadership is not about solving puzzles in isolation. It is about solving real problems with real people.

A Better Approach

If you want to assess technical depth in an engineering leader:

• Ask about architecture I have led

• Review a system design together

• Walk through a real trade-off I made in production

If your process still centers on reversing linked lists or binary trees, it likely won’t surface the kind of leadership I bring.

2. No Lengthy Take-Home Assignments

A Personal Experience

I once received a “quick” take-home coding exercise for a team manager role. It ended up taking more than a dozen hours. I worked nights and weekends to build a complete backend project with edge cases, tests, and documentation, all while balancing a full-time job and family responsibilities.

I even included suggestions for improvements. A few days later, they asked me to implement them.

Then came the message: “Congratulations, you’re moving forward. Please submit an engineering best practices guide and a leadership presentation.”

That was the last time I accepted a take-home assignment without clear limits.

Why I Draw the Line

Take-home assignments can be useful when they’re well-scoped and fair. But most are not. They tend to:

Demand excessive unpaid time,
penalize candidates with full lives outside of work,
emphasize output over decision-making.

If your evaluation relies on marathon take-home work, you’re not assessing ability; you’re screening for availability.

A Better Approach

If you want to see how I think and work:

• Set a clear two-hour limit and stick to it

• Let me walk through a real project I’ve led

• Or review code together and talk trade-offs

Lengthy take-home assignments don’t test skill. They test how much free time you have, often excluding those with limited availability, such as managers and parents.

3. No More Than Five Interview Rounds

A Personal Experience

I once went through a long interview loop for a promising engineering management role. It was a great startup with an exciting product. After the recruiter call, I was told to expect three more interviews.

I was wrong. It turned into an NxM process: a technical loop, a management loop, and a culture fit loop, each with multiple rounds.

At that point, I wasn’t being interviewed. I was auditioning. For free.

I didn’t drop out sooner because of the sunk cost fallacy. I kept thinking, maybe the next one would be the last.

Why I Draw the Line

Dragging candidates through endless interviews sends the wrong message. It usually means one of two things:

The company struggles to make decisions,
or they don’t value your time.

Both are red flags.

And the more people involved, the more diluted the signal becomes. With every added opinion, your chances of passing decrease. Consensus is not a substitute for clarity.

A Better Approach

A well-run process looks like this:

• Limit the interview loop to three to five rounds

• Respect the candidate’s calendar

• Move with urgency and purpose

If it takes weeks and a dozen people to decide whether I’m a fit, the problem likely isn’t the candidate; it’s the process.

4. No Second Interviews Without Discussing Salary

A Personal Experience

I once interviewed with a well-known tech company. After the recruiter call, the hiring manager interview, and five final rounds, everything seemed on track. The team was enthusiastic, and the conversations went well.

Then came the offer: about 30 percent below my current salary.

I understand compensation can vary. Location, equity, bonuses, and negotiation all play a role. But given my background and the signals I received throughout the process, the offer was unexpectedly low. Even some local startups were offering more.

I had heard not to bring up salary early with such well-know tech companies. People said they would pay fairly. They didn’t, in this case. I had wasted weeks on a role I would have declined upfront if they had just been transparent.

Why I Draw the Line

If you are not upfront about compensation, you are not respecting the candidate’s time.

Salary ranges are not just numbers. They reflect trust, clarity, and alignment. Hiding them puts all the risk on the candidate and signals a power imbalance.

It also discourages underrepresented candidates from negotiating or even applying, which reinforces pay gaps and inequality.

A Better Approach

If you are serious about the role:

• Share the salary range by the second conversation, ideally in the job description

• Be clear about your compensation philosophy: is it fixed, flexible, or tied to equity

• If you cannot meet expectations, say so early. Save everyone time

Compensation is not a taboo topic. It is a business conversation. If a company cannot handle that professionally, I do not trust how they will handle anything else.

Share

5. No Negotiating Low-Ball Offers or Down-Leveling

A Personal Experience

Some time ago, after a smooth interview process for a senior leadership role, the recruiter called with good news: “You really impressed the team. They’d love to move forward.”

Then came the twist. “We’re offering one level below the original scope. The team felt you’d grow into the higher role soon.” The offer was well below market, with vague promises and no clear path to advancement.

I declined, even though it was a well-known company I had been eager to join.

I do not believe in down-leveling or vague future promises. I’ve seen how, on both sides, as a candidate and as a hiring manager, it creates confusion, misaligned expectations, and broken trust.

Why I Draw the Line

Low-ball offers and down-leveling can signal a lack of alignment. They often suggest one of three things:

The company may be trying to stretch its budget,
they might not fully understand the impact of the role,
or they may be unsure how to assess seniority accurately.

In leadership roles, scope, compensation, and authority need to align. When they don’t, the risk of misalignment and future friction increases, sometimes setting the hire up for a difficult start.

A Better Approach

Great hires start with clarity:

• Benchmark roles and offers to the market

• Be clear about level, scope, and expectations

• Reject if you are not confident, but do not down-level to keep them “just in case”

Pay for the role you are hiring, not for what someone might grow into.

I’m not here to negotiate my worth. That kind of process simply doesn’t align with how I approach leadership and problem-solving.

6. No Room for Disrespect in Interviews

A Personal Experience

I once interviewed with a large tech company. After several strong rounds, I reached the final interview.

The interviewer arrived late and began by introducing himself as a highly senior architect and the proud creator of one of their products. He made it clear he would be the final decision-maker. And he was not joking.

As we started, I mentioned that Elixir was my preferred programming language. He seemed unfamiliar with it and spent a few moments looking it up. The dynamic shifted, and I began to feel uneasy. I offered Ruby as an alternative to help the conversation flow more smoothly. He responded with, “What esoteric languages you use,” which caught me off guard.

A few questions later, after I shared a technical answer he disagreed with, the interview ended abruptly. His final comment was, “Our managers need to be highly technical.”

I left the call feeling disheartened. What began as a promising opportunity ended with clear misalignment. Not just technically, but also in values and communication style. While I didn’t move forward, the experience gave me valuable insight into what I’m looking for in a team and environment.

Why I Draw the Line

Interviews are not just evaluations. They reveal the culture behind the scenes.

If someone behaves with arrogance, disrespect, or hostility in an interview, that is often how they act at work. If the company defends or ignores it, that tells you what they are willing to tolerate.

Respect is not optional. It is the foundation of trust, safety, and performance. Especially in leadership roles where communication and emotional intelligence matter just as much as technical skill.

A Better Approach

Culture shows up in every interview:

• Train interviewers to assess candidates and represent company values

• Watch for legacy hires who slipped through before principles mattered

• Ask candidates for feedback, and act on it

A poor interview experience can push great talent away. An unprepared or dismissive interviewer can do lasting harm to your culture. I value honest feedback and clear expectations, but there’s a difference between being direct and being disrespectful. If your team cannot make that distinction, we may not be aligned.

7. No Half-Measures on Remote Work

A Personal Experience

Some years ago, I interviewed with a company that called itself “remote-friendly.” But throughout the process, contradictions appeared.

One leader preferred people “close to the office.” Another mentioned “We’re flexible, but ideally we’d love managers to come in a few days a week.”

That was not flexibility. It revealed a misalignment between the expectations and the reality of the role.

I have built and led high-performing remote teams. I know the value of focused, async, distributed work. The problem with “remote-friendly” setups is that when leadership stays in the office, remote employees fall behind. They miss the hallway chats, the unplanned lunches, the in-room decisions. They become second-class employees.

Why I Draw the Line

Remote work is not a perk. It’s an operating model. Leading remotely takes intention. It demands clear communication, real autonomy, and outcome-based expectations.

When companies are not truly remote-first, you often see:

Office voices gaining more influence,
confusion about availability and presence,
broken collaboration caused by a lack of shared habits.

Remote leadership is not about working from home. It’s about designing teams that thrive apart.

A Better Approach

Remote work only works when it’s intentional:

• Be clear about your model: remote, hybrid, or office-first

• Shift the mindset from hours worked to impact delivered

• Give teams the tools and practices they need to succeed remotely

Remote work shifts the focus from busyness to meaningful outcomes. I am here to do work that matters, measured by results, not hours seated on a chair or office presence. If your model still equates productivity with being seen, we are not aligned.

Final Thoughts: Boundaries for Mutual Respect

These aren’t just preferences. They’re principles I’ve learned to hold, to protect my time, my dignity, and the career I’ve built with intention.

Some might say I’m being too selective. Maybe. But I’ve learned the hard way: not every door is worth opening.

This isn’t about ego. It’s about knowing what matters, and having the self-respect to expect it in return.

You don’t have to follow my rules. But you should have your own.

So ask yourself: What do you need from an interview process to feel respected, valued, and set up for success? What are your non-negotiables?

The clearer you are about your boundaries, the easier it is to recognize the opportunities that truly fit.

Hiring is a two-way street. What would make you walk away from an offer?

Leave a comment

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch. Connect with me on LinkedIn.

Subscribe now

I love physical books. There’s something special about holding them, turning pages, and scribbling notes in the margins. I read digitally too. It’s convenient, fast, and practical. But when a book truly resonates, I buy a physical copy. If it earns a spot on my shelf, it means I want it close.

This list doesn’t include every book I’ve read. Just the ones that changed how I think, lead, and live. My bookshelf1 isn’t decoration. It’s filled with mentors, coaches, and trusted companions on my journey as a leader and lifelong learner.

Below, you’ll find my favourites organized by category, each with summaries and personal highlights.

These books are my best of the best.

1. Leadership & Management

The following are books that guide readers through various leadership roles, from engineering management to executive leadership, and general organizational change.

1.1 Engineering Management

Help you transition from engineer to manager (team leader, engineering manager, etc.), with insights on leadership, team dynamics, and mentorship.

• The Manager’s Path – Camille Fournier

  A Guide for Tech Leaders Navigating Growth and Change

  A roadmap for transitioning from individual contributor to technical leadership, with insights into mentorship, feedback, and team dynamics.

• Become an Effective Software Engineering Manager – James Stanier
  Practical advice for new engineering managers, covering communication, team development, and the shift from coding to leadership.

• High Output Management – Andrew S. Grove
  A classic management guide from Intel’s former CEO, emphasizing output-oriented management and effective team leadership.

• An Elegant Puzzle – Will Larson

  Systems of Engineering Management
  Tackles complex engineering management challenges through systems thinking, addressing team structure, scaling, and organizational design.

• Engineering Management for the Rest of Us – Sarah Drasner
  Offers empathetic, approachable leadership strategies focusing on communication and building inclusive, high-performing teams.

1.2 Technical Executive Leadership

Cover strategic thinking for tech leaders (managers, directors, VPs and CTOs)—scaling teams, setting vision, and aligning tech with business goals.

• Team Topologies – Matthew Skelton & Manuel Pais

  Organizing Business and Technology Teams for Fast Flow
  Explores optimal team structures and interactions to enhance software delivery and organizational effectiveness.

• The Engineering Executive’s Primer – Will Larson

  Impactful Technical Leadership
  Guidance for engineering executives on scaling teams, setting strategic vision, and driving impactful organizational change.

• The CTO ToolBox – Sergio Gago Huerta

  The definitive list of tools and resources for Technology Leaders
  A practical collection of tools and frameworks for CTOs, covering strategic alignment, team building, and tech-business integration.

1.3 General Leadership & Organizational Change

Cover leadership principles for any domain—focused on collaboration, empowerment, and execution.

• Turn the Ship Around! – L. David Marquet

  A True Story of Turning Followers into Leaders
  A former submarine captain’s story of empowering his crew with a leader-leader model, transforming organizational performance.

• Leading Teams – Mandy Flint & Elisabet Vinberg Hearn

  10 Challenges, 10 Solutions
  Practical approaches to resolving team challenges through trust, collaboration, and shared purpose.

• The Art of Action – Stephen Bungay

  How Leaders Close the Gaps between Plans, Actions and Results
  Combines military strategy with business insights to improve alignment, execution, and decision-making.

2. Technical Mastery & Engineering Craft

The books of this section are dedicated to enhancing technical skills, covering advanced engineering roles, software design, architecture, and craftsmanship.

2.1 Staff & Principal Engineering

Help senior engineers grow their influence, lead without authority, and make strategic technical impact.

• The Staff Engineer’s Path – Tanya Reilly

  A Guide for Individual Contributors Navigating Growth and Change
  Guides senior engineers on navigating influence without authority, project execution, and mentoring across teams.

• Staff Engineer – Will Larson

  Leadership Beyond the Management Track
  Defines the staff engineer role, focusing on leadership, architecture, and strategic technical impact beyond management.

2.2 Software Design & Architecture

Focus on building scalable, maintainable systems with strong design principles and architecture.

• Designing Data-Intensive Applications – Martin Kleppmann
  A comprehensive guide to building scalable and maintainable data systems, with a focus on storage, processing, and integration.

• System Design Interview – Alex Xu & Sahn Lam

  An Insider’s Guide: Volume 2
  Frameworks and real-world examples for tackling advanced system design problems effectively.

• Understanding Distributed Systems – Roberto Vitillo

  What every developer should know about large distributed applications
  Practical insights on building scalable, reliable distributed systems with a focus on fault tolerance and real-world applications.

• A Philosophy of Software Design – John Ousterhout
  Discusses how to manage complexity and improve maintainability through thoughtful design principles.

• Practical Object-Oriented Design in Ruby – Sandi Metz
  Teaches clean, maintainable OOP design using Ruby, with real-world examples and principles.

2.3 Software Craftsmanship & Engineering

Cover the path to engineering excellence—best practices, learning, and writing quality code.

• The Pragmatic Programmer – Andrew Hunt & David Thomas

  From Journeyman to Master
  Offers timeless programming wisdom and practical tips to become a more adaptable and effective software developer.

• The Software Engineer’s Guidebook – Gergely Orosz

  Navigating senior, tech lead, and staff engineer positions at tech companies and startups
  A roadmap from junior to senior engineer, offering guidance on technical excellence and career growth.

• Modern Software Engineering – David Farley

  Doing What Works to Build Better Software Faster
  Advocates for continuous delivery, feedback loops, and disciplined engineering practices to improve software delivery.

• Elixir in Action – Saša Jurić
  Introduces Elixir and functional programming for building concurrent, resilient applications.

3. Product, Business & Strategy

This section covers the intersection of product development, business strategy, and startup methodologies, providing frameworks for building successful products and organizations.

3.1 Product Discovery & Management

Focus on understanding customers, continuous discovery, and strong product management.

• Inspired – Marty Cagan

  How to Create Tech Products Customers Love
  Reveals how top tech companies create products that customers love, emphasizing strong product management and discovery.

• Continuous Discovery Habits – Teresa Torres

  Discover Products that Create Customer Value and Business Value
  Provides a framework for ongoing customer discovery to inform effective, evidence-based product decisions.

3.2 Business & Startup Strategy

Cover strategy, startup methods, and how to scale a business effectively.

• Good Strategy Bad Strategy – Richard Rumelt

  The Difference and Why It Matters
  Distinguishes good strategies from bad ones and presents tools to craft focused, actionable plans.

• The Goal – Eliyahu M. Goldratt

  A Process of Ongoing Improvement
  A business novel introducing the Theory of Constraints through a story-driven approach to continuous improvement.

• The Lean Startup – Eric Ries
  A foundational book on building startups efficiently through iterative development and validated learning.

• Predictable Revenue – Aaron Ross & Marylou Tyler

  Turn Your Business Into a Sales Machine with the $100 Million Best Practices of Salesforce.com
  A playbook for scaling B2B sales through repeatable outbound systems.

• The Hard Thing About Hard Things – Ben Horowitz

  Building a Business When There Are No Easy Answers
  Brutally honest lessons from a CEO’s journey through building and surviving tough startup situations.

3.3 Culture, Collaboration & Ways of Working

Focus on the people side of tech—team dynamics, remote work, and workplace culture.

• Peopleware – Tom DeMarco & Timothy Lister

  Productive Projects and Teams
  A classic exploring how team environment and human factors drive software success more than tools or processes.

• Rework – Jason Fried & David Heinemeier Hansson
  A bold rethinking of traditional business wisdom, focused on simplicity and impact over process.

• Remote – Jason Fried & David Heinemeier Hansson

  Office Not Required
  A practical guide to managing distributed teams and thriving in a remote-first world.

• The Geek Way – Andrew McAfee

  The Radical Mindset that Drives Extraordinary Results
  Explores how “geek” values like transparency, experimentation, and speed can revolutionize organizational culture.

• The DevOps Handbook – Gene Kim, Jez Humble, Patrick Debois, and John Willis

  How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  Comprehensive guide on how to build high-performing technology organizations by combining DevOps, lean principles, and continuous delivery.

4. Mindset & Personal Growth

4.1 Habits, Focus & Deep Work

Build better habits, focus deeply, and sustain long-term productivity.

• Atomic Habits – James Clear

  An Easy & Proven Way to Build Good Habits & Break Bad Ones
  Breakthrough framework for building good habits and eliminating bad ones using behavioral psychology.

• Deep Work – Cal Newport

  Rules for Focused Success in a Distracted World
  Advocates for deep focus and provides tactics to minimize distractions in knowledge work.

4.2 Communication, Negotiation & Influence

Sharpen your communication—be clear, assertive, persuasive, and confident in every conversation.

• On Writing Well – William Zinsser

  The Classic Guide to Writing Nonfiction
  A gold standard for clear, graceful nonfiction writing.

• Never Split the Difference – Chris Voss

  Negotiating as if Your Life Depended on It
  Negotiation tactics from an FBI hostage negotiator that are surprisingly useful in everyday business and life.

• How to Win Friends & Influence People – Dale Carnegie
  Timeless, practical advice on how to connect with others, build trust, and influence outcomes.

• When I Say No, I Feel Guilty – Manuel J. Smith

  How to Cope - Using the Skills of Systematic Assertive Therapy
  A powerful introduction to assertiveness training using systematic behavioral techniques.

4.3 Mental Toughness & Discipline

Push past limits, develop grit, and strengthen your mindset through challenge and discomfort.

• Can’t Hurt Me – David Goggins

  Master Your Mind and Defy the Odds
  A story of how extreme discipline and grit helped Goggins overcome trauma and achieve the impossible.

• Never Finished – David Goggins
  The follow-up to Can’t Hurt Me, doubling down on relentless self-improvement.

4.4 Stoicism, Antifragility & Self-Mastery

Cultivate resilience, clarity, and control—learn to thrive under pressure and lead yourself first.

• The Daily Stoic – Ryan Holiday & Stephen Hanselman

  366 Meditations on Wisdom, Perseverance, and the Art of Living
  Daily meditations from Stoic philosophers to help navigate modern life with clarity and resilience.

• Invicto – Marcos Vázquez

  Logra más, sufre menos
  A Spanish-language book on discipline, Stoicism, and living a purpose-driven life.

• Antifragile – Nassim Nicholas Taleb

  Things That Gain from Disorder
  Explores how certain systems actually benefit from chaos, volatility, and disorder.

• Thinking, Fast and Slow – Daniel Kahneman
  Nobel-winning insights into how we think, decide, and often fail without realizing it.

  Share

My Top 10 Personal Favourites

I’ve read dozens of books on leadership, engineering, strategy, and personal growth—but these are the ones that stuck. I return to them often. Some brought clarity when I needed it; others pushed me to lead better, think deeper, or grow stronger. They live on my shelf because they changed something in me.

These are my all-time favourites, in no particular order. Each one includes a brilliant quote from the book, a brief note on why it matters to me, and a link where I’ve mentioned it (or a related post on a similar topic). They’re not just great reads—they’ve stuck with me and earned their place.

1. The Manager’s Path

I picked up this book early on my management journey. It didn’t have all the answers, but it gave me a fresh perspective on leadership—one that focused on growing with my team, not above them.

“Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. Marc Hedlund.”

2. High Output Management

This book changed how I think about my job as a manager. Grove turns management into a process—clear, structured, and measurable. It helped me become more intentional about how I lead and scale teams.

“The output of a manager is the output of the organizational units under his or her supervision or influence.”

3. Team Topologies

It gave me the language to talk about team structure, flow, and ownership—things we often feel but struggle to explain. Every engineering leader should read this.

“When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains.”

4. Turn the Ship Around!

This book reshaped how I think about authority. Marquet shows that true leadership is about giving control, not taking it. It made me a more empowering, trust-first leader.

“Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves.”

5. The Staff Engineer’s Path

I wish this existed earlier in my career. It captures the messy, unspoken side of being a senior IC—the politics, the influence, the impact beyond code. It’s practical and refreshingly honest.

“You should put points into what you want to be good at so you can build up those skills.”

6. Designing Data-Intensive Applications

I don’t just reference this book—I study it. It’s helped me make smarter architectural decisions and understand trade-offs at scale. Every time I open it, I learn something new.

“Building for scale that you don’t need is a waste of effort and may lock you into an inflexible design.”

7. The Pragmatic Programmer

This is the book that made me fall in love with the craft of software engineering. It’s full of timeless wisdom—simple, sharp, and always relevant.

“You can’t write perfect software. Did that hurt? It shouldn’t. Accept it as an axiom of life.”

8. Atomic Habits

This book helped me actually change. It’s not about motivation—it’s about designing systems that make success inevitable. Small steps, done right, can be transformational.

“All big things come from small beginnings. The seed of every habit is a single, tiny decision.”

9 .Never Split the Difference

This book changed how I approach conversations—at work, in life, everywhere. It taught me the importance of listening well and asking the right questions.

“He who has learned to disagree without being disagreeable has discovered the most valuable secret of negotiation.”

10. Can’t Hurt Me

It’s raw and intense—and exactly what I needed during tough moments. Goggins taught me that limits are mostly in our minds, and discipline is freedom.

“You are in danger of living a life so comfortable and soft, that you will die without ever realizing your true potential.”

Final Thoughts

Every book on this list has shaped me in some meaningful way. Whether by shifting my perspective, advancing my career, or simply helping me see life more clearly.

But the real power of reading isn’t just in discovering new ideas. It’s in taking action and letting those ideas change you.

These are my favourites. What about yours? I’d love to hear which books have made a difference in your life.

Happy reading,
Rafa

Leave a comment

Thanks for reading The Engineering Leader. 🙏

If you enjoyed this issue, tap the ❤️, share it with someone who'd appreciate it, and subscribe to stay in the loop for future editions.

👋 Let’s keep in touch — connect with me on LinkedIn.

Subscribe now

Yesterday, I saw a bold post on X:

“Junior engineers are cooked”

I get it. But I disagree.

AI won’t replace software engineers. Not even the less experienced ones.

It’s not the end of junior engineers. It’s the end of low-agency individuals.

Let me explain it.

The Invisible Farewell

Layoffs aren’t always dramatic confrontations or tearful goodbyes. Sometimes, they’re more like quiet disappearances.

Imagine the shock of waking up one day to discover you’re no longer relevant to the team’s plans. No announcement, no explanation, just the unsettling silence of being forgotten.

In engineering, these silent layoffs often target people who never raise their voice or their hand; those who comfortably do what they’re told and nothing more. They’re rarely the problem, but they’re rarely the solution, either. When times get tough, they’re quietly the first to go.

Meet David: The Cost of Being Passive

Let me introduce David. On paper, David was flawless: punctual, reliable, accurate. He finished tasks exactly as instructed, and rarely made mistakes.

But David rarely asked why his work mattered or how it impacted customers. He never proposed better solutions unless someone asked. He waited for direction instead of creating it. David was comfortably passive.

When the company needed cuts, leadership evaluated value differently: who was driving projects, taking risks, and shaping the product? David didn’t come to mind. His contributions were solid, but his impact was invisible.

As Larry Winget reminds us:

“You get paid for results, not effort”

David gave effort, but he lacked initiative and ownership. He followed orders, and quietly followed his career out the door.

Understanding the ‘Silent Layoff’

Silent layoffs happen when companies subtly phase out employees whose contributions aren’t visibly significant. Unlike dramatic, public layoffs, these happen quietly, slowly, and often go unnoticed until it’s too late.

Low-agency engineers aren’t disruptive or problematic, which ironically makes them more vulnerable. In good times, companies tolerate passivity. But when challenges arise, passive employees are often the first considered expendable.

Focusing only on writing code without broader impact can put engineers at similar risk. The role of coders is fading, while product-minded engineers are on the rise.

Engineers who simply “code what they’re told” are becoming less valuable in an industry that increasingly demands broader product thinking, ownership, and strategic contribution.

Share

What Exactly is High Agency?

High agency is the mindset and belief that you can actively shape your environment and outcomes, rather than passively accepting circumstances. High-agency engineers proactively solve problems, question assumptions, and drive meaningful change without waiting for permission.

High agency doesn’t mean reckless action. It means confident autonomy. It means owning not just your work but its broader impact. Low-agency engineers see their roles as tasks given, not opportunities created.

George Mack, the person behind HighAgency.com (highly recommend reading), believes that high agency might be the most important idea of the 21st century. And once you see it, you can’t unsee it.

“High agency isn’t one skill — it’s the rare combination of clear thinking, bias to action, and the courage to disagree when it matters.”

— George Mack

A Word of Caution: Don’t Mistake Noise for High Agency

Taking up airtime in meetings, posting endless Slack messages, or debating every decision without moving anything forward isn’t high agency. Being noisy without delivering outcomes can backfire just as badly as being invisible.

Real agency is about connecting action to results. It means pushing projects forward, solving real problems, and making an actual impact, not just broadcasting opinions.

Do not confuse high agency with being a hero. High agency is about making the team, the product, and the business better, not about stealing the spotlight.

Noise for the sake of attention dilutes credibility. True influence comes from thoughtful contribution and reliable execution. Engineers who confuse noise with impact burn goodwill fast—and often find themselves just as vulnerable during cuts.

The goal is not to talk more. It is to matter more.

Why Companies Quietly Cut Low-Agency Engineers

When revenue clouds gather, finance teams run a brutal thought experiment: If we lost this person tomorrow, would our customers notice before our monitoring did?

Low‑agency engineers rarely pass that test. Their work is useful but tucked so deep in the scaffolding that its impact is hard to trace.

High‑agency engineers, by contrast, staple their code to metrics that matter: conversion, uptime, cash. They steer critical projects, coach peers, and surface risks before risk surfaces them.

That ruthless logic hides in plain sight across high‑performance cultures. When budgets contract, the quiet and comfortable become the easiest cuts. Not because they’re bad, but because their absence costs the least.

How to Avoid the Silent Layoff Trap

Before adopting new behaviors, shift your mindset from “What tasks am I assigned?” to “What outcomes can I actively influence?” High agency begins internally before it’s seen externally.

Follow these five habits to stay indispensable:

1. Speak Up—Clearly and Consistently
   Quiet competence isn’t enough. Offer well‑formed opinions, ask thoughtful questions, and challenge shaky assumptions. Make your presence and perspective felt.

2. Take End‑to‑End Ownership
   Don’t just finish tasks—own outcomes. Know why they matter, who benefits, and what success looks like. When problems surface, lead the fix.

3. Translate Work into Business Impact
   Always anchor achievements in measurable value: “Optimised the cache, cutting page load by 150 ms and saving 20 % in server costs” beats “Tweaked performance.”

4. Show Initiative, Regularly
   Don’t wait for someone to hand you the next ticket. Spot gaps, volunteer for hairy problems, and propose improvements before they’re assigned.

5. Invest in Cross‑Team Relationships
   Seek perspectives outside your pod. Pair with design, chat with support, and demo to sales. Allies amplify your influence and keep your work visible when budgets shrink.

Proactivity is the hallmark of high-agency people. Rather than just reacting to issues, high-agency engineers actively seek out opportunities, spot risks before they escalate, and shape the future instead of waiting for it.

Leave a comment

Leaders: Build High‑Agency Teams

Agency starts at the top. High-agency teams don’t emerge by accident. They’re built deliberately by leaders who prioritize autonomy, ownership, and proactivity. Your processes either amplify ownership or smother it. Tilt the odds toward the former:

• Authorize, don’t approve. Push decisions to the lowest competent level and back them publicly. Trust is gasoline for agency.

• Reward smart risk. Celebrate experiments that moved metrics or taught a lesson—even if the first try failed. Punishing every misstep breeds spectators, not owners.

• Broadcast the “why.” Context is the mother of initiative. Share customer anecdotes, revenue targets, and strategic trade‑offs so engineers see the full chessboard.

• Surface dissent early. Make it safe—and expected—to challenge plans before code is poured in concrete. Silence in planning should raise questions, not be mistaken for agreement.

• Model the behavior. Unblock yourself, admit mistakes, and ship visible wins. Teams copy what they see.

Simon Sinek sums it up:

“Leadership is not about being in charge. It is about taking care of those in your charge.”

Taking care means creating a playground where smart people can act, own and thrive, loudly enough to be heard and wisely enough to matter.

Final Thoughts: Reject Passivity, Own Your Career

Careers aren’t lost in dramatic layoffs. They’re silently eroded by choosing passivity over action, comfort over challenge, and waiting over ownership.

If you recognized any part of yourself in David’s story, take it as an urgent signal to shift your approach—starting now.

High agency isn’t something you’re born with; it’s something you practice daily:

• Speak up clearly about what matters, even when it’s uncomfortable.

• Take on problems proactively, instead of waiting for instructions.

• Make your impact visible by connecting your work explicitly to meaningful outcomes.

In today’s tech market, the threat isn’t AI. It’s becoming passive and unnoticed.

Choose action over inaction, ownership over comfort, and visibility over invisibility.

Your career depends on it.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

As expected, some harsh responses poured in.

“You don’t need to ruin your health to succeed.”

“This has a toxic productivity vibe.”

“Sleep deprivation kills creativity.”

“Stop glorifying hustle.”

And they’re absolutely right.

Health matters. Sleep is essential. Burnout is real. I’m not here to romanticize exhaustion or suggest that success requires sacrificing your well-being.

But here’s what many people missed.

That image is not about self-destruction. It is about flow state. It is about being in the zone.

Some people find their best focus when the world goes quiet. After the messages stop. After the kids are asleep. When there is finally space to think. (Yes, that’s me.)

Of course, seeking luck or excellence doesn’t come from comfort alone. It comes from showing up with intentional focus. Not through burnout, but by knowing when you’re at your best and making space for it.

Not every late night is a red flag. Some are a reflection of purpose.

Let’s talk about what makes the difference.

The Magic of Flow

Have you ever sat down to work and, in just a couple of hours, accomplished more than you did the entire day before? It happens to me, more often than I’d like to admit.

That kind of productivity isn’t a fluke. It’s what psychologists call flow. Some people call it being “in the zone.” It’s a mental state where focus sharpens, distractions disappear, and time seems to bend.

Flow is a powerful mental state where you become so immersed in your work that the outside world fades away. You’re not just getting things done, you’re doing your best thinking. Ideas connect faster. You make decisions with clarity. You’re fully present, and it shows in the quality of your output.

For many of us, especially in engineering, that kind of clarity doesn’t always happen between nine and five. It tends to show up after the last meeting ends, when Slack is quiet, and your calendar finally stops demanding attention.

This isn’t about glorifying late nights. It’s about understanding the conditions that make deep focus possible. For some, that’s early mornings. For others, it’s the quiet of night. What matters isn’t when the work gets done, but how present you are when it does.

Psychologist Mihály Csíkszentmihályi, who coined the term flow, described it as:

“A state in which people are so involved in an activity that nothing else seems to matter; the experience is so enjoyable that people will continue to do it even at great cost, for the sheer sake of doing it.”

Flow doesn’t come from pressure. It comes from presence. It’s not about working harder. It’s about working with depth and clarity.

It can be hard to reach, but when it happens, you feel it. You’re immersed. Ideas connect effortlessly. You’re moving with focus and ease. And when you pause, you realize time has passed, but you barely noticed.

That’s the magic of flow. It’s rare, but when it shows up, it’s one of the most rewarding ways to work.

Productivity Is Personal: Early Birds vs. Night Owls

When it comes to productivity, there’s no one-size-fits-all schedule. Some people are sharp at sunrise. Others hit their stride long after the world winds down. Yet we still treat early risers as the gold standard, as if productivity only counts before noon.

But real productivity isn’t about conforming to the clock. It’s about understanding your natural rhythm and working with it, not against it.

I’m a night owl.

My focus doesn’t peak at sunrise. It usually kicks in after my kids go to bed, when the house is quiet and the world finally slows down. No meetings. No messages. No expectations. Just space. And in that silence, I often find flow.

Not every night. I’m not burning the candle seven days a week or entering the zone on demand. But when it happens, it’s deep, it’s creative, and it’s some of my best work.

And that’s the point.

Some people find their rhythm at dawn. Others, like me, find it after dark. One isn’t better than the other. What matters is knowing when you focus best, and protecting that time.

Trying to force night owls into early schedules doesn’t make them more productive. It just drains energy. Likewise, expecting early birds to stay sharp into the evening rarely ends well.

As Naval Ravikant once said:

“Escape competition through authenticity.”

The same holds true for productivity. When your work aligns with your natural rhythm, it becomes not only more effective but also more sustainable.

This isn’t an argument against structure. It’s a case for flexibility and self-awareness. What matters isn’t when the work gets done. It’s the quality, the intent, and the outcome.

Respect your rhythm. That’s where your best work actually happens.

Share

Busy Isn’t the Enemy. Distraction Is.

You’ve probably heard the saying: “If you want something done, ask a busy person.” It’s not because they are over-committed. It’s because they have learned how to be busy with intention.

Being busy the right way means staying focused. These are the people who carve out time for deep work, guard their attention, and say no to what does not matter. They do not confuse motion with progress. They know what deserves their energy and when.

The irony? Many of them are also the ones who make space for rest, learning, exercise, and family. They work hard, but they work smart. And they understand that productivity is not about doing more. It is about doing what matters, when it matters, with full attention.

The real enemy is not being busy. It is being distracted. It is the nonstop pings. The meetings that should have been messages. The inbox that grows faster than your focus can recover.

True productivity, the kind that actually moves the needle, requires uninterrupted focus. And for many of us, especially if you’re a people manager, that kind of space only exists at the edges of the day.

As Cal Newport wrote in Deep Work:

“Clarity about what matters provides clarity about what does not.”

It is not about doing everything. It is about protecting what matters most.

Rest Is Part of the Work: The Antidote to Burnout

Let’s not confuse admiration for flow with a celebration of overwork. Just because someone can focus deeply late at night doesn’t mean they should live in a constant state of output.

Flow is not a replacement for rest, and it’s definitely not a strategy for burnout.

The top performers I’ve worked with, whether in engineering, leadership, or creative roles, all treat rest as part of the work. They understand what elite athletes know: recovery is not a break from training. It is training.

No one expects a sprinter to run at full speed every day without rest. Champions don’t just train harder. They recover smarter. They optimize for endurance, clarity, and longevity.

The same holds true in knowledge work. Sleep is not laziness. It is cognitive maintenance. Time off is not indulgent. It is how we stay sharp, creative, and emotionally present.

Flow is powerful, but it is not endless. When it becomes forced, when it replaces connection, reflection, or self-care, it loses what makes it valuable. What once felt energizing becomes draining.

Balance is not a luxury. It is the infrastructure that allows you to do deep work without crashing. As Arianna Huffington wrote in Thrive:

“Burnout is not the price you have to pay for success.”

Rest isn’t the opposite of great work. It’s what makes great work possible.

Leaders: Design for Flow, Not Control

If you’re in a leadership role, this is where your mindset matters most. Don’t measure your team by how early they log on or how late they stay. Measure them by outcomes. By the clarity of their thinking. By the quality of their work.

Your job is not to supervise hours. It’s to create the conditions for focus.

That means protecting time for deep work. Pushing back against unnecessary meetings. Letting go of the idea that real work only happens when everyone is online at the same time.

This is one of the many reasons I love remote and async work. It acknowledges a simple truth: not everyone feels productive at the same time. Some people need quiet mornings. Others find their focus after dark. Some need long stretches of uninterrupted time. Others work best in bursts. Remote work gives them the space to find their rhythm and own their results.

Synchronous work can be useful but defaulting to it stifles autonomy and flow. Leaders need to stop confusing constant visibility with real productivity.

Engineers don’t need more check-ins. They need more trust. They don’t need more structure. They need more space.

If you want high performance, build an environment where flow can happen, and then step aside and let it.

Jason Fried, in It Doesn’t Have to Be Crazy at Work, put it bluntly:

“Modern-day offices have become interruption factories… How can you expect anyone to get work done in an environment like that?”

The best teams don’t thrive in noise. They thrive in focus. And it’s your job to protect it.

Final Thoughts

Doing your best work isn’t about pushing harder. It’s about knowing when you’re at your best and creating the space for it to happen.

Sometimes that looks like a glowing window at 2 a.m. Sometimes it looks like a quiet morning with no meetings. What it doesn’t look like is forcing everyone into the same mold, schedule, or rhythm.

Flow is personal. Productivity is personal. And the environments we build, both for ourselves and for our teams, should reflect that.

Great work is not the result of nonstop hustle. It’s the outcome of clarity, intention, and trust. It comes from aligning effort with energy, not sacrificing health for output. And it lasts longer when it’s built on rest, not burnout.

So if you find your flow late at night, or in the early morning, or in between school runs and quiet afternoons, that’s not something to fix. That’s something to protect.

Your best work lives there.

Make space for it.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Imagine waking up tomorrow to find automation has taken over your software development job.

No more writing repetitive boilerplate code, debugging tedious errors, or wrestling with yet another JavaScript framework. Scary? At first glance, sure. But if you’re honest, there’s a hint of relief in there too.

Everyone seems terrified about losing their jobs to Artificial Intelligence (AI), and I get it. But I’m not afraid. In fact, I’m excited.

Why spend time on tasks machines do better when I could focus on strategy, creativity, and solving complex, meaningful problems?

Welcome to the end of the “coder.”

But before you panic, trust me: this is actually great news. Let me explain why.

The Historical Pattern of Automation

“The factory of the future will have only two employees: a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.”

— Warren Bennis

Automation isn’t new. Every major technological revolution has sparked fears of job losses. The Industrial Revolution, for example, caused panic over the disappearance of manual labor. People worried about losing tedious, repetitive tasks like hand-harvesting crops or manually assembling machinery.

But let’s be honest, do you really miss manual harvesting or lifting heavy machine parts by hand? Probably not.

In reality, automating those tasks freed workers to take on more meaningful, less physically demanding roles. It also paved the way for entirely new industries and job categories.

Similarly, the so-called “end of coders” isn’t the end of software engineers. It simply means that the repetitive, mundane parts of the job will no longer impede real innovation.

My First Job as a “Coder” Made Little Sense

“Programmers are not typists. Typing is not the bottleneck.”

— Kent Beck

As I wrote in one of my first articles, in 2004 I started my first job as a “coder”. My role was to translate highly detailed spec sheets into code. Every input, output, and function was predefined by my analyst literally on a paper sheet. There was minimal scope for independent thought, creative ideas, or my own choices.

One day, I asked my analyst (who was also my manager):

“Aren’t you spending more time writing this spec sheet than it would take to just write the code yourself?”

He replied:

“Yes, I could write the code faster but this is the only way you’ll learn to code.”

Technically, he was right; I was learning to code. But I wasn’t learning about how to solve software engineering problems. And the process, while well-intentioned, was painfully inefficient for everyone.

Fast forward to today, software engineers are no longer just coders. They are expected to think critically, solve complex problems, collaborate across teams, and influence product decisions.

Despite this shift, many still spend most of their time writing code, stuck in a cycle of translating instructions and repeating predictable tasks. Even at senior levels, the complex and meaningful challenges that drew us to the field often remain out of reach.

AI Won’t Take Your Job. It’ll Take Your Boredom

“AI won’t take your job. It’s somebody using AI that will take your job.”

— Richard Baldwin

AI has already started replacing repetitive tasks across countless industries. In software development, AI tools can now effortlessly write code, perform routine debugging, and even suggest optimized code solutions faster than most humans.

If your job mainly involves translating clearly defined tasks into code, you’re essentially competing against a machine. Spoiler alert: the machine will eventually win.

But here’s the good news: AI won’t replace creativity, ingenuity, and strategic thinking, at least in the short-term.

The core of software engineering has never truly been about writing the code. It’s always been about problem-solving.

Creating Solutions, Not Just Writing Code

“The engineer’s first problem in any design situation is to discover what the problem really is.”

— Unknown

Let’s imagine a different future. Instead of spending hours writing predictable CRUD operations or integrating APIs, engineers could describe an application in natural language and watch as AI instantly generates optimized, reliable code.

In this AI-driven era, engineers evolve into architects, creators, and strategists. Our role shifts from writing every line of code to envisioning new possibilities, designing thoughtful systems, and solving problems AI alone can’t yet understand or fully address.

Rather than debugging obscure syntax errors late at night or chasing the latest framework, we’ll focus our energy on crafting solutions that truly matter. We’ll build products that transform healthcare, education, sustainability, and countless other vital areas of society.

This is our opportunity to innovate, create, and push the boundaries of what’s possible, beyond code.

Embracing the Shift (and Loving It)

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”

— Charles Darwin

I hear you, change can feel scary. Especially when it challenges the skills we’ve spent years mastering. But the most impactful engineers have never just been coders. They’ve been problem-solvers, creators, innovators, and builders of the future.

This shift away from manual coding isn’t about losing what we love. It’s about making room for more of what we came here to do. More creativity. More collaboration. More space to design experiences, shape products, and imagine new possibilities.

We’re not stepping back, we’re stepping up. From execution to invention. From syntax to strategy.

It’s time to let go of the fear and embrace the evolution. Because coding was never the destination, it was just the starting point for something far greater.

Should We Still Learn to Code?

“Everyone should learn how to program a computer because it teaches you how to think.”

— Steve Jobs

Absolutely. But maybe not in the way we’ve traditionally thought about it.

Learning to code is still crucial. It teaches logic, problem-solving, and structured thinking. Understanding code gives you insight into how software works, helping you collaborate effectively and leverage the power of automation and AI.

The key is to shift the focus. Instead of emphasizing writing endless lines of code, focus on understanding system function, architecting effective solutions, and communicating your ideas clearly.

In the future, coding may be less about writing everything yourself and more about orchestrating systems, automating the mundane, and building products people love.

In other words, we’re entering the era of the 100x Product Engineer.

Final Thoughts

“It was never about coding. It was always about solving problems that truly matter.“

— Rafa Páez

The end of coding isn’t really the end. It’s a new beginning. A chance to redefine what it means to be a software engineer and focus our talents where they matter most.

Imagine what we can achieve when we’re no longer bogged down by repetitive tasks. Imagine the applications we can build, the problems we can solve, and the innovations we can unleash.

So let’s welcome this change. Let’s leave the code to the machines and direct our energy toward solving the complex, fascinating, and impactful challenges of our world.

The future of product engineering is bright, and it doesn’t require you to write every line of code yourself.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Let me guess: someone asked for an estimate this week, didn’t they?

It always starts innocently enough:

“Hey, can you give me a quick estimate for this project?”

It sounds harmless. But hidden in that simple question, there is a can of worms just waiting to explode all over your roadmap, your priorities, and your engineering team’s sanity.

If you’ve been around long enough in tech, you’ve probably lived some version of this drama. The characters may vary, but the scene is all too familiar.

The Broken Conversation

For context:

• PM here could be a Product Manager, an internal stakeholder, or even an executive. They usually represent the “what” and “why” of a project.

• TL stands for Team Leader (or Tech Lead), the engineering voice responsible for guiding the team on the “how” and “how long.”

Let’s drop in on a typical exchange:

PM: Hey! I need an estimate for the Y project.

TL: Seriously? We’re already swamped with the X project.

PM: This comes straight from leadership—I need it tomorrow.

TL: Fine. We’ll see if we can squeeze it in.

(Next day)

TL: It’ll take around 4 weeks.

PM: Four weeks? That’s too long. It should only take two.

TL: Then why did you even ask? Just pick a number next time!

PM: Don’t get defensive. Leadership expects it in two weeks, so make it happen.

TL: Not my problem if leadership can’t handle reality.

PM: This attitude isn’t helping anyone.

Sound familiar?

What Went Wrong?

The PM just wants to keep things moving. The TL is trying to protect their team from being crushed under impossible expectations. Leadership needs velocity. Engineering needs clarity. But instead of pulling together, everyone ends up pulling apart.

Team Leader Mistakes

• Started with defensiveness instead of curiosity or alignment.

• Didn’t clarify trade-offs, just dropped a number with no reasoning.

• Reacted emotionally, escalating conflict instead of managing expectations.

Product Manager Mistakes

• Demanded an estimate without having the work clearly defined first.

• Used urgency as pressure, not as context for collaboration.

• Challenged the estimate without understanding how it was made.

• Treated the estimate as a commitment, not a conversation starter.

This happens because we’re often trying to answer the wrong question. We think we need better estimates. But we actually need better “shaped” work.

The Estimate Trap

Estimates have always divided the software world. Some see them as essential for planning. Others view them as unreliable guesses wrapped in false confidence.

The #NoEstimates movement, championed by , challenges the need for estimates entirely. It argues that estimating delivery dates based on early lists of features or stories leads to waste, misalignment, and mistrust—and that teams are better off delivering value incrementally.

But most experienced engineers and product leaders agree:

Too often, estimates become promises. As if engineering had a simple formula:

estimate(feature_or_project) => duration_in_days

But estimating without shaping the work is like guessing how long it takes to build a house without knowing if it’s a cottage or a skyscraper.

You get vague input. You throw out a number. That number becomes the expectation. And when reality doesn’t match? Blame, fire drills, and broken trust follow.

Deadlines Aren’t the Enemy

There’s a crucial distinction:

• Estimates ask: “How long will this take?”

• Deadlines say: “We’re willing to spend this much.”

Think of a deadline as a budget of time and resources.

“This idea is worth two weeks of our time. What’s the best value we can deliver within that budget?”

That shift in mindset reframes deadlines from pressure into strategic investment. You’re not guessing. You’re deciding how much to spend and asking what’s achievable within that limit.

It leads to:

• Smarter prioritization

• Scoped-down, realistic outcomes

• Team autonomy

• More predictable delivery

Instead of asking, “How long will Feature Y take?”, ask:

“We have a two-week budget—what’s the best version we can build with it?”

This approach avoids over-promising based on shaky assumptions.
It empowers teams to make thoughtful trade-offs and deliver with confidence.

Cooking Analogy: Estimate vs Deadline

You’ve got 1 hour before a meeting and want to eat something healthy.

Estimate mindset:

“This curry looks good—how long will it take?” The recipe says 45 minutes. Halfway in, you're missing ingredients. You run out of time.

Deadline mindset:

“I’ve got 1 hour—what can I cook that’s healthy and doable?” You scan the kitchen, make a stir-fry or salad, and show up fed and on time.

Deadlines don’t lower the bar—they sharpen your focus.

In product work, the same principle applies:

• Fix the time, shape the scope → momentum and clarity

• Fix the scope, estimate the time → stress and misalignment

What Is Shaping, Anyway?

If you’ve read Shape Up by Ryan Singer, this concept will sound familiar. But even if you haven’t, it’s pretty intuitive:

“Shaping is work that happens before the cycle begins, to set boundaries on what the team will be asked to deliver. It involves defining the problem, roughing out the solution, and addressing risks before committing to build it.”

— Shape Up, Ryan Singer

The Three Properties of Shaped Work

Shaped work has three essential characteristics:

• Rough: It’s intentionally unfinished, giving designers and developers the flexibility to apply their expertise and handle real trade-offs during implementation.

• Solved: Even though it’s rough, the core solution is thought through at a macro level. There’s enough direction to guide the work, and foreseeable risks have been addressed.

• Bounded: It includes clear limits. It defines what not to do and fits within a specific time frame—known as the “appetite.” This helps keep scope in check.

These traits give the team room to make decisions while staying aligned with the problem and constraints, reducing risk and increasing focus.

The Four Core Steps of Shaping

1. Set boundaries: Decide how much time the idea is worth (the appetite) and define the core problem you’re solving.

2. Rough out the solution: Sketch a high-level approach without diving into detailed specs or wireframes.

3. Address risks: Identify edge cases, technical unknowns, or gaps that could derail the project or lead to open-ended work.

4. Write the pitch: If the idea still looks viable, summarize it in a short pitch that outlines the problem, the solution, key constraints, and any identified risks.

Shaping Together: Product, Design, Engineering

Shaping isn’t a solo mission. It works best when Product, Design, and Engineering shape the work together—before it ever hits the development cycle.

Each role brings something valuable:

• Product Managers bring context and priorities.

• Designers bring user empathy and interaction thinking.

• Engineers bring constraints, edge cases, and technical trade-offs.

This collaboration helps surface blind spots early. It prevents scope blow-ups later. And it leads to a better solution—because everyone helped shape it.

As Fred Brooks famously said:

“Plan to throw one away; you will, anyhow.”

Shaping helps you throw away the wrong idea before any code gets written.

Why Shaping Matters

In simple terms, shaping is about scoping the work before it reaches the engineering team. You’re not asking engineers to build—or estimate—something that’s undefined. You’re giving them a solvable, constrained problem.

It’s not waterfall. It’s not months of documentation. It’s just enough structure to move forward with confidence.

Instead of asking, “What will it take to build Feature Y?”, you ask:

“Here’s the user problem, here’s how much time we’re willing to spend, and here’s a rough idea of how to solve it.”

This flips the conversation from guessing to collaborating.

Fixing the Conversation: Two Better Ways Forward

Estimates and deadlines often drive the conversation around software projects. But without clear boundaries and defined scope, they lead to confusion and friction. So how do we fix it?

Here are two clear, collaborative ways to handle this:

Approach 1: Appetite-Driven (Shape Up Method)

Start by setting a fixed time boundary—your appetite—and then shape the project accordingly. This approach doesn’t rely on estimating how long work might take. Instead, it scopes the project to fit within your defined timeline.

PM: We’re looking to tackle Problem Z with Project Y. Leadership values delivering something impactful in about two weeks. Can we shape this together to see what’s achievable?

TL: Great clarity. Given our workload with Project X, let’s review priorities and see what fits within two weeks.

(Next day)

TL: We’ve shaped something valuable that fits into two weeks, but it means deferring some features. Here’s what’s feasible…

PM: Excellent. I’ll present this scoped version to leadership.

This conversation aligns the team around a realistic goal and shared constraints, making collaboration easier.

Approach 2: Shaping First, Estimating Second

Alternatively, shape the solution first, then estimate the effort needed. Here, estimation happens only after you’ve collaboratively defined the work clearly.

PM: We want to address Problem Z with Project Y. Could you help shape the solution so we can estimate it accurately?

TL: Absolutely. Let’s first define what success looks like and break down the main components clearly.

(Next day)

TL: After shaping the solution, we estimate roughly 3 to 4 weeks, depending on certain implementation details. We’ve also identified some potential risks.

PM: Perfect. This gives us clarity to prioritize and adjust scope accordingly. Let’s move forward.

This approach ensures estimates are realistic and rooted in a clear understanding of the work.

Both paths prioritize clarity and collaboration, helping your team replace guessing games with structured, meaningful discussions.

Final Thoughts

Whether your team prefers working within a fixed time box or estimating after shaping, the real game-changer is clarity:

• Clarity on the problem.

• Clarity on constraints.

• Clarity on what success looks like.

Shaping gives you that:

• It replaces guesswork with grounded conversations.

• It turns conflict into collaboration.

• It creates space for engineering and product to work as partners—not opponents.

So the next time someone says, “Can you estimate this real quick?”—pause. Smile. And ask:

“Can we shape this first?”

Because the fastest way to deliver value isn’t rushing to a number. It’s understanding the work well enough to make a real bet.

P.S. If this resonated, forward it to your favorite PM, TL, or anyone who still believes shipping starts with a number. Let’s shape smarter, together.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Traditional management is dead. Old ways of managing people and leading teams no longer work.

Conventional leadership models—rooted in hierarchy, rigid processes, and top-down decision-making—are increasingly falling short.

The tech industry moves at lightning speed. We’re experiencing the rise of the 100x Product Engineer and many leaders operate in Founder Mode.

To stay relevant in today’s fast-moving world, managers and leaders need to embrace “Vibe Leading”.

Let’s explore what that looks like in practice.

Introducing Vibe Leading

Vibe Leading is a term I’ve been thinking about recently, inspired by Vibe Coding. But it’s not just about using Generative AI to be more efficient, make faster decisions and lead effectively. It’s about tuning into the energy, emotions, and dynamics of your team—observing the vibes.

While modern leaders should embrace tools like Generative AI and Large Language Models (LLMs) to stay effective and make smarter, more tailored decisions, Vibe Leading goes beyond technology. It’s about sensing shifts in team dynamics, reading the room, and aligning emotional awareness with business needs.

Vibe Leaders use intuition, empathy, and adaptability to guide their teams—not just to keep up with rapid change, but to drive innovation that serves both people and purpose. AI is part of the toolbox, but real leadership comes from human connection.

Traditional management—rigid plans and strict oversight—often slows teams down and stifles creativity. Today’s engineering challenges are too complex and fast-moving for one-size-fits-all solutions.

Importantly, Vibe Leading isn’t about abandoning structure. It’s about blending:

• Flexibility with clarity.

• Empathy with accountability.

• Intentional guidance with autonomy.

This balanced approach helps leaders stay attuned to their team’s energy and rhythm—ensuring they remain agile, creative, and genuinely motivated.

What Vibe Leading Isn’t

Vibe Leading isn’t about being impulsive or skipping the basics. Just like “vibe coding” can lead to bugs if done without understanding, Vibe Leading can go wrong if misused.

Relying only on intuition—without clear communication, accountability, or guidance—can cause confusion and misalignment. Vibe Leading doesn’t replace planning, critical thinking, or responsibility.

Strong leadership foundations and experience matter. Leaders need solid skills like strategy, decision-making, and conflict resolution. When done right, Vibe Leading adds flexibility and emotional intelligence to strong, thoughtful leadership.

Why Vibe Leading Matters

Nowadays, engineering teams move extremely fast—they have to. They innovate, adapt, and evolve constantly. Leaders who stick to rigid hierarchies, slow approvals, and micromanagement end up slowing things down.

Today’s engineers “vibe code”—they work using creative LLM prompts, iterate quickly, and collaborate fluidly. Leaders need to match that energy by being empathetic, adaptable, and tuned in to team dynamics.

Vibe Leaders don’t wait for one-on-one's or retros to solve problems. They sense shifts early, respond quickly, and keep things moving. This prevents issues from growing and keeps the team focused and energized.

Vibe Leading matters because it turns managers and leaders into enablers of innovation—keeping teams inspired, aligned, and ready for whatever comes next.

Share

Core Principles of Vibe Leading

Great Vibe Leaders live by a few essential principles. These principles guide them in consistently driving innovation, team cohesion, and sustained success:

1. Embrace Adaptability: Recognize that uncertainty is inevitable. Swiftly adapt your strategies and approaches as conditions evolve, staying responsive and agile. And remember, change is constant.

“Adaptability is about the powerful difference between adapting to cope and adapting to win.”

— Max McKeown​

2. Cultivate High Agency: Foster a culture where team members feel empowered to take initiative, own their decisions, and drive impactful outcomes with resilience and perseverance.

“If your ship doesn’t come in, swim out to meet it.”

— Jonathan Winters​

3. Don’t Shield, Strengthen: Instead of blocking every challenge, help your team grow by facing them. Resilience, confidence, and problem-solving skills are built through experience, not over-protection.

“Smooth seas do not make skillful sailors.”

— African Proverb

4. Lead with Intent, Not Control: Clearly communicate the direction and purpose, empowering and trusting your team to find their paths to achieve shared goals without micromanagement.

“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”

— George S. Patton

5. Develop Leaders, Not Heroes: Invest in building leadership qualities across your entire team. Great leaders multiply their impact by nurturing more leaders, rather than relying on individual heroics.

“The function of leadership is to produce more leaders, not more followers.”

— Ralph Nader

6. Combine Strategy and Tactics: Pair strategic vision with rapid execution to keep your team aligned and moving fast. This balance drives high-quality results without losing sight of the bigger picture.

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.”

— Sun Tzu

7. Lead with Principles Over Processes: Use clear, adaptable principles to guide your team, enabling innovation and smart, independent decisions without relying on rigid rules or processes.

“Policies are many, Principles are few, Policies will change, Principles never do.”

— John C. Maxwell

These principles help Vibe Leaders navigate complexity, foster genuine team connections, and amplify collective business impact.

Becoming a Vibe Leader

Vibe Leading starts with self-awareness and intention. Reflect on your current leadership style—are you relying too much on rigid rules? Are you tuned in to your team’s emotions, needs, and dynamics?

Be open about your goals and invite honest feedback. Talk about the values you want to lead with—like adaptability, agency, and empowerment—and involve the team in shaping those principles together.

Stay flexible. Pay attention to the signals your team sends, and regularly check if your actions match your values. Embrace change with resilience and lead with calm confidence, even in uncertain times.

Empower your team by trusting them with clear responsibilities. Encourage ownership by letting them take initiative and make decisions. Guide when needed, but avoid jumping in to fix everything.

Balance long-term vision with day-to-day speed. Keep your goals clear, but stay open to adjusting your path as things evolve.

Finally, grow future leaders. Mentor intentionally, celebrate team wins over individual ones, and foster a culture of continuous learning and shared success.

Final Thoughts

Vibe Leading isn’t just a new style. It’s a necessary shift for leading in today’s era of rapid innovations.

To succeed, you need to connect with your team on a deeper level. Pay attention to their needs. Adapt as things change. Empower them to grow and do their best work.

When you lead this way, you move beyond managing tasks. You start inspiring innovation and real growth.

The future of leadership is about unlocking the energy, creativity, and potential of your team to achieve outstanding business results.

Embrace the vibe: lead with intention, empathy, and clarity. Build teams that don’t just perform—they change industries and redefine success.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Jose is the author of , one of my favorite newsletters about Data Engineering, Data Science and Leadership!

Senior Data Science Lead

Helping managers build world-class teams, data professionals master storytelling and guiding those looking to break into Data Science. I have built teams from scratch and lead 50+ data scientists. Now, I share my experience with you.

By Jose Parreño Garcia

Thank you, Jose, for sharing your experiences, lessons, and insights with all of us.

"What gets measured gets managed." But, what if we are measuring the wrong things?

In most organisations, revenue, cost and user driven metrics (acquisitions or retention) are the North Star metrics. And, if you build solutions that significantly move these, then, of course you should be recognised.

However, not all impact is equal. Today, I want to share with you 5 real stories where traditional impact measurement falls short. Each story will challenge a common assumption:

1. The £1M that wasn’t fully recognized. Why a machine learning improvement that generated $1M in revenue wasn’t considered strategic.

2. The £1M that was recognized (and why context matters). A parallel example where a similar financial outcome led to much greater recognition.

3. The problem with recognition-based impact. How a team that provided company-wide enablement received 10x the visibility but wasn’t necessarily creating 10x the impact.

4. The challenge of measuring slow-moving metrics. Why long-term improvements often go unrewarded, even when they fundamentally change an organisation’s capabilities.

5. The amplifier effect: impact that multiplies over time. How a single contributor reshaped engineering standards and de-risked projects without producing a measurable metric.

Story #1: Flights ranking: the £1M that wasn’t fully recognized

"A £1M revenue boost sounds like a success story. So why wasn’t it enough?"

Let’s start with a case that should, on paper, be an easy win.

One of our senior data scientists was working on flights ranking, a core component of how we optimize search results for travelers. The goal was to improve how we rank flight options, leading to better user engagement and, ultimately, higher conversion rates.

They successfully deployed an experiment that increased redirect rates by small percentage, but leading to an additional £1M in annualized revenue.

A million dollars. That is real, measurable impact.

So, why wasn’t this a clear-cut recognition case?

The issue wasn’t the outcome. It was how the result was achieved.

Instead of developing a novel ranking approach or strategically enhancing our model, the senior data scientist relied on brute-force optimization. The approach itself required persistence, patience, and solid execution, but not deep innovation.

And to be clear: this is not a bad approach. It’s a completely valid way to optimize machine learning models. In fact, for a junior or mid-level data scientist, this would be an outstanding contribution. But for a senior? The expectation is not just to find a better model, it’s to think more strategically about how we get there.

(PS: If you are interested in knowing more about our competency framework, check this article where I go into it in detail)

Recognition vs. long-term strategic growth

This is where the distinction between recognition and career progression becomes important.

• Recognition is deserved. This person delivered real business value. It’s entirely reasonable to acknowledge their effort. A stronger bonus or public appreciation are great ways of doing so.

• But was it a promotion-worthy achievement? Not necessarily. Strategic, senior-level impact goes beyond just testing variations. It involves pushing boundaries, introducing new frameworks, or fundamentally improving our approach.

If we start promoting based solely on absolute impact, without considering how the impact was achieved, we set the wrong precedent:

• We risk incentivizing brute-force, low-leverage solutions instead of encouraging deep problem-solving.

• We signal that optimization work alone is enough to climb to the next level.

• We fail to differentiate between impact that any capable data scientist could achieve and impact that truly redefines our competitive advantage.

So, the real challenge is to figure out if we are rewarding results, or are we building a culture that encourages the right kind of impact?

Next, let’s look at another £1M success story—but this time, one that was fully recognized.

Story #2: Hotel ranking: the other £1M, but this time, it was recognised

"Two teams. Two ranking models. Two £1M revenue boosts. So why was this one seen differently?"

On the surface, the outcomes look identical. The flights ranking experiment and the hotel ranking project both increased revenue by $1M per year. But the effort, complexity, and long-term impact of the two could not have been more different.

• They had to design and implement a brand-new ranking system from scratch.

• They worked cross-functionally with engineers, data scientists, and product teams to get it production-ready.

• They integrated machine learning models, heuristics, and operational constraints to ensure accuracy.

The heuristics they initially used may not have been more complex than the brute-force approach used in flights ranking. But the difference is they weren’t just iterating on a model; they were creating the entire infrastructure that powered ranking.

Same financial impact, but a different kind of work

So why did this team receive more recognition than the flights ranking team? Because absolute impact isn’t the only factor. Context matters.

• Flights Ranking was an optimisation. They tuned parameters and ran brute-force experiments to squeeze out incremental gains.

• Hotel Ranking was an architectural rebuild. They created an entirely new framework that could support further innovation.

When evaluating impact, we need to ask:

1. Is this solving a high-leverage problem? The hotel ranking system improved not just one model but the entire infrastructure, unlocking future enhancements beyond this single £1M win.

2. Does this scale beyond the immediate project? The new system can support future features and ML improvements, creating a compounding effect.

3. Is this work foundational? Unlike a parameter tweak, this was a major system investment that elevated our ranking capabilities across the company.

In this story, the key element is that we ensured that we recognised and rewarded work that raised the bar.

Next, let’s shift the conversation from financial impact to another flawed metric: recognition-driven measurement.

Story #3: Enablement teams: The problem with visibility-based recognition

"If a team gets 10x more public praise, does that mean they are 10x more impactful?"

So far, we have examined impact through the lens of measurable business value. But what happens when impact is measured by recognition rather than actual contribution?

This is where visibility bias comes into play.

In our data science discipline, we have a centralised enablement team responsible for maintaining and improving our A/B testing statistical engine.

As part of their role, they:

• Provide support for teams across the company running experiments.

• Host “green flag” Q&A sessions to help teams interpret results.

• Ensure that our internal experimentation framework is used correctly.

Because of their cross-functional nature, they interact with far more teams than a typical data science squad. And since they are often solving urgent, visible problems, they receive a great amount of recognition.

We have an internal “high-5” system where employees can send thank-you notes and public appreciation to colleagues. It’s a great tool for celebrating contributions, but if we were to measure impact by sheer number of high-5s, the enablement team would outperform every other team by an order of magnitude.

• Does that mean they are 10x more impactful than a team working on core ranking models?

• Does that mean they should be prioritized for promotions over others who work on complex, but less visible, problems?

Of course not. But this is exactly what happens when we conflate recognition with impact.

So, how do we know if enablement teams are overperforming?

This doesn’t mean the enablement team isn’t valuable. Let me be clear: they are. Their role is to amplify the effectiveness of others. But measuring their impact solely by recognition would be like judging an engineer’s effectiveness by the number of Slack messages they send.

Instead, a good way of looking at contributions from enablement teams would be:

• Look at the multiplier effect: how much do they improve the quality of experimentation across the company?

• What tooling did they ship that helped teams move forward in new ways?

• How many green flag duties do they have to cover? Paradoxically, if the platform was perfect, the team wouldn’t get too many urgent requests.

Next, let’s look at another case where traditional impact measurement falls short: slow-moving metrics that take years to show their full value.

Story #4: Slow metrics, where long-term impact is hard to measure

"If a team spends three years improving a system, but the results come in tiny increments, does that make their work any less valuable?"

Some of the most important work in a company happens slowly, bit by bit, over months or even years. If we are not careful, we risk undervaluing it simply because it doesn’t fit neatly into quarterly or annual reporting cycles.

The flight price calendar: A 3-year effort with an astonishing result

One of the most complex challenges in flight meta-search is accurately estimating flight prices over time. Imagine a traveler looking at our calendar view, where they can see estimated prices for flights across an entire month or even a full year.

Seems straightforward, right? I can tell you, it is not.

• Flight prices change constantly, sometimes multiple times per day.

• We don’t always have real-time data for every date, meaning we need to estimate missing prices.

• Users expect accuracy. If they see a flight for £60 on the calendar but land on a page where it’s suddenly £80, they lose trust in our platform.

For years, our coverage accuracy metric hovered at 40%. Because of that, our calendar view was super sparse, as we didn’t want to fill it with prices where we knew that 60% of the times they were wrong.

A dedicated team spent 3 years improving this system.

• They developed new estimation techniques to increase accuracy.

• They improved how we pull and refresh pricing data at scale.

• They fine-tuned coverage algorithms to ensure fewer gaps in the calendar.

And after 3 years of continuous work, they raised the accuracy metric from 40% to 80%.

Why this work was at risk of being overlooked

This improvement happened bit by bit, quarter by quarter. No single release made a giant, eye-catching difference overnight. But when you zoom out, the impact is undeniable:

• 80% accuracy means a dramatically better user experience.

• Users trust the calendar view more, increasing engagement and bookings.

• The foundation is now in place for future improvements, making our pricing system far more scalable.

If we are not intentional, slow-moving improvements like this get ignored because:

1. We expect impact to be immediate. Quarterly results dominate decision-making, making multi-year investments seem “less urgent.”

2. It’s hard to tie improvements directly to revenue. Unlike an A/B test that increases conversions by 1%, this work supports many different downstream impacts.

3. Incremental gains are harder to “sell” internally. A team that says, “We improved accuracy from 40% to 43% this quarter” sounds less impressive than one that says, “We ran an experiment that made $500K.”

So, next time, ask yourself if you are looking at the full picture, not just quarterly snapshots? If you are recognising compounding improvements, even if they take years? Or, if you are valuing long-term thinking as much as short-term wins?

Finally, let’s look at an even harder-to-measure form of impact: The Amplifier Effect.

Story #5: The amplifier effect

"What if the most valuable work doesn’t move a single metric—but makes everything better?"

We have explored cases where impact was measured incorrectly, undervalued, or too slow to be appreciated. But what about work that doesn’t have a direct metric at all? Work that multiplies the effectiveness of others, but is never attached to a single person’s performance review?

A Data Scientist who transformed engineering standards

One of the most impactful people on my team wasn’t a senior engineer or a principal scientist. She was a mid-level data scientist who saw a problem, took ownership, and quietly reshaped how we worked.

• She noticed that our engineering standards for Git repos, data storage, and other core infrastructure were inconsistent.

• Instead of waiting for someone else to fix it, she took the initiative to improve them.

• She reached out to senior engineers for guidance, learning how to implement best practices properly.

• She built a new, standardized approach that the team agreed was the right way forward.

The improvements weren’t tied to a specific revenue goal. They weren’t even officially on the roadmap. But, they made everything smoother, faster, and more maintainable.

Then, came the most important part. Instead of moving on to another project, she focused on spreading what she learned.

• She trained 3 other teammates on the new framework.

• She ensured no single person was a bottleneck for this knowledge.

• She created a standard approach that future projects could build on.

The problem with traditional impact measurement

If you judged her performance by standard metrics, her work didn’t show up anywhere.

• She didn’t build a new model.

• She didn’t deliver a direct revenue increase.

• She didn’t improve an existing KPI.

But what she did do was de-risk future projects, improve team efficiency, and level up the entire organization. And as part of our competency framework, she nailed the “expertise” and “build it right” sections for her level. Thus, was accordingly rewarded with a great bonus and more challenges that would set her up to a promotion path.

Rethinking how we measure impact

"Not all impact is measurable. And not all measurable impact is equal."

I hope you have enjoyed my 5 stories that challenged me personally to change the way I was defining impact. To summarise them:

• Impact isn’t just about revenue. Two $1M projects can have vastly different strategic value.

• Visibility doesn’t equal value. The loudest contributions aren’t always the most important.

• Slow-moving progress matters. Some of the most critical work takes years to show results.

• Amplifiers shape the future. The best contributors don’t just create impact—they enable it at scale.

If we only reward what is easiest to measure, we risk deprioritizing foundational work, discouraging long-term thinking, and failing to recognize those who make the entire system better.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Deadlines tighten. Backlogs grow. Leadership urges you to push harder. You comply—only to witness productivity stall, morale collapse, and your best engineers eyeing the exits.

What went wrong?

While it seems intuitive that pushing harder should increase output, productivity doesn’t scale linearly with pressure. Instead, it follows an inverted-U curve:

• Underworked: Low pressure leads to boredom, disengagement, and sluggish results.

• Overworked: High pressure causes burnout, reduced productivity, and unhappy teams.

• Optimal Zone: Healthy pressure sparks engagement, creativity, and sustained performance.

Your challenge as a leader is to keep your team in this optimal zone. Easier said than done, especially under escalating business demands.

Let’s explore why this happens—and how you can address it proactively.

Understanding the Productivity Paradox

“Teams are like rubber bands—useful tension drives progress, but overstretching breaks them.”
— Adapted from Yerkes-Dodson Law

Engineers thrive on challenges. Teams excel when they’re stretched just enough to stay motivated, engaged, and continually learning. Healthy tension fuels innovation and progress, but there’s a critical tipping point:

When pressure becomes excessive, productivity doesn’t rise—it collapses. High stress leads to declining morale, reduced creativity, increased mistakes, and turnover. Even your most committed engineers lose motivation, hurting both immediate output and long-term effectiveness.

The goal is clear: find the sweet spot between productive challenge and harmful stress.

The PACE Framework for Sustained High Performance

“If you can’t measure it, you can’t improve it.”
— Peter Drucker

Managing workload and productivity sustainably requires clear, actionable metrics. The PACE framework combines both quantitative and qualitative insights, enabling managers to keep teams in a high-performance zone without risking burnout.

PACE stands for:

• P – Productivity Metrics
  Measure productivity using clear indicators such as deployment frequency, lead time for changes, and perceived rate of delivery. Watch for the point at which these metrics peak and start to decline.

• A – Attitude and Morale
  Track how team members feel about their work through regular one-on-ones, anonymous surveys, team health checks, or engagement scores (such as eNPS). Healthy morale correlates with better output.

• C – Capacity Utilization
  Monitor workload distribution to maintain a sustainable pace. Compare the amount of planned tasks versus unplanned tasks, since an excess of unplanned work may indicate inefficiencies or high technical debt.

• E – Errors and Escalations
  Track bugs, defects, incidents, escalations, rework and perceived software quality. Rising error rates often signal that teams are stretched too thin, making early detection and resolution essential.

Putting PACE into Action for Sustainable Results

“Action is the foundational key to all success.”
— Pablo Picasso

Simply knowing about PACE isn’t enough; it must be woven into day-to-day leadership. Below are practical steps for implementing the framework and ensuring sustained performance:

1. Establish Baselines: Gather initial data across all four dimensions—productivity, morale, capacity, and errors—over a 4–6 week period. These baselines serve as reference points.

2. Define Thresholds and Alerts: Set clear triggers for each metric. When numbers rise or fall beyond predefined limits, it signals the need for intervention.

3. Schedule Regular Check-ins: Conduct weekly or biweekly reviews to discuss:

   • Productivity Metrics (e.g., deployment frequency, lead time)

   • Capacity Utilization (team capacity, plan vs. unplanned work)

   • Errors and Escalations (defects, incidents, overall quality trends)

   • Team Morale and Well-Being (candid conversations about engagement)

4. Share Insights with Leadership: Present data-driven reports that clarify the team’s status. This transparency helps align decisions and priorities at the leadership level, reducing the risk of misguided top-down pressure.

5. Adjust and Recalibrate Proactively: Adapt workloads, priorities, and resources based on the signals PACE provides. If a particular metric crosses its threshold, take early action to prevent burnout or dips in quality.

Empowering Teams to Perform at Their Full Potential

Burnout is a real concern, but not every team works at full capacity. Some are close to their breaking point, shown by rising errors, frequent escalations, and declining quality. Others have room to improve efficiency, productivity, and speed. Recognizing which situation applies is the first step to effective leadership.

Determining When and How to Push for Greater Outcomes

“A good objective of leadership is to help those who are doing poorly to do well and to help those who are doing well to do even better.”
— Jim Rohn

When a team has untapped potential, the goal should not be to push indiscriminately. Instead, push more effectively by clarifying expectations, removing bottlenecks, and fostering accountability:

• Clarify Expectations: Make sure everyone understands what high performance looks like, then set clear, measurable goals.

• Eliminate Bottlenecks: Identify inefficiencies—slow processes, excessive meetings, unclear ownership—and remove them to maintain momentum.

• Improve Focus: Reduce distractions, cut unnecessary work, and give engineers time for deep, uninterrupted work.

• Challenge Growth: Stretch teams beyond their comfort zone with ambitious but achievable targets that spur development.

• Leverage Strong Leadership: Provide structure, coaching, and mentorship so teams can move from underperformance to excellence.

Push Smarter, Not Harder, for Lasting Impact

“Working on the right thing is probably more important than working hard.”
— Caterina Fake

Effective leadership is not about piling more tasks onto an already full plate. It is about guiding your team in the right direction and applying pressure where it drives the most impact. Consider these principles:

• Prioritize Ruthlessly: Focus on high-impact tasks, communicate what is being deprioritized, and do fewer things better.

• Balance Pressure with Recovery: Allow periods of rest after intense sprints so teams can recharge and remain innovative.

• Use Data to Drive Decisions: Monitor key indicators (such as workload, morale, and quality) and adjust proactively, rather than relying on guesswork.

• Set Realistic Expectations: Align with both leadership and your team on achievable targets, maintaining trust and reducing unnecessary stress.

Navigating Leadership Demands to Deliver More Without Burnout

“The art of leadership is saying no, not saying yes. It is very easy to say yes.”
— Tony Blair

Even with clear data and well-reasoned arguments, you may still face demands for increased output from senior leaders. Use the following strategies to uphold sustainable practices while maintaining strong relationships and credibility.

1. Clarify and Align on Priorities

Before taking on new requests, determine which existing priorities can be postponed or dropped. If your team is already at full capacity, framing the conversation around trade-offs helps leadership see the impact of additional tasks.

How to Do It

• Share current PACE metrics (e.g., capacity utilization and error rates) to illustrate workload limits.

• Ask leadership to choose which tasks to deprioritize if new demands are non-negotiable.

Example Conversation

“Our PACE data shows we’re already at 95% capacity this quarter. We can add Feature X, but that means postponing Feature Y until the next cycle. Which is more critical?”

2. Provide Transparency into Risks

Clearly articulate the potential downsides of overburdening the team, such as increased defects, turnover, or missed deadlines. Present quantifiable data to reinforce these risks as real business concerns, not just “soft” issues.

How to Do It

• Present actual metrics (e.g., rising defect rates, longer lead times) that correlate directly with current workload.

• Connect the dots between burnout and tangible costs (decreased morale, employee attrition, slower delivery).

Example Conversation

“Over the past cycle, defect rates have increased by 20%, which aligns with the surge in overtime. If we keep pushing at this pace, we risk both quality and retention.”

3. Offer Incremental Commitments

Instead of rejecting a request outright or caving in fully, propose a balanced approach that allows a test run. Short bursts of extra effort, paired with planned recovery, can achieve goals without long-term damage.

How to Do It

• Suggest a small-scale pilot or a temporary “push period,” followed by a scheduled slowdown.

• Use the results to evaluate whether maintaining this level of pressure is truly beneficial.

Example Conversation

“We can sprint for three weeks to deliver Feature X sooner, but we need to schedule one week of buffer afterward to handle technical debt and keep morale up. Would that approach work for you?”

4. Escalate Constructively

If leadership continues to insist on unrealistic demands, it may be necessary to involve higher-level stakeholders. Approach this step in a spirit of collaboration, not confrontation, keeping the focus on sustainable results.

How to Do It

• Request a meeting with upper management to ensure alignment on priorities and potential risks.

• Present clear data from the PACE framework to show current limitations and ask for strategic guidance.

Example Conversation

“I’m fully committed to delivering strong outcomes, but additional workload could trigger burnout. Could we discuss these capacity concerns with senior leadership so we can refine priorities and avoid hurting long-term productivity?”

Data-driven transparency, constructive trade-offs, and well-defined recovery periods help preserve sustainable performance without alienating leadership. Saying “no” (or “not now”) isn’t shirking responsibility—it’s about safeguarding your team’s well-being and securing the best long-term results for the business.

Final Thoughts

High-performing teams thrive when they are challenged at the right level, without risking burnout. The PACE framework provides a structured way to measure and adjust workload so teams can work at their peak without running on empty.

Not every team is at full capacity. Some have room to grow. In those cases, applying strategic pressure, refining processes, and offering strong leadership can unlock hidden potential.

Great managers do not simply demand more. They create the conditions for sustainable high performance. The goal is not just immediate output, but also long-term excellence. Push smart, not just hard.

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Climbing the career ladder isn’t the only way to grow. In fact, sometimes it’s the fastest path to burnout.

What if actively choosing not to chase promotions could become one of your best career decisions?

Promotions often seem like the ultimate measure of success—higher pay, a flashy job title, and an impressive LinkedIn profile. Yet many who relentlessly pursue this traditional form of success quickly discover that reality isn’t as fulfilling as it appears.

In this article, I’ll reassure you that it’s perfectly okay—and often wiser—to stop chasing the next promotion, whether you decline it or never even get offered the next one.

Why I Stopped Chasing Titles

Some years ago, I was a Senior Engineering Manager, just one step from becoming Head of Engineering of a great scaleup. By traditional standards, I was quickly climbing. Then I made a decision that confused many colleagues: I left that role for an Engineering Manager position at a fast-growing international startup.

On paper, it looked like a demotion. In reality, it was an upgrade—in responsibilities, impact, and purpose. My title shrank, yet my scope expanded significantly. I led team leaders and staff engineers, tackling more complex challenges.

Ironically, at many companies, my responsibilities could easily have warranted a Head or even Director title. This inconsistency highlights a broader issue: titles are inconsistent across organizations and rarely reflect reality.

Don’t get me wrong—titles matter. They open doors, convey credibility, and mark progress. But titles alone don’t define your value or organizational impact. What truly matters is your work, behaviors, leadership, and the problems you solve.

I stopped chasing titles because I realized they don’t define my worth or determine my impact. My actions matter, not the title on my LinkedIn profile.

Before stressing over job titles, ask yourself: Am I truly growing, or am I just collecting labels?

The Uncomfortable Truth About Promotions

Like many, I once believed promotions directly equaled growth. I was wrong.

Early in your career, promotions feel essential, especially in an “up or out” culture—either you get promoted, or you risk losing your job.

However, once you reach senior roles, the reality shifts dramatically. Promotions become less about your skill and more about the perception the right people have of you. Relationships, internal politics, and visibility often outweigh genuine competence and hard impactful work.

Sylvia Ann Hewlett captures this bluntly in Executive Presence:

“Being perceived as leadership material is as crucial as actual accomplishments.”

Advancement, therefore, isn’t just about competence—it’s about fitting a particular leadership mold. That can feel deeply unfair if you believe promotions should be merit-based.

Depending on your company, leadership, and personal values, this might be a game you don’t want to play.

Why Chasing a Promotion May End Badly

Chasing promotions can feel exciting, but it’s also a gamble—one that can easily lead to frustration, disappointment, or burnout. Here’s why.

a) If you don’t get the promotion

Imagine spending months or even years tackling high-stakes projects, resolving team conflicts, expanding your teams, and driving success across the entire engineering organization—fully expecting that all this hard work will secure your next promotion. Then the announcement comes—and your name is not on the list.

It’s a bitter pill. You feel undervalued, overlooked, and question whether the extra effort was worth it.

But here’s a harsh truth: treating promotions as ultimate validation rarely ends well. It often leads to bitterness or burnout, neither of which fosters effective leadership or a fulfilling career.

b) If you do get the promotion

Surprisingly, achieving the promotion can be equally risky. While it might include a modest salary increase, it often brings significant additional workload, stress, and much higher expectations.

Consider the hidden imbalance of promotions:

• Salary → Slight increase

• Scope of Responsibilities → Noticeable increase

• Risk of Burnout → Significant increase

Suddenly, what felt like a reward can become a burden. Pressure intensifies, and if you’re not aligned with leadership or ready for extra responsibilities, the promotion could make you miserable.

The lesson? Promotions aren’t magic fixes for career growth or satisfaction. Blindly chasing them may land you in roles you never wanted—or worse, ones that drain you.

Are You Climbing the Right Ladder?

We often treat careers like video games, relentlessly chasing the next level. But ask yourself: Is the next level truly where you want to be?

Before fixating on promotions, reflect on what genuinely drives you. Is it higher salary and status or something deeper—personal growth, meaningful challenges, or alignment with your values?

Promotions, especially into management roles, often mean sacrificing technical work you love for increased stress from managing teams, navigating politics, and juggling competing priorities.

Camille Fournier, author of The Manager’s Path, wisely points out:

“Management is a career change, not a promotion. Treat it that way.”

Becoming a manager means redefining your career, often stepping away from beloved technical work to face new challenges.

If management isn’t the right path for you, consider staying on the technical track. Many companies today offer Staff Engineer or Principal Engineer roles, allowing you to grow and advance without stepping into management.

Growth Beyond Promotions

True career growth isn’t just about climbing upwards—it’s about expanding your impact. Whether you’re an engineer (individual contributor) or a people manager, there are many ways to grow without chasing a new title.

Here are some meaningful ways to develop your career:

For Individual Contributors

• Mentoring & Pair Programming: Elevating junior engineers, improving the team’s skillset and best practices.

• Specialization: Becoming the go-to expert in performance optimization, security, infrastructure, or AI/ML.

• Owning Large-Scale Systems: Leading critical technical areas and cross-teams initiatives that drive significant business impact.

For Engineering Leaders

• Building High-Performing Teams: Fostering autonomy, accountability, and continuous improvement.

• Scaling Organizations: Optimizing hiring, onboarding, and organizational structures.

• Influencing Strategy: Aligning engineering efforts with broader strategic business objectives.

A bigger title doesn’t always mean true progress or fulfillment. Instead of chasing promotions, invest in the areas that excite you. True career growth happens when you increase your impact, not just your job title.

Final Thoughts

Titles and promotions are appealing milestones—easy to measure and publicly recognized. But they are not the key to long-term success or happiness.

Instead of chasing titles, seek genuine growth, deeper challenges, and authentic fulfillment. Your career will flourish when you pursue impact rather than status.

Before chasing your next title, pause and reflect: Are you seeking genuine growth, or just chasing validation?

Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!

Subscribe now

Related Reading