Imagine this. Two teams are asking for the same three engineers. One team is working on a reliability problem that could become serious. The other is building a product initiative tied to an important company goal. Both have data, both have reasonable arguments, and both believe their work should come first. You have to decide where to allocate those engineers.

Engineering leadership is full of situations like this. The higher you go, the fewer decisions have an obviously correct answer.

You rarely get perfect information. You rarely know all the consequences, and you often need to make a decision before you feel completely ready.

This is why engineering leaders need good Judgment, I call Vitamin J.

Data is important, But It Isn’t Everything

Engineers are trained to look for evidence. We measure latency, availability, conversion, velocity, defects, incidents, customer satisfaction, and dozens of other signals before making decisions.

But leadership decisions are often made with incomplete data.

Should we rewrite or incrementally improve a system? Should we promote someone who is performing well but hasn’t demonstrated every aspect of the next level? Should we reorganize a team that is functioning reasonably well because we believe another structure will work better in the future?

There may be data informing all of these decisions, but data can’t tell you everything in those ambiguous situations. At some point, leadership requires judgment.

Judgment Is More About Learning Than Experience

We often associate judgment with seniority, and experience certainly helps. Seeing hundreds of projects, incidents, hiring decisions, and organizational changes gives you a larger library of patterns.

But experience alone does not guarantee good judgment. Someone can have twenty years of experience and simply repeat the same assumptions for twenty years.

Good judgment comes from converting experience into better mental models. Blind pattern matching is dangerous; what matters is continuously learning from experience and converting those lessons into better judgment.

Three Ingredients of Good Judgment

When you face a difficult decision, you can find it useful to mentally examine a few ingredients.

1. What do we actually know?

Separate facts from assumptions. “We experienced three incidents this quarter” is a fact. “This architecture will become impossible to maintain next year” is a prediction.

Both may be important, but they should not carry the same weight.

Many bad decisions result from assumptions that slowly turn into facts as they move through an organization.

Good judgment begins by separating facts from predictions.

2. What is the cost of being wrong?

Not every decision deserves the same amount of analysis. Some decisions are easy to reverse, and others create consequences that last for years.

Changing a dashboard metric is easy to undo, whereas choosing a new foundational architecture is considerably harder.

Before spending weeks debating a decision, ask whether it is reversible. For reversible decisions, speed often matters more than precision. You can make the call, observe what happens, and adjust.

For irreversible or expensive decisions, slowing down may be the right choice.

3. What are we optimizing for?

Many disagreements are not actually about the solution; they are about the objective and the trade-offs. One person might optimize for velocity, another for reliability, and others for long-term maintainability.

All three may be rational and right, but it is often about what we’re trying to optimize; hence, defining the principles driving the decision is critical.

Beware of Decision Overload

Not every decision deserves leadership attention. Engineering leaders can easily spend their entire day making small decisions. Individually, these decisions seem harmless, but collectively, they create decision fatigue.

When your cognitive energy is consumed by low-value decisions, the quality of important decisions eventually declines. Engineering leaders should delegate decisions and deliberately choose which decisions require their attention. For example, you lead a group with 4 teams, and you could delegate the decision about the on-call process for two of the 4 teams to one of your managers. Deciding a re-org could be a more important decision you might want to focus your attention on.

Make Decisions Observable

A decision should not disappear after it is made. Whenever possible, define what would tell you whether the decision was good. If we move engineers to this initiative, what do we expect to improve? If we launch despite the technical debt, what risk are we accepting? If we reorganize the team, what should be different six months from now?

Define the expected outcomes behind each important decision so you can learn and improve from them. You should observe the outcomes that follow from the decision, but be wary: a good decision can produce a bad outcome, and a bad decision can occasionally produce a good one.

The goal is not to judge decisions solely by what happened afterward, but to improve the process that led to the decision.

Keep a Decision Log

One of the simplest ways to improve judgment is to write down important decisions. Nothing complicated, capture this in a document or note, then look back six months later.

Human memory is surprisingly good at rewriting history. After something succeeds, the decision often feels obvious, and after something fails, the risks suddenly seem obvious too.

A decision log preserves what you actually knew at the time, and over time, patterns emerge. Maybe you consistently underestimate migration costs, or perhaps you are too conservative when information is incomplete. Those patterns are extremely valuable, and they are the raw material from which judgment improves.

Strong Leaders Change Their Minds

There is another misconception about good decision-making. We sometimes associate strong leadership with certainty, and once a leader makes a decision, they need to stand behind it. Conviction and stubbornness are not the same thing, though.

Good leaders can say: “Given what we knew then, this was the right decision. Given what we know now, we should change it.“

Changing your mind when the evidence changes is not a leadership failure; it demonstrates adaptability and intellectual honesty. On the other hand, refusing to change because your identity has become attached to the original decision is a failure.

The healthiest engineering organizations are not led by people who always know the answer. They are led by people who create systems that consistently produce better decisions.

To make better decisions, Vitamin Judgment is one of the most important capabilities an engineering leader can develop.

AI has expanded what engineering leaders can do. An engineering leader or manager can now draft a design doc, generate a prototype, build a feature, and refactor code in a reasonable amount of time, or sooner than an engineer would have in the past.

And that is exactly the trap.

The reason is that leadership has never been about maximizing output. Leadership is about multiplying your team’s output and outcome. AI makes it easier than ever to confuse “doing” with “leading.”

Instant heroism is cheap now

In the past, heroism (as writing code 🙂) required ingredients such as deep codebase context, long hours, and the willingness to carry risk. Today, heroism is cheap.

With AI, an engineering leader can parachute into almost anything, produce something that looks credible, and be proud of themselves: “I unblocked the team by writing the first version”, “I rewrote the whole codebase to speed it up”, “I fixed it myself because it was faster”.

It can be useful in the moment. But it has a long shadow.

When a manager becomes the fastest producer, the team quietly learns:

• Their Decisions are moved elsewhere

• Their Work might not be needed tomorrow

• Their Ownership is temporary

Engineer managers can deliver a lot personally and still hurt the team.

Leadership is leverage, not speed

As an engineering leader, if you disappeared for two weeks, would the team keep moving forward?

If the answer is “no,” then you are not leading a team or a system. You are acting as a high-privilege IC with a calendar.

AI does not change this. If anything, it raises the bar. As individual contribution becomes cheaper, leadership becomes more clearly defined by multiplication:

• Defining clarity on what matters and why;

• Distributing real ownership with decision rights;

• Facilitating fast feedback loops;

• Making quick, high-quality decisions without constant escalation.

Your job as a leader is not to be the person who can do the work fastest. Your job is to make it easier for engineers to do great work without needing you to do it for them. It should amplify engineers closest to the work, not turn the manager into the primary operator.

When a leader should jump in

There are moments where jumping in and being hands-on is appropriate. The difference is intent and structure. Jumping in is healthy when it is:

• Time-bound (“I’ll help for 48 hours”),

• Preserving Ownership (the Individual Contributor remains the owner),

• Learning related (pairing up with an Individual Contributor to empathize with the new workflow),

• Exceptional (not the default).

Just watch out: a manager who frequently rescues the team trains it to be dependent and disempowers it.

Everyone can feel like a hero with AI today, which is precisely why leadership matters more. The best leaders in the AI era will not be the ones who can do the most. They will be the ones who create teams that can do the most, without needing a hero.

Imagine you’re in a high-stakes meeting with VPs or executives. A question is directed at you, and you freeze. Or you have a brilliant insight but stay silent, paralyzed by the fear of being wrong.

The meeting ends. You have five minutes before a 1:1 with a direct report who is struggling with a critical project. How do you show up?

If you are still stuck in the “mental loop” of the previous meeting, for example, replaying your silence, criticizing your performance, and feeling the heat of self-doubt, you have no energy left to be the leader your report needs.

This is why we need Vitamin R: Recovery.

The Cost of “Emotional Latency”

In engineering, latency is the delay between a request and a response.

Leadership has its own version of latency: the time between an event and your ability to show up fully for the next one. When you can’t recover from a mistake, or even a moment of discomfort, your “emotional latency” spikes.

You carry the baggage of the last meeting into the next. You ruminate, you replay, you self-criticize. That invisible load quietly taxes everything that matters: your ability to mentor, give clear feedback, stay patient, and think strategically.

We often focus on external management, such as motivating teams, recognizing talent, setting direction, etc, but the most critical system to manage is yourself.

Habits over Perfection

In nutrition, a deficiency isn’t caused by one “cheat meal”. What matters is the set of habits that reliably brings you back on track. For instance, I love sourdough bread, and enjoying it occasionally doesn’t compromise my health because I have a robust system of good habits (e.g., 90% of my diet is based on whole foods).

Recovery in leadership works the same way. When you have a solid foundation of leadership habits, a single “bad” meeting or an emotional reaction under pressure isn’t a system failure, but just a data point.

One missed answer doesn’t define your competence. One failed launch doesn’t define your organization. One tense 1:1 doesn’t define your values.

It only becomes a real deficiency when you stop the recovery process, when you stop reflecting, adjusting, and returning to your baseline habits.

Quickly recovering (aka “absorbing Vitamin R”) prevents a single error from turning into a permanent outage.

Managing Your Uptime

A different use case is when engineering leaders often go through “sprints”, long stretches of high-intensity focus, or heavy planning seasons.

In a distributed system, if a node is under heavy load for too long, we remove it from rotation to prevent a crash. As a leader, you must do the same. In this case, Vitamin R (Recovery) needs to be absorbed slowly and intentionally. Allowing yourself time to recover after a period of high intensity is not “slacking”, it guarantees longevity. Similarly, in fitness, muscle doesn’t grow during the set; it grows during the rest period. Without recovery, effort turns into injury.

How to Absorb Vitamin R

When you find yourself spiraling into self-criticism (rumination), you need habits that interrupt the loop and create space for recovery.

1) Write it down, then schedule it
Spend 60 seconds jotting down the mistake or the sentence you wish you had said. This “flushes” it from your mind. Then explicitly allocate time later (even 15 minutes) to reflect. The act of scheduling it reassures your brain that it won’t be ignored, so it can let go for now.

2) Do a quick physical reset
Wash your hands, stand up, step outside, or grab a coffee or a glass of water between calls. A physical interrupt signals closure: the last meeting is done, and a new one is starting.

3) Use the 5–5–5 rule
Will this matter in 5 minutes? 5 months? 5 years?
Most mistakes don’t survive the second “5.” This reframes the moment and reduces the emotional charge.

4) Box breathing
Use a 4-second box breathing cycle (inhale–hold–exhale–hold). This lowers physiological stress and helps shift you from “fight” back into a calmer, more deliberate mode.

If instead you feel depleted after a major milestone, you need different recovery habits: ones that reduce cognitive load and prevent burnout.

5) Non-decision time
Block a half-day (or a full day) with zero high-stakes decisions. Use it for input gathering, writing, planning, and reflection, not for irreversible decisions.

6) Zero-notification hours
Build a daily habit that removes notifications: a workout, a long walk, or a simple routine without your phone (or with it, but without checking your messages). These are scheduled maintenance windows. They remind you that you’re not just a leader, you’re a person with constraints, needs, and priorities.

7) Take a PTO

Take some time off to recharge. A few days away from the office or work could be beneficial to fully recover in some situations.

Vitamin R doesn’t come in a bottle, but it may be the most valuable supplement for a sustainable career: it’s a self-healing mechanism.

The best engineering leaders aren’t defined by avoiding mistakes. They’re defined by how they “Recover”.

It has been twenty years since my mum passed away.
After writing a tribute to my dad last year, I felt I wanted to write one for her as well. This post, like the previous one, is more personal and somewhat outside the usual scope of this Substack, but as I’ve said before, I write primarily for myself.

My mum was a strong woman. She fought cancer for more than seven years, through moments of hope and moments of hardship. Throughout that long battle, she did everything she could for our family: for my dad, for my sister, and for me. Even while carrying her own pain, she always put others first.

Like my dad, my mum was a teacher. In fact, they met at work. She taught educazione artistica (art) in middle school and, for three years, she was also my teacher. I still remember waiting for her outside the classroom when her lessons ended, small moments that remain vivid even after all this time.

My mum was deeply creative. She loved art and painting, especially before her illness. We still have her paintings at home, quiet reminders of her talent, her sensitivity, and the way she saw the world.

She devoted much of her time to caring for the family, cleaning our home, and cooking for us. Holidays, like Christmas, are still difficult because they inevitably bring back memories of the incredible meals she used to prepare and the warmth she created around the table.

My mum had an exceptionally good heart; she was so genuine and transparent. I admired her deeply, and I hope that some of her traits (honesty, empathy, strength) live on in me.

She understood me like no one else. She could read me instinctively, always took my side, and believed strongly in my potential. She wanted me to succeed at school and in life, and she taught me the importance of discipline as a foundation for achieving meaningful goals.

From her, I learned resilience. I learned that life can be unfair, but that some things are worth fighting for, no matter how difficult the path becomes.

She also had a light spirit. She knew how to balance discipline with humor, how to make people laugh, and how to bring energy into the family. The final phase of her illness inevitably changed that dynamic, but I choose to remember her as she was for most of her life, with a smile, looking at me with warmth and care.

Twenty years may sound like a long time, but I still miss her. Sometimes I feel sad thinking about all the moments of my life she didn’t get to see. At the same time, I feel deeply proud that she was my mum and grateful that I had twenty-three years with her.

This is a picture of her, and below is a picture of our family when I was little, moments frozen in time, but never truly gone.

My mum showed me that leadership is not defined by authority, but by resilience, discipline, and care for others. She led through example, consistency, and quiet strength. Those values continue to shape how I hope to approach leadership and life today.

Vitamin K is a fat-soluble vitamin essential for blood clotting and bone health. It acts as an activator, supporting blood-flow regulation and calcium placement. Too little Vitamin K can lead to excessive bleeding or osteoporosis, while too much can cause blood clotting.

A fast-moving engineering organization behaves much like a living organism, with continuous circulation of code, decisions, information, and ideas. In that context, governance functions like Vitamin K: it activates clarity, ownership, and alignment so that teams can move with fluidity and control.

Using the metaphor of “blood circulation,” engineering groups often experience two unhealthy extremes:

• Excessive bleeding: constant churn, shifting priorities, unclear ownership, and decisions that do not stick.

• Thrombosis: decision paralysis, redundant checkpoints, and micromanagement that suppresses creativity and autonomy.

Engineering leaders must design governance systems that maintain flow without obstruction.

Healthy Governance as Vitamin K: Activation, Not Control

Governance is not about bureaucracy or control; it is about activation. The purpose is not to slow teams down, but to provide clarity and guardrails necessary to enable autonomous execution.

Engineering leaders should work across multiple governance dimensions that support healthy organizational “circulation.” Let’s take a look at them.

Strategic Governance

Strategic governance aligns engineering work with business objectives. The goal is to create clarity of direction, support purposeful prioritization, and ensure that engineering investments produce measurable business value. Strategic governance should empowers teams to understand the rationale behind their work and to make informed trade-offs. A few key mechanisms that can help with this dimension:

• Establishing Mission (more in this previous post), Vision, and Values for an engineering team. A mission establishes the team’s mandate; a vision describes the desired future state; values set behavioral expectations and norms. Leadership should make sure these artifacts connect day-to-day execution with long-term intent.

• Definining a North Star metric and initiative-level Success metrics. A team should have one clear topline they keep top of mind. A single topline metric provides a unifying focus and supporting metrics at the initiative level ensure granularity.

• Executing Quarterly Planning, possibly using a framework like OKRs (more in this previous post). Quarterly planning translates strategy into actionable commitments. Objectives describes desired outcomes; key results define measurable success; initiatives map the operational plan or roadmap (more in this article on the difference between OKRs and roadmap). Engineering leaders partner closely with cross-functional peers to shape these plans.

• Practicing Continuous Prioritization (more in this previous post). Prioritization does not end after planning cycles. Teams should reassess focus weekly as new data, customer signals, and competitive dynamics emerge.

• Operating Business Review cadences (WBR, MBR, QBR). Regular review forums provide leadership with a disciplined mechanism to track progress, evaluate performance against key metrics, surface risks, and align on course corrections. Outcomes from these reviews cascade into team-level adjustments through line managers.

Execution & Ownership Governance

Execution and ownership governance defines how work moves and who is accountable. The objective is to create a repeatable “modus operandi” that supports fast execution while preserving clarity of responsibility. Key mechanisms include:

• Assigning Accountable Owners for each program and project. Each initiative should have a single, clearly identified Directly Responsible Individual (DRI). Engineering leaders must clarify roles within their teams and specifically who the DRIs are.

• Defining Repeatable Product Development Life Cycle (PDLC) Process. This process should enable teams to execute multiple initiatives predictably. A clear PDLC structures how initiatives progress from concept to launch, creating predictable execution and consistent cross-functional expectations. Teams should redefine the process as they learn.

• Creating a structured Experimentation Process. Engineering organizations accelerate innovation by running continuous experiments (more on this in the previous post). Hypotheses must be explicit, success metrics defined in advance, and decision-making clarified.

• Having a robust Continuous Development process (more on this in a previous post). Continuous integration, canary releases, gradual rollouts, and automated verification enable teams to ship high-quality code with high frequency and low risk. Engineering leadersh should leverage this approach to reduces operational surprises, and shortens feedback loops between development and realeases.

Technical Governance

Technical governance encompasses a set of practices to preserve long-term engineering health without slowing down delivery. Effective technical governance ensures that teams can innovate rapidly without accruing structural risk or compromising product reliability. Key practices include:

• Standardizing and rigorously reviewing technical design documents. Technical docs should follow specific templates and be evaluated through a structured review process. Design documents serve as alignment instruments across teams, and make sure that engineering trade-offs are explicit, traceable, and understood.

• Establishing periodic Tech Strategy reviews. These reviews address architecture evolution, technical debt, infrastructure investments, developer-productivity initiatives, and long-term technical direction. They create intentional space for proactive thinking rather focused on the technical side. Engineering managers should operate though their technical leads to support those forums.

• Embedding Continuous Testing and Quality (more in this previous post). A comprehensive testing strategy (unit, integration, end-to-end testing) aim to keep the product quality high. Engineering leaders should proactively guard against degraded quality standards.

• Caring for Operational Excellence (more in this previous post). Operational rigor serves as a core dimension of engineering quality. Practices such as reliability engineering, observability, capacity planning, and performance monitoring help ensure that production systems remain performant and resilient. Engineer leaders should reinforce that operational excellence is a non-negotiable element of the engineering culture.

Cultural Governance

Cultural governance defines the behavioral norms and operating principles that sustain psychological safety, collaboration within engineering organizations. Key practices include:

• Providing and asking for feedback regularly. Engineering leaders are expected to offer timely, actionable feedback during 1:1s, while also inviting feedback on their own performance and decisions. Normalizing feedback enables team members to address issues early and grow in role.

• Making Transparent Decision. Decisions, their rationales, and relevant constraints must be communicated clearly and promptly to the team.

• Setting Clear Goals and Expectations. Teams perform at their best when objectives and standards are unambiguous. Leaders should set explicit performance expectations and goals, minimizing ambiguity and uncertainty.

• Embedding Continuous Learning (more on this in a previous article). Postmortems, retrospectives, 360 feedback encourage teams to analyze successes and failures with rigor. The aim is not to point fingers to whoever made a mistake but to keep learnings.

• Cultaving Trust. Trust is the foundation for psychological safey (more on the topic in this previous article). Teams that trust one another can move with confidence, and challenge assumptions without fear. Leaders should reinforce trust by modeling integrity, following through on commitments, and creating space for dissenting views.

Healthy governance does not add friction; it removes drag. Just as Vitamin K activates essential proteins to help with blood circulation, governance activates clarity, ownership, and motivates teams to do their best work.

Engineering leaders are responsible for designing governance as a circulatory system. When done well, it strengthens organizational health, accelerates delivery, and enables teams to perform at their highest potential.enables teams to perform at their highest potential.

When it comes to personal health, we often rely on regular bloodwork as a diagnostic checkpoint. Preventive medicine teaches us not to wait until we feel ill to measure cholesterol, glucose, or inflammation markers. Instead, we establish a baseline and track trends that reveal whether our body is functioning as it should.

Engineering teams deserve the same rigor. Instead of waiting for problems to become severe, engineering leaders can create regular State of the Union (SOTU) documents as structured check-ins to address issues proactively. Just as bloodwork surfaces early signals of health, SOTU docs help leaders analyze the state of their team across multiple dimensions, reflect deeply, and act before issues compound.

Structure of a SOTU Document

Think of a SOTU as a full-spectrum health panel for your team. It’s not just about velocity or deadlines; it’s about holistic health. A well-structured SOTU should cover:

• 🩺 TL;DR (Vital Signs)
  A quick read on how the team is doing overall, much like the summary your doctor provides after reviewing lab results. Distill the signal into two or three sentences.
  Example (for a healthy team):
  “The team is in a strong place. Execution is predictable, morale is high, and cross-functional partners consistently highlight our reliability and collaboration. Engineers are identifying growth opportunities, and our investments in engineering excellence (quality, testing, and observability) are yielding results with fewer incidents and faster iteration. Risks are minimal and well-contained.”

• 🎯 Team Focus (Current Treatment Plan)
  What is the team currently prioritizing? Is there clarity and alignment on the most important goal, or are distractions pulling energy elsewhere?

• 🧭 Team Direction (Long-Term Prognosis)
  Beyond the immediate sprint or quarter, does the team understand its long-term mission and role in the org strategy? Is there a long-term direction for the team aside from achieving short-term goals?

• 🌱 Career Growth & Team Roles (Muscle Building & Recovery)
  Teams thrive when individuals thrive. Are engineers finding opportunities for stretch, mentorship, and skill development? Neglect here is like neglecting nutrition. Part of this involves also clarifying how you plan to utilize your team members’ strengths. For example, you might have team members who are more focused on engineering activities and others with a more product sense.

• 🤝 Collaboration with XFN (Circulatory Health)
  Just as blood flows through the body, information and collaboration must flow freely across Product, Design, Data Science, and other partners. Are there issues in those partnerships? It is essential to identify the root cause of any problems and examine how to streamline the collaboration.

• 🏆 Wins (Positive Test Results)
  What’s going well? Celebrating victories reinforces healthy habits and helps the team see progress.

• 🙌 Recognitions (Immune Boosters)
  Highlight individual and collective contributions. Recognition strengthens morale and resilience, much like boosting the immune system. More on recognition in this post.

• 🛠️ Engineering Excellence (Preventive Care)
  Is the team investing in code quality, reliability, observability, and reducing tech debt? Engineering excellence (see also this previous post) is akin to preventive care, as it reduces the likelihood of future incidents. See this article for

• ⚠️ Risks (Warning Signs)
  No check-up is complete without looking for red flags, eg, burnout, attrition, or quality gaps. Calling these out early allows for prompt intervention. A leader must also highlight the steps taken to mitigate those risks.

How Often to Write SOTU Docs

Just as annual bloodwork isn’t enough for high-performance athletes, yearly check-ins aren’t enough for the team. The right cadence depends on your team’s pace and context:

• Quarterly: A good default for most teams, usually enough to track trends.

• Monthly: Useful for rapidly scaling teams or those navigating major product shifts.

• Biannual: Works for very stable, mature teams where changes are incremental.

The important part isn’t the exact cadence, but the commitment to making it a regular habit.

Who Is the SOTU Doc For?

The document is primarily intended for engineering leaders to reflect on progress, diagnose systemic issues, and adjust their course.

This information could also be shared with cross-functional partners to foster trust and transparency by demonstrating how the team is performing beyond output metrics.

Skipping bloodwork leaves you blind to slow-moving health issues. By committing to writing SOTU documents, leaders create a way to prevent risks from creeping in and spend time going deep, reflecting on the state of the team.

Vitamin E is an antioxidant that protects human cells from damage caused by free radicals. It works continuously, preserving long-term health and resilience for our bodies.

Similarly, in engineering leadership, a focus on engineering excellence helps address technical debt and quality issues. Technical debt and quality issues act like oxidative stress, impacting speed and morale, and ultimately make it harder to deliver business impact.

The Functions of Vitamin E

The human body can’t produce Vitamin E and must be obtained from the diet (or supplementation if necessary). Unlike Vitamin D, which the body can produce with sunlight, Vitamin E must come from external sources.

Vitamin E is fat-soluble and is found mainly in foods that contain healthy fats, such as nuts & seeds (almonds, sunflower seeds, hazelnuts), vegetable oils (olive oil or sunflower oil), green leafy vegetables (kale, swiss chard, etc). Avocado is also another good source of Vitamin E. In case you are not able to eat enough foods rich in Vitamin E, you can use supplements.

Pro tip: Vitamin E is best absorbed when eaten with fat-containing meals, since it is fat-soluble.

Vitamin E covers multiple functions:

• Protects cell membranes from damage

• Neutralizes free radicals early

• Works continuously and proactively

• Preserves long-term function & energy

  ---

Engineering Excellence in Teams

As an engineering leader, we often have the tendency to prioritize product roadmap iteams first-and-only given our teams need to deliver lots of business impact. Often, we need to make tradeoffs, which may involve creating tech debt or introducing follow-up tasks. This is pretty common as companies tend to focus on topline business metrics. Engineering leaders need to make sure to guarantee quality is taken care of, otherwise we’ll end up slowing down our team eventually and actually have a negative impact on the business goals.

To keep tech debt under control and maintain high quality, one critical component is to uphold high standards in terms of engineering excellence for our teams. To do so, we might want to follow the following 3 steps:

1. Measure the health of your systems and processes

2. Prioritize engineering excellence along with product priorities

3. Embed engineering excellence as part of the team culture

1. Measure the Health of Your Systems

You can’t protect what you don’t measure. Just as physicians use blood panels to detect deficiencies long before symptoms appear, engineering leaders need regular “health checks” to understand the state of their systems. Frameworks like DORA, SPACE, or DevEx (see article) provide useful lenses, but the key is to choose a set of measures that are actionable for your team’s context.

Without going too much into the weeds on which framework or specific metrics your team needs, there are a few core areas to monitor:

Performance: How fast and responsive your system is. Examples include p90 latency, page load times, and API response times.

Scalability: How well the system holds up under growth. Examples: throughput under 10x traffic, auto-scaling efficiency, etc

Reliability: How consistently your system delivers expected results without failure. Examples: uptime %, mean time to recovery (MTTR), error rate per request, etc

Code Quality: How maintainable, readable, and correct your codebase is. Examples include static analysis scores, cyclomatic complexity, and bug density, among others.

Development Efficiency: How quickly and effectively engineers can deliver value. Examples: deployment frequency, lead time for changes, CI/CD pipeline duration, developer satisfaction surveys, etc

Testability: How easily changes can be validated to ensure safety and correctness. Examples: unit/integration test coverage, flaky test rate, etc.

Security: How well the system protects data and resists malicious attacks. Examples: # of critical vulnerabilities, results from penetration tests, etc

Observability & Monitoring: How effectively the system provides visibility into its internal state for debugging and improvement. Examples: coverage of logging, alerting accuracy (false positive/negative rates), and % of critical flows instrumented with tracing.

Cost Efficiency: How resources scale with value. Examples: infra cost per DAU/request, cloud cost allocation accuracy, etc

Security & Compliance: How well your system is in compliance with required standards. Examples: SOC2/ISO audit pass rate, % of systems with automated compliance checks, etc

These dimensions don’t need to be tracked with dozens of dashboards. A simple set of those metrics, reviewed regularly, is often enough to surface where the “oxidative stress” is creeping in. The goal is not perfection, but rather gathering signals, so engineering leaders can make deliberate decisions about where to invest in strengthening the system.

2. Prioritize Excellence Alongside Product Goals

Vitamin E isn’t optional, it’s a daily essential. Engineering excellence should be treated the same way, prioritized continuously, not deferred until “after we ship” or “when there’s time.”

Prioritization, however, is situational. Depending on the maturity of your team, the health of your systems, and the urgency of business goals, you may need to apply different approaches to ensure engineering excellence gets the space it deserves:

Dedicated Tech Debt / System Weeks: Periodically dedicate an entire sprint or week to paying down accumulated debt and strengthening foundations. These bursts are effective when the team needs to “reset the baseline.”

20% Allocation Model: Reserve ~10–20% of ongoing capacity in each sprint or week for quality and tech debt work. Similar to daily nutrient intake, this steady model should prevent issues from compounding.

Unified Approach: Bake engineering excellence directly into the product development lifecycle, rather than treating it as a separate activity. For example, when planning for a new product feature, explicitly consider test coverage, observability, and performance in your timelines. Of course, the aim is not perfection (e.g., you could ship products even if we don’t have 100% test coverage), but is to minimize accruing tech debt.

Opportunistic fixes: When working on a code path for product development, opportunistically clean up technical debt and add missing tests. This small effort could lead to meaningful improvements over time.

The gist here is: don’t let excellence be an afterthought.

3. Embed Engineering Excellence as Part of the Culture

Just as Vitamin E sustains health through daily habits, engineering excellence sustains team health when it is embedded into the team culture and not treated reactively.

A culture of excellence means that every engineer feels accountable for the long-term quality of the systems they build. It’s not the job of an occasional sprint, it’s a shared mindset. This shows up in the small decisions: writing tests without being asked, documenting so the next teammate can succeed, or raising concerns early.

Leaders reinforce this culture by:

• Talking about system health with the same seriousness as product metrics.

• Recognizing craftsmanship (a great refactor, observability improvements) in retros and all-hands, not just feature launches.

• Framing excellence as an accelerator of delivery, not a blocker.

When excellence becomes cultural, it stops competing with speed, but actually, it enables it.

Vitamin E should protect our cells through daily consumption. In the same way, by proactively addressing tech debt, embedding high standards, and balancing speed with stability, leaders can build teams with have long-term health.

Psychological safety isn’t optional – it’s the foundation of resilient and innovative teams.

The tech landscape has changed in the last few years, and job security has diminished. The consequences of this on team dynamics and developer mental health are profound.

In environments where job insecurity is common, there’s a natural tendency for developers to take fewer risks, avoid challenging conversations, and, in some cases, overwork – all symptoms that hinder innovation and lead to burnout.

To remedy this, engineering leaders need to create an environment where those tendencies are reversed, building psychological safety into teams.

Leading with empathy and vulnerability

It is always important to remember that the fundamental route of all leadership is human connection. Leaders need to communicate openly, show understanding of people’s feelings, empathize, be compassionate, and show vulnerability, especially in a time when people’s jobs feel unsafe. In doing so, you help people feel understood, respected, and at ease.

Leaders need to engage in a lot of active listening, diving deep into topics people bring up. For instance, if a company had announced layoffs the day before, leaders might want to hear out people’s concerns. Phrases like “Tell me more about what concerns you about the layoff of company X” or “I understand where you’re coming from – sometimes I worry too,” show vulnerability and transparency.

Building a sense of inclusion safety is the first stage of creating psychological safety in teams, and establishing trust through presenting yourself as a human rather than “the boss” is the only way you’re going to get there.

Bring a positive perspective

Acknowledging a tough market builds transparency, but bringing a positive outlook helps motivate people and soothe any fears. Statements like this might help: “Even though our competitor just had layoffs, we have a strategic advantage for X, Y, Z reasons.”

Positivity is the main element here. Leaders can expand their focus from layoffs to providing overall learning opportunities for team members, such as conferences. This incentivizes the second stage of psychological safety: learner safety.

Another way to achieve this is through asking for feedback, which shows a willingness to improve. It invites reports to raise concerns and feel like their voices are heard. Simple phrases like “Could you give me some feedback on the way I ran the last meeting? I’d like to improve on my communication skills,” help create a safe environment where engineers feel empowered to continuously learn.

Empower people’s voices

People may be hesitant to speak up when layoffs and job insecurity are on their minds. In our current environment, anything perceived as a failure amplifies anxiety.

Leaders, therefore, play a key role in minimizing the spread of fear. By focusing on the effort and contributions of a team, instead of a “failure,” attention is shifted. Leaders can lean on sentiments like, “We tried to launch feature X. Unfortunately, the primary metrics gave us a negative signal, but it was a great learning experience for the team, and we now know how to move forward.”

Publicly recognizing curiosity and valid inputs is essential for fostering contributor safety, the third stage of psychological safety. This helps create a safe environment where the focus is on the process of contributing, making an effort, and learning as opposed to solely on outcomes. For example, during a post-mortem, instead of focusing on who made a mistake, leaders can praise stakeholders who focus on finding ways to prevent the same incident from happening in the future.

Foster innovation

Innovation stems from new ideas. But when people hear about something destabilizing, like layoffs or reorgs, it can become hard to challenge the status quo; it’s perceived as a significant risk, and engineers are uncertain whether others will have opposing opinions.

This is where leaders need to incentivize people to innovate and propose new ideas and solutions. You can do this through small gestures like thanking people for disagreeing, especially if they oppose an idea or process defined by somebody with higher authority. A simple “thank you for your feedback. I think this is a fair way of looking at things,” can set the example that disagreements are safe, as long as they are meant to improve the overall outcome.

Fostering innovation in a team directly correlates with challenger safety – the last stage of psychological safety. This is about being comfortable and safe in expressing new ideas, which generates innovation and typically allows businesses to improve their outcomes.

Final thoughts

Teams that can achieve all four stages of psychological safety attain a resilience that allows them to rebound faster when layoffs or significant shifts happen. As an engineering leader, it is your responsibility to guide your teams toward calmer waters in as stable a way as possible, ultimately reaching a place where trust and innovation are at all-time highs.

Predicting what a group of engineering teams can realistically achieve every quarter or in any specific timeframe is not a straightforward task. Without a structured approach, it can become a pure guesswork exercise.

This is where capacity planning comes in - capacity planning is a powerful practice that enables engineering leaders to forecast team allocation, align on priorities with stakeholders, and make sure it is clear what can and what cannot be achieved in a specific quarter. In this article, we’ll explore a four-step process for implementing capacity planning effectively. This process is typically conducted before the start of a quarter, with tight collaboration between Engineering Managers (EMs) and Product Managers (PMs).

Step 1: List All Initiatives and Projects

The first step is about compiling a comprehensive list of all initiatives and projects that your teams might work on in the upcoming quarter. This list should include everything under consideration; the goal is to capture the full scope of potential work.

Typically, EMs and PMs collaborate to brainstorm all ongoing projects, new feature proposals, efforts to reduce technical debt, and any cross-team dependencies.

At this stage, there is no ranking or filtering, but there is a willingness to make sure nothing is overlooked.

From experience, an issue that could come up is having projects in the list that are not correlated with OKRs (more on OKRs and Roadmap in this previous article). To avoid this, it is essential to have a reference between each project and a Key Result.

Step 2: Rank the Initiatives

Once you have a complete list, the next step is to prioritize the initiatives based on their importance, urgency, and strategic alignment. PMs usually drive ranking and help clarify which projects are must-haves versus nice-to-haves. It's key to consider what's essential for the business in the upcoming quarter to drive prioritization.

This step is instrumental for the EMs so they can start thinking about how to allocate people.

A typical issue I experienced is having multiple projects marked as ‘Important’ and with the same priority. This needs to be avoided as much as possible because EMs need a clear direction to allocate people.

Step 3: Estimate the LoE per project

EMs mainly drive the third step, which involves estimating the Level of Effort (LoE) required for each initiative (e.g., in-person weeks) and mapping it to the ranked list of initiatives. EMs work closely with PMs to collect as much data as possible about the projects and work with the teams to define high-level estimates. EMs might use data from past quarters (e.g., velocity or throughput) to inform their estimates and need to ensure that they serialize or parallelize initiatives based on team members' skills.

EMs work iteratively to fill out the overall allocation for all team members, aiming to maximize capacity.

A common issue here is that there are gaps in skills on a team for a specific initiative, and sequencing becomes challenging or inefficient. This is where an EM needs to raise this with leadership and stakeholders to make tradeoffs or find creative solutions.

Step 4: Review Allocation and Lock the Plan

The final step is to review the proposed allocation and ensure that everyone agrees with it. This is when EMs and PMs double-check that the plan is realistic, make sure the priorities and sequencing of execution make sense, and when all stakeholders commit to the plan.

At the end of this step, we should have a locked-in plan with a clear view of what each person will work on in the upcoming quarter.

A common issue in this step is that changes to the allocation occur due to trade-offs, and additional sessions are needed to lock in the plan. For example, let’s say initiative A is slightly higher in priority than initiative B; initiative B can be completed in 3 weeks with two people, and initiative A takes 12 weeks with four people. In the initial allocation, the EM might put initiative A before initiative B, but the risk is that nothing is delivered in that quarter. After the alignment sync, EMs and PMs may decide to execute initiative B before initiative A to complete an initiative within the quarter.

Practical implementation

An easy way to implement capacity allocation is to use a spreadsheet. Rows represent people in different teams; columns represent the different weeks in a quarter; and cells represent initiatives based on the estimation, see below:

In this example, there are two teams, each with five people, and each person has a specific skill. We’re just looking at January divided by weeks, and you can see how the allocation is done based on the initiatives ranked from 1 to 6 (each initiative is estimated at a high level by the EM with the team).

This is just a way to create a capacity plan; you can use more advanced tools if needed.

Final thoughts

Capacity planning is an approach to predicting what engineering teams can achieve in a given timeframe. By listing initiatives, ranking them, estimating their costs, and assigning people to them, engineering leaders can set realistic goals and create alignment across the company for a successful quarterly planning.

Did you know that Vitamin D deficiency affects around 42% of people in the US and around 1 billion worldwide? Similarly, many capable engineering teams can suffer from a 'visibility deficiency,' making it hard to justify further investment and support.

Vitamin D is mainly absorbed when our skin is exposed to sunlight, and it is fundamental for overall health, specifically for bones, the immune system, and mood regulation.

Similarly to the importance of Vitamin D for our health, visibility is crucial for an engineering team’s success. An engineering team needs to get visibility across the company to secure support, justify further investments, and guarantee motivation among its team members.

Let’s first look at the benefits of visibility and Vitamin D, and then we will look at the risks of low visibility and how engineering leaders can help with this.

The Benefits of Vitamin D and Visibility

The first benefit of having the right Vitamin D level in our body is bone health. In the same way, visibility for teams strengthens the structure of a team. Having goals and priorities defined and visible to everyone can be the basis of a stable team. For example, at the start of each quarter, sending out an e-mail to adjacent teams outlining key projects, dependencies, and expected outcomes ensures visibility and alignment.

Second, Vitamin D facilitates calcium absorption, which is essential for cellular communication and function. Similarly, visibility for teams ensures that information flows effectively across teams, enabling better decision-making and overall awareness. For instance, having team members share what the team is building in the company’s tech talks can help with information flow.

Third, Vitamin D is essential for the immune system, protecting the body from illness. In a team context, visibility and alignment protect teams from miscommunication. For example, providing frequent project status updates and calling out project risks helps identify and address issues early.

Lastly, Vitamin D can help with mood regulation, while visibility can help boost team morale. Giving visibility helps with recognition and motivation. For example, calling out team members during company-wide All Hands can boost their engagement even more.

The Risks of Low Visibility

After looking at the benefits, what are the risks of low visibility and low Vitamin D levels instead?

Vitamin D deficiency can weaken bones and immune functions and cause depression, whereas a lack of visibility can decrease an engineering team’s impact. Let’s dive deep into some of the consequences that might be generated by low visibility:

• The team is misaligned with business priorities, and projects in progress are scrapped because the team’s work might go unnoticed.

• The team might struggle to secure resources for growth and innovation

• Team members may feel undervalued, leading to lower morale and higher attrition.

• Other teams may work on similar problems, and collaboration opportunities may be missed. For example, a team once spent months building an internal tool, and only after launch, the team discovered another team had developed a similar solution. A lack of visibility led to a lack of collaboration and wasted effort.

Engineering leaders must take proactive steps to avoid those risks - we’ll look at a few practical ways in the next section.

How to Provide Visibility for Teams

Here are a few strategic levers engineering leaders can pull to improve visibility.

• Utilize Emails & Slack (or other IM tools ): These are easy but effective ways to provide updates and insights into what a team or organization is doing.

• Incentivize team members to demo their work in open forums - i.e. All Hands or any forum with a broad audience.

• Build a rapport with upper management through skip-level meetings- E.g., if you are an engineering director, you could ask for a monthly meeting with a VP or GM, and if you are an engineering manager, with the director or senior director. This could help shed light on what the team/org is doing.

• Volunteer team members to take on cross-team initiatives. For example, if there is an initiative to foster genAI tools usage across the company, you could volunteer team members to showcase what has been done in the team.

• Solicit team members to share their knowledge in company-wide tech forums, e.g. Tech Talks, etc. People could share what the team is building or innovating on.

Just as maintaining Vitamin D levels by spending time in the sun or taking supplements is essential for physical health, ensuring visibility is crucial for a team's success. Engineering leaders must proactively build visibility for teams to avoid being underfunded, or misaligned with company priorities.

First of all, how do we define longevity for humans and teams?

Longevity for individuals refers to living a long and healthy life - it encompasses life span and health span.

Longevity for teams is the sustained ability to deliver value and adapt to change without burnout shown by teams. It’s about ensuring engineering teams remain constantly excellent (see the five core characteristics in a previous article).

V̇O₂ max and Longevity

V̇O₂ max is widely considered one of the most accurate indicators for predicting longevity for individuals. A 2018 research study shows that “V̇O₂ max is a strong and independent predictor of all-cause and disease-specific mortality, suggesting a correlation with longevity.”

It measures how efficiently your body delivers oxygen to your muscles during exercise. It expresses the ability of your heart, lungs, and muscles to work together seamlessly.

Higher V̇O₂ max scores correlate to:

• Reduced Risk of Cardiovascular Disease: Individuals with higher VO2 max have more efficient hearts, reducing the risk of heart attacks and strokes.

• Improved Metabolic Health: A high VO2 max enhances your body’s ability to regulate blood sugar and fat metabolism, reducing the risk of diabetes and obesity.

• Increased Resilience: High VO2 max enables quicker recovery from exertion, allowing sustained physical activity and reducing fatigue.

Athletes improve V̇O₂ max through a careful balance: sustained, aerobic work (most of the training) and high-intensity intervals (the minority). Research studies point out that both types of training are needed. This study shows the importance of High-Intensity Interval Training (HIIT), and this other study shows the importance of aerobic training.

Durable Delivery and Longevity

Durable delivery is a good indicator of team longevity. It involves continuously executing on time, on budget, and with quality.

Similarly to V̇O₂ max, durable delivery requires the team to be functional in multiple areas (planning, implementation, verification, launch, team morale, etc).

Durable delivery has different aspects, and engineering leaders are accountable for increasing this indicator - Let’s look at a few interesting parts:

• Delivering according to plan is at the core of durable delivery. It’s key to predictably executing features, bug fixes, and improvements, meeting budget and timeline constraints, and maintaining high quality. Engineering leaders must ensure their team has a plan and then use processes to stick to it.

• Balancing product roadmap, tech items, and KTLO (Keep The Lights On): This applies mainly to Product Engineering teams. Engineering leaders must allocate people to roadmap items, tech debt, bugs, etc., dynamically and based on priorities. Similarly to aerobic training, roadmap items should receive most of the allocation, and tech items, explorations, and bug fixes are similar to high-intensity intervals (less allocation but still very important).

• Continuous Learning: Teams that incorporate time for continuous learning are better equipped to handle change and recover from setbacks more efficiently like a well-trained athlete recovering more efficiently. Engineering leaders need to champion a growth mindset and curiosity. This previous article has more continuous learning.

• Fast recovery: Setbacks, failures (e.g., incidents), and significant shifts are frequent, and teams need to be adaptable to them. Engineering leaders must embrace continuous changes and focus on how the team can quickly recover, reset, and focus on new goals.

Measuring VO2Max and Sustainable Delivery

The most accurate way to measure VO2 max is to execute a test in a controlled environment using specialized equipment. The test will give you a score that might vary based on your endurance level. See this sheet for a recap of what the score means for your age and gender.

For teams, catching durable delivery might not be as straightforward; engineering leaders could use a combined set of metrics:

• Rate of projects delivered on time - this can be based on how many projects run according to the initial plan (usually established after a Technical Design Document is completed)

• Lead Time is the time it takes to deliver value from ideation to deployment. Measuring this absolute value over time could help us understand the speed at which the overall XFN team moves forward.

• Mean Time to Recover (MTTR) is how quickly the team recovers from incidents.

• Number of Bugs within SLA: Track the number of bugs within a specific SLA. Assuming the severity of a bug affects the specific SLA, this can help monitor quality.

• Engagement score is about tracking the team morale, which can be executed through a pulse survey.

Like individuals with high VO2 who are more likely to live a longer and healthier life, teams emphasizing durable delivery continue to thrive, adapt, and perform over time.

In the final post of this series, we will explore the last but not least macro-activities of the Continuous Software Engineering (CSE) framework: Continuous Innovation and Continuous Knowledge Management. These areas can develop a culture where teams can express adaptability, collaboration, and craftsmanship - three of the five core characteristics of excellence I defined in the first post of this series.

Read more

In the previous post, we explored continuous development and quality, looking at development practices such as CI/CD, continuous pull requests, TDDs, and quality assurance practices such as dogfooding and automated testing. All those practices enable teams to build resilient software according to Continuous Software Engineering (CSE) principles (see paper)

Now, we will focus on two other key pillars of the CSE framework: Continuous Experimentation and Measurement. These areas ensure that what is built is informed by data, helping teams drive rational product decisions and measuring team health objectively.

Continuous Experimentation

At the core of Continuous Experimentation is the notion of experiments in the context of product feature launches.

Experimentation is a process where we want to observe - in a data-driven manner- the behavior of a subset of users applied to an experiment. The process starts with hypotheses usually driven by Product Managers. Each hypothesis has a primary metric associated with it, most likely used in defining a KR (see this post to know more about OKRs) and an initiative we want to launch, whose output will affect the primary and possibly secondary metrics.

One of the most used ways to test a hypothesis is through A/B testing. A/B Testing allows teams to test hypotheses by comparing one or multiple treatments - the hypothesis we want to test with possible variants - against control - the current version of the product. For instance, if we are going to optimize user engagement on a landing page, we might test two versions of the landing page with a subset of users (under two treatments) compared with the current version (under control) and measure which version results in a higher engagement rate.

Engineers, product managers, and data scientists work together to define the test, implement it, and analyze the data. Usually, engineering takes the lead in the implementation, whereas product & data lead in the definition and analysis. However, engineers and engineering leaders need to lean in all the stages, specifically during the data analysis - commonly called readouts.

Continuous Experimentation is about constantly considering hypotheses and running experiments, making data-driven decisions, and learning from them. A specific result of an experiment may validate the current strategy or affect how the strategy needs to change.

An example of a process in this category I have seen in multiple companies is an Experiment Review forum. This type of forum is used to discuss ongoing tests that haven’t yet been fully rolled out to all the users. For each experiment, a data scientist, an engineer, or a product goes deep into the results related to an A/B test. A document is usually shared ahead of the meeting with the critical data, links, or screenshots to the charts of primary/secondary/guardrail metrics. Collectively, the team discusses the results, and the decision maker (typically a product manager or an engineering leader) will drive the decision most objectively. The decision could be to abandon the experiment (in case of negative results) or to roll it out to more users or all users (in case of positive results).

Continuous Measurement

Continuous Measurement is about constantly tracking the metrics associated with products, engineering health, and overall processes.

Broadly, these metrics can be divided into three types:

1. Business Metrics – These metrics directly reflect the product’s impact on the business. Business metrics can include engagement rates, user acquisition amount, retention rates, revenue per user, etc. By measuring these, teams understand how their work contributes to larger organizational goals; therefore, engineering leaders must raise awareness about those metrics with their teams.

2. (Engineering) Operational Metrics – These metrics focus on the systems' stability, reliability, scalability, performance, etc. Operational metrics include system uptime, error rates, latency, incident response times, etc. They give teams a view of the tech stack health - typically, teams will have monitoring and alerting for those metrics.

3. Execution Metrics – These metrics track the productivity and efficiency of engineering teams. Examples include sprint velocity, code merge frequency, number of PRs, and build-deployment times. Execution metrics should help engineering leaders find areas for improvement in terms of efficiency; for instance, a downward trend in the number of PRs could indicate a bottleneck.

Engineering leaders should constantly monitor those metrics and set an example for the team, fostering a data-driven mindset.

For example, regarding engineering operational metrics, a process I experienced at a few companies is having a Weekly Operational Metric Review forum. In this session, each engineering leader will present noticeable regressions/progressions for the key metrics of a specific area. For instance, a Messaging engineering lead might show an ongoing regression with the send message performance metric in a particular week. She will present the details and root causes for this issue and follow up with remediation items the following week. This forum pushes accountability from each engineering team to stay on top of engineering health metrics.

Continuous Experimentation and Measurement are fundamental areas in the CSE framework that align software development with business impact. Experimentation encourages teams to make data-driven decisions, validating hypotheses through A/B tests. Measurement drives teams to focus on data, constantly monitoring the business's health, tech stack, and execution.

In the previous post, I discussed how Continuous Planning and Prioritization enable teams to stay responsive and aligned with changing business and customer needs. Now, we’ll look into two more areas of the Continuous Software Engineering framework (see paper): Continuous Development and Continuous Quality Assurance. 

These activities ensure that teams continuously build and maintain high-quality software and are directly connected with the craftsmanship and quality attributes discussed in a previous post.

Continuous Development

In the Continuous Software Engineering (CSE) framework, Continuous Development is about “building”. It includes practices that ensure software is iteratively delivered to users, such as Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (CD) - which I assume are familiar to most of you. 

Continuous Integration (CI) ensures that new code is regularly integrated into the main (or master) branch to minimize integration issues and maintain a consistently functioning codebase. CI tools such as Jenkins or CircleCI allow you to integrate, build, and deploy the code to a selected environment.

Continuous Delivery (CD) refers to having code merged on the main (or master) branch ready to be released for production at any time. The code is automatically pushed and deployed to different environments, reducing lead times (you can read more here about the Change Lead Team DORA metric) and enabling faster delivery of new features. In Continuous Delivery, the deployment to production is not automated; the production push is typically a manual step.

Continuous Deployment (CD) can be simplified as Continuous Delivery plus automated deployment to production, eliminating the need for manual intervention when deploying.

However, beyond CI/CD, two critical aspects are often less discussed: Continuous pull requests and Continuous Architecture Evolution.

Writing Continuous Pull Requests (PRs) is the habit of engineers submitting PRs frequently and keeping them small and manageable. When PRs are continuously created, reviewed, and merged, it drives productivity, collaboration, and learning among the team members working on the same codebase. It prevents risky merges and makes code reviews more efficient and focused.

For example, in a group I led in the past, we adopted this practice: engineers were encouraged to submit incremental PR changes every day or other day behind Feature Flags (more on Feature Flags here)- a features flag was the first thing to be created for a feature. This practice significantly reduced integration issues, promoted knowledge sharing (see this previous post about the value of knowledge sharing), and maintained a high standard of code quality.

Continuous Architecture Evolution is about revisiting high-level design decisions in a continuous matter. Due to the ever-changing business, product requirements, and engineering discoveries, an active codebase needs to evolve the architecture or design of different pieces.

A critical practice in this area is continuously reviewing Tech Design Documents (TDD). TDDs are living documents that outline the architecture and technical decisions of a product feature. They are continually refined as the architecture evolves. In my experience, regularly revisiting these documents for active features or components helps teams ensure that architectural decisions remain flexible according to the product direction and discoveries.

For example, while managing the team working on the initial development of the Spotify Ad Manager (called Ad Studio back then), we frequently revisited our tech strategy doc along with the different releases (from alpha to beta to public release). For example, in the Payments area, we moved from leveraging integration with Paypal to integrating with Adyen and then to integrating with the internal Spotify payments API. We could make the necessary changes by continuously reviewing our design before they became more considerable technical debt.

Continuous Quality Assurance

Building software doesn’t stop at writing code; quality is also an integral part of the continuous process. Continuous Quality Assurance (QA) ensures that software is tested and validated at every step of the development cycle. This approach is far more effective than the traditional waterfall approach that typically introduces testing as a final step.

Continuous Verification and Validation (V&V) ensures that code changes meet quality standards before they reach users.

Continuous verification focuses on verifying the actual behavior adheres to the expected behavior for specific requirements. Continuous validation ensures that the product meets the users’ needs and delivers the intended business value.

A combination of automated testing and dogfooding are good examples of practices within continuous quality assurance.

Automated testing integrated into the CI pipeline ensures that as developers continuously merge code into the main branch, the system automatically verifies the functionalities and discovers regression issues and performance bottlenecks.

For example, in every team where we had a comprehensive test suite with unit, integration, and end-to-end tests,  the teams could deploy features faster while maintaining confidence in the quality of the software. Engineers could focus on delivering new features, knowing that our test suite would catch regressions or performance issues early.

Dogfooding allows you to experience the product like your customers; see my previous article for more details. For example, at Snap, we relied heavily on dogfooding to release features safely.

Finally, manual QA should not be overlooked either. Techniques like exploratory testing and user feedback loops ensure that edge cases are tested before production releases.

With Continuous Development and Continuous Quality Assurance, teams can build software faster and ensure that quality is maintained throughout the process. Practices like Continuous Pull Requests and Continuous Architecture Evolution contribute to having teams excel in craftsmanship and adaptability, and embedding quality assurance into every step provides better confidence in what is delivered.

In a previous post of this series, I defined excellence in engineering teams through five core characteristics (effectiveness, craftsmanship & quality, efficiency & productivity, adaptability & learning, collaboration & communication). In this post, I’ll explore how adopting a Continuous Software Engineering (CSE) approach can help teams achieve these characteristics.

This framework emphasizes continuous iteration across the entire software development lifecycle. Initially introduced in this paper by Brian Fitzgerald and Klaas-Jan Stol in 2014 and further expanded in Jan Bosch’s book “Continuous Software Engineering”, it focuses on a series of practices emphasizing the continuous nature of software-building activities, defined with the term ‘Continuous *’.

I’m going to revisit the framework with my take, and I will dive into the following ‘Continuous’ activities:

• Planning and Prioritization

• Development

• Quality assurance

• Experimentation & Measurement

• Improvement & Innovation

• Knowledge Management

This post will focus on Continuous Planning and Prioritization, the activities that enable teams to be adaptive and effective.

Continuous Planning

Building great software starts with understanding what is essential for the business and creating a plan that aligns with strategic goals (see my previous post on the meaning of strategy).

In many organizations, this typically happens as part of an annual planning cycle (in some places, this is called Operational Planning), where teams come together to define the key initiatives and roadmap for the upcoming year.  At a very high level, the outcome of this planning exercise is a list of initiatives associated with the team owning them and related dependencies.

While yearly planning is beneficial for setting a high-level direction, it often falls short in today’s ever-changing environment. 

 “Plans are dynamic open-ended artifacts that evolve in response to changes in the business environment, and thus involve a tighter integration between planning and execution.” from the paper ‘Continuous software engineering: A roadmap and agenda’

As customer feedback, market conditions, and business needs shift throughout the year, relying on a static yearly plan can limit a team’s ability to respond effectively. This is where Continuous Planning becomes essential. Continuous planning is an ongoing process where plans are frequently revisited and adapted based on new insights and data. This approach allows teams to stay responsive to change. 

For example, transitioning from an annual planning cycle to a quarterly cadence—leveraging frameworks like OKRs (Objectives Key Results)—enables teams to balance long-term objectives with more actionable goals. For more details on OKRs, refer to one of my previous articles. 

An example of a key ceremony that enables continuous planning is Quarterly OKRs planning.

During this multi-session event, engineering, product, and design leads come together to discuss priorities, allocate capacity, and define goals for the upcoming quarter. By reflecting on the results of lessons learned in the previous quarter and based on external factors, teams can make informed adjustments to their near-term roadmap and key results.

Continuous Planning ensures that while high-level outcomes remain consistent, the strategies and tactics to achieve them can continuously evolve based on learnings to optimize effectiveness.

A personal example of effective continuous planning occurred during my time at Pinterest. In one particular quarter, we planned to build a new tab dedicated to shopping within the iOS and Android apps. The initial plan was to add a dedicated shopping experience for our users. However, after two quarters of development and gathering early market feedback, we realized that the direction wasn’t aligned with the user needs and changes in the market.

While the high-level objective for the year—improving user engagement in the shopping space for Pinterest users—remained unchanged, we decided to pivot away from the original plan for the shopping tab and reallocate resources to meet users where they are. This was a clear example of how revisiting plans regularly ensures that teams stay aligned on what is relevant and important.

Continuous Prioritization

Contingent to continuous planning, Continuous Prioritization is about frequently adjusting priorities to stay aligned with evolving plans. Engineering and product leaders are responsible for defining these priorities, which include roadmap items, customer support issues, technical debt, and longer-term technical strategy.

Prioritization in this context must be fluid and flexible, accommodating each item's importance and urgency. Similarly to continuous planning, this dynamic approach ensures that teams remain focused on the most impactful work while being flexible enough to shift focus as new data or challenges arise.

The Leads Weekly Sync is an example of a critical ceremony I experienced that enabled continuous prioritization. This forum lets the EM and PM of a team regularly meet to review and adjust team priorities based on the most recent data and developments. This allows for constant re-alignment between short-term efforts and the defined plan.

With Continuous planning and Prioritization (two macro-activities from the CSE Framework), teams are prepared to constantly adjust their plan and priorities while delivering value even as the landscape changes. This allows teams to become more adaptable and effective, two of the core characteristics of excellence discussed in the previous post.

This will be a different article from the others I’ve written before. This is an article to remember the person who has been my primary support for a lifetime and recently passed away: My Dad.

In this post, I want to share something deeply personal - a tribute to my father - that has shaped my approach to leadership in ways I couldn't fully appreciate until now.

My dad was a simple man with a great heart and a sharp mind. What my sister and I picked as a sentence on his grave was:

“Honesty was his main value,

Work his life,

Family his love”

Honesty and integrity were the primary values my dad was carrying. He always tried to do the right thing according to his values. 

My dad was brave, bold, and passionate - he never shied away from expressing his opinion.

My dad was a teacher. That was his profession. He dedicated over 40 years of his life to teaching “educazione tecnica” (“technical education” in English, but there is no similar subject in the US) in middle school. His students loved him; I often remember lots of his previous students approaching me to say hi to him in the past. Lots of his students came to visit during the viewing as well. He was also a teacher for my sister and me; he taught us a lot about the important things in life.

He transmitted my passion for writing software and programming. In the 90s, he started learning BASIC, sharing his knowledge with me. Because of him, I started programming when I was in middle school. This is when I decided I wanted to study software engineering.

My dad didn’t care about money. He barely spent money on himself and never on unnecessary things. My dad taught me that health and family are the most important things, and he always prioritized family and health for his family. He taught me that accumulating money is not the end goal of life; money is just a way to accomplish important things, and you can have a great life without being rich.

My dad was a giver. He dedicated his life entirely to his kids, especially after my mum passed away almost 19 years ago. He did a lot for my sister and me; we were always at the center of his thoughts. He was not a taker at all. Every time we gave him a present, his reaction was, “Don’t waste money on this.”

My dad was loved by many people. Many people had stories about him, telling us the good advice he could provide with his generosity, good heart, and good spirit. 

My dad was a unique man; he was passionate about his vegetable garden. Growing a garden was his hobby and his way of spending time “building” things. It also was his way to provide natural and healthy food for us.

Overall, my dad was a leader. He was a man people listened to and followed. Many of his traits are things great leaders should have: honesty, integrity, passion, prioritization, growing others, advising, and generosity.

My father showed me that true leadership begins with who you are, not just what you do.

Here are a couple of photos with my father, who dropped me off at Milano Malpensa airport before I returned to the U.S.

Here’s an article from the local newspaper about him (in Italian)

Thank you for everything, Dad. You’ll always be my source of inspiration. ❤️

Grazie di tutto Papa’. Sarai sempre la mia fonte di ispirazione. ❤️

This series of articles will explain how to use Continuous Software Engineering (see this paper from 2014), a framework to promote excellence in engineering teams. 

In this first article, we will set the context - we will define excellence in engineering teams (in my view).

Read more

In our previous article, we covered the importance of Vitamin B in maintaining energy and health and how this can be compared to psychological safety for engineering teams. Today, we turn our attention to Vitamin C, an important micronutrient to build resilience in our body. Parallely, engineering leaders could use compassion to build resilience in teams, especially in unpleasant or challenging times, such as company layoffs or strategic shifts.

Vitamin C & Compassion to Build Resilience

Vitamin C is a water-soluble vitamin (similar to Vitamin B) that must be consumed regularly since it isn’t stored in our bodies. Vitamin C helps with the healing process in our body and protects against harmful free radicals, being an antioxidant. Vitamin C is crucial for iron absorption and collagen production, lowering cancer risk, and regenerating Vitamin E. This vitamin is found in foods like bell peppers, black currants, citrus fruits, cruciferous vegetables, and strawberries; its adequate intake is 90 mg daily for men and 75 mg for women, and the Upper Limit is 2000 mg daily. 

Vitamin C is crucial to building physical resilience.

Similarly to Vitamin C, compassion builds emotional and psychological resilience within teams. Compassion starts with empathy—understanding others’ feelings and putting oneself in their shoes.

True compassion, however, goes beyond empathy and involves taking action to support and alleviate others' difficulties.

As a leader, compassion is key to developing healthy and resilient teams and can be expressed in multiple ways.

Compassion Through Communication

Communication is the foundation of a leader's operation because a compassionate communicator helps create psychological safety in a team (more on psychological safety in the previous article). In challenging times, leaders must engage in transparent and empathetic communication. This means having private one-on-one conversations, actively listening to team members’ concerns, and providing context for difficult decisions. For instance, if a whole department is eliminated due to a strategic change, a compassionate leader will explain the reasons to the team, addressing their doubts and fears rather than avoiding tough conversations.

AMAs (Ask Me Anything) sessions are also excellent tools for leaders to incentivize open communication and show genuine concern for their team’s well-being, letting people ask any top-of-mind question.

For example, in one of my past experiences, I let go of a few people for business reasons. Huddling with the team through an AMA session was very helpful for people to express their emotions and clarify the business decision. Those decisions are hard, but leaders must focus on the people remaining on the team and provide compassion to them.

Compassion Through Giving Space and Time

Leaders can support their teams by giving them space and time to cope with tough situations. Encouraging breaks, organizing team-building activities, or dedicating time to innovate can help teams recharge and handle stress better.

For example, after a stressful period of time for the team, a leader might schedule a team onsite or allocate a Hackathon for a few days to let team members work on projects unrelated to the current OKRs. These activities not only boost morale but also foster a sense of innovation.

In fact, in one of my past experiences, one of my teams worked hard for 6 months on a project, and given a global change of strategy, the project was disbanded. Giving a day off to people and the remaining days of the week to work on a passion project was a refreshing way to have people handle this challenging situation.

Compassion Through Giving Direction

Leaders need to reinforce the mission and vision, especially during challenging times. For example, if part of a team gets laid off, a leader should disseminate the new directions and strategy.

In a past experience, when a team needed to work over multiple weekends to complete a project within a strict timeline, it was crucial to clearly explain to the team the necessity of meeting the deadline for the hard work. It was also important to highlight the impact of the work and how it connected with the overall company goals.

Another action that helped maintain motivation and increase team resilience was recognizing the most effective people (more on recognition in this previous article) and expressing gratitude during weekly meetings.

Just as Vitamin C is indispensable for physical resilience, compassion is vital for team resilience. 

Engineering leaders can build resilient teams in the face of adversity by practicing compassionate communication, giving space and time, and providing clear direction.

In the previous article, we looked at how maintaining a good level of Vitamin A helps our body with vision. In the same way, “dogfooding” can help teams see what customers need.

This article will explore the parallel between B Vitamins and psychological safety. Vitamin B (there are actually multiple types of B Vitamins) is an essential nutrient that supports energy levels and keeps blood cells healthy. Metaphorically, Psychological Safety in a team is similar to B Vitamins, which are necessary to keep the team healthy, motivated, and energetic.

The B Complex of Team Health

Vitamin B is a complex of eight different vitamins (all water-soluble vitamins — which means are not stored by our body), each with a unique role in maintaining body health:

• Vitamin B1 (Thiamin) helps break down and release energy from food. The best food sources are wheat germ and pork.

• Vitamin B2 (Riboflavin) supports cellular energy production and protects cells from damage. The best food sources are spinach, tempeh, and yogurt.

• Vitamin B3 (Niacin) keeps the nervous and digestive systems healthy and helps produce energy from food, similar to Vitamin B1. The best food sources are chicken, bluefin tuna, and salmon.

• Vitamin B5 (Pantothenic Acid) helps release energy from sugars and fats and helps to deal with stress. The best food sources are shitake mushrooms and avocado.

• Vitamin B6 (Pyridoxine) helps break down sugar and fat, influences mood, and reduces symptoms of depression. The best food sources are chicken, wheat germ, and spinach.

• Vitamin B7 (Biotin) helps with carbohydrate and fat absorption. The best food sources are yeast, eggs, and salmon.

• Vitamin B9 (Folate) helps with healthy red blood cells and cell growth. The best food sources are asparagus, chicken, and edamame.

• Vitamin B12 (Cobalamin) releases energy from food, similarly to other Vitamin Bs. It also helps with the production of red blood cells and cell metabolism.

In a team, psychological safety—the belief that people can be themselves at work and are comfortable being vulnerable and making mistakes, asking questions, and proposing new ideas—acts like these vitamins, creating a healthy work environment that encourages growth and releases energy.

Psychological safety and effective teams

Psychological safety is a key sauce engineering leaders need to use to shape healthy engineering teams. According to the research done at Google in Project Aristotle, it is one of the five team dynamics to build effective teams. To use the definition used in the research article:

Psychological safety is about risk-taking and being comfortable with vulnerability. People who don’t feel psychologically safe worry that taking risks will mean they’re seen as ignorant, incompetent, negative, or disruptive. Psychological safety means feeling confident about admitting mistakes, asking questions, or offering new ideas.

The 4 Stages of Psychological Safety

In his book “The 4 Stages of Psychological Safety: Defining the Path to Inclusion and Innovation,” Timothy Clark defines psychological safety in four sequential stages, which can be thought of as a pyramid.

At the foundation of psychological safety, the first stage is “Inclusion Safety” which is associated with inclusiveness in teams.

How do engineering leaders enable inclusiveness in teams?

Engineering leaders should ensure everyone can express their opinions freely and with respect. For example, in a team meeting, it is important to facilitate the conversation organically, including introverts’ points of view, either from comments on documents or explicitly giving them space during a meeting. The audience must respect each opinion, so it’s also essential for a leader to call out or address if somebody is diminishing somebody else’s opinion.

After the team feels “inclusion safety”, the second stage is “Learner safety” which is associated with continuous learning.

How do engineering leaders enable continuous learning in teams?

Engineering leaders need to emphasize learning over mistakes. For example, during a post-mortem triggered by an incident, engineering leaders should focus on the lessons learned and what can be done to avoid the same issue in the future instead of pointing fingers at who made a mistake. Continuous learning is an evolving journey and one of the key concepts even Socrates talks about; you can read more in this previous article I wrote.

An environment where team members lack “learner safety” is typically a dysfunctional team with an “absence of trust,” referring to one of the five dysfunctions of teams mentioned in Patrick Lencioni's book “The Five Dysfunctions of a Team”.

Going up the pyramid, the third stage is “Contributor safety” which is associated with autonomy and accountability.

How do engineering leaders enable autonomy and accountability in teams?

The key elements here are trust and setting clear expectations. When an engineering leader delegates an activity to a team member or manager, she needs to set the expectations, let the team members operate, and then evaluate the outcome of what was delegated. For example, a newly promoted engineering manager named John, reporting to Sally, is now managing a team. In this case, Sally should define the expectations about the new role and evaluate whether John is enabling people to be successful and unblocking them. Instead of attending all the ceremonies for that team and chiming in all discussions, Sally should observe and give time to John to learn and contribute to the team. She should trust John and gather whether her expectations were met, letting John contribute as John feels appropriate. At the same time, John needs to be accountable for the team and have a sense of ownership in how he behaves and operates.

An environment where team member don’t have “contributor safety” is typically a dysfunctional team with “avoidance of accountability” and/or “lack of commitment”, and/or “absence of trust”, again referring to the book “The Five Dysfuctions of a Team”.

The last stage in psychological safety is “Challenger safety” which is associated with candor.

How do engineering leaders enable candor in teams?

Engineering leaders need to set an example here. They should encourage, acknowledge disagreement, and thank people who express different opinions. In situations involving authority, it can be challenging for a subordinate to disagree, so it is crucial to thank the person who expresses a different opinion. For example, let’s say there is a retrospective and a discussion around a process improvement. Having a team member express a different point of view from the manager’s perspective can help find a better solution. The manager should be appreciative because this improves the overall outcome of the team.

An environment where team members don’t feel “challenger safety” is typically a dysfunctional team with a “fear of conflict,” again referring to one of the dysfunctions described by Patrick Lencioni.

Just as a deficiency in any B vitamin can lead to poor health, neglecting aspects of psychological safety can lead to a dysfunctional team environment. Ensuring your team is well-nourished with the B vitamins of team health will create a thriving, dynamic, and innovative workplace.

The last three articles explored the parallels between macronutrients and team management elements: carbs were seen as motivation to inject energy into teams, protein as continuous improvement to build team strength, and fat as strategic thinking for long-term sustained team health.

In this article, we will begin shifting our focus to micronutrients. We will start with Vitamins, specifically Vitamin A. Vitamin A is a fat-soluble vitamin, which means it’s absorbed with fats. Aside from strengthening immunity against infections, Vitamin A is essential for maintaining healthy vision and helps convert light into signals our brains can interpret, enabling us to see clearly. In engineering teams, clear eyesight can be thought of as deeply understanding customer needs and the product the teams work on.

One effective method to achieve this is “dogfooding,” a practice where team members use and test their products to identify potential improvements, find bugs, and think about new solutions. This process ensures that teams remain closely connected to the user experience, mirroring the role of Vitamin A in enhancing and maintaining eyesight.

How to provide Vitamin A to your body 

We clarified that Vitamin A is important for your health - how can you provide it to your body through food?

Vitamin A, in its preformed (ready-to-absorbed) version as retinol or Vitamin A1, can be found in foods such as beef, liver, and dairy products.

Your body can also generate retinol from carotenoids (such as alpha-carotene, beta-carotene, gamma-carotene, and beta-cryptoxanthin), which are plant-based precursors to Vitamin A. Foods with high concentrations of carotenoids are orange and yellow fruits and vegetables, such as butternut squash, pumpkins, sweet potatoes, carrots, and persimmons.

How to instill dogfooding in your teams

In a parallel way, how do you instill “dogfooding” in your teams? Engineering leaders should advocate for a culture of dogfooding, ensuring that teams regularly engage with the product just as consumers would.

1. Engineering leaders should lead by example and be the first to engage with the product, testing features and publicly reporting issues or improvements (via email or Slack).

2. If a team doesn’t do dogfooding right now, one way to kickstart this practice is to pick a theme or feature every week and arrange a meeting of an hour (or half an hour) for the team to get used to testing and using the product.

3. Engineering leaders could also recognize people who submit many issues to incentivize the behavior.

4. Leaders should also refine the process around “dogfooding”. For example, you might want to apply dogfooding to internal versions of your product that have yet to be released. For a mobile product, your company might need to support the creation of a separate internal app associated with your master/main build updated frequently. For a web product, you might use a staging or pre-prod URL where the changes are integrated.

This practice makes the team more user-centric and helps foster a deep sense of empathy and understanding for the consumers using their product. For example, I experienced a strong culture of “dogfooding” at a couple of companies (Snapchat and Pinterest), where employees using the internal app logged tens of bugs daily and weekly. This helped teams find bugs before releasing them to the public and built a culture of ownership and accountability.

Challenges with dogfooding

There are also challenges with “dogfooding”. Team members might not represent the typical users or the whole variety of users a company has, so it’s important to avoid biases. Product and engineering leaders must be aware of the diversity of users using their products and ensure that dogfooding is just one input. In the same way, vitamin A is not the only element needed for good eyesight.

In companies where this practice is widespread, another challenge can be the overload in triaging all the incoming tickets raised by internal employees and for example, in some cases, the high number of duplicated tickets. Similarly, too much Vitamin A (the current Upper Limit is 3,000 mg of retinol) can cause vertigo, nausea, or blurry sight. It is worth noting that this can happen only using supplements; it will be pretty impossible to get to a similar amount from just eating food, especially plant-based (E.g., 1 cup of baked sweet potatoes gives you 23mg of beta-carotene which gets converted into around 12mg of retinol).

In conclusion, an adequate level of Vitamin A in your diet is key to avoiding night blindness and issues with eyesight. In the same way, dogfooding is important to have a team that sees how the user experiences its product and builds a culture of ownership, empathy, and accountability.