The answer to “What does it mean to be a good engineering manager?” really depends on when you asked that question. It was different a few years ago and it’s something else now. That’s because the tech industry itself has been changing so much.

One thing became clear to me in my 15+ years in the industry:

The role of Engineering Managers has always been defined by the market, not by individuals.

Here’s how the definition has changed over the years during my career and how we can prepare for 2026.

The Project Manager Era (Early 2010s)

When I worked at Intel as a software engineer in the early 2010s, I barely had any 1:1s with my manager. I never got any useful feedback or meaningful performance review. No clear expectations or career growth conversations.

And that was common in other companies as well. Management was about day-to-day execution. Managers assigned tasks and asked for status the next morning. The idea was to keep the “factory” running.

Engineering management was basically project management. But even that was done in a very waterfall way. There was no planning or estimation. The work was mostly in manager’s head. They assigned and checked regular status.

But it worked at that time. Teams were stable. Growth was slow but steady. The market rewarded output and reliability more than efficiency and speed.

The People-First Shift (2017–2019)

Around 2017, things changed.

My then manager focused much more on people: hiring, onboarding, retention, performance evaluation, and career conversations. I saw that managers intentionally stayed away from technical details and delegated heavily. This was when terms like “psychological safety” and “radical candor” became really popular.

This is also when I transitioned into a tech lead role and started learning this new style of management. Manager’s success was measured by how independent the team was. Advice like “Hire smart people and get out their way” and “Make yourself redundant” became overused.

This model felt more modern though. It gave a very enlightened vibe. And we went too far.

The Peak and the Crack (2020–2021)

That approach peaked during Covid.

Remote work reduced visibility. Managers didn’t know how to manage remotely so they started trusting even more. They operated people-first. But many felt increasingly disconnected from delivery and outcomes. Holding people accountable became uncomfortable. Sometimes impossible.

Besides, job opportunities were abundant. Attrition risk was everywhere. Managers were expected to support everyone, retain, and somehow still ship.

Many felt helpless but even they were not subject to accountability. Even companies didn’t know how to handle so they said stuff like “Take care of yourself first, work can wait.”

But that wasn’t gonna last forever.

The Correction (2022–2025)

The market tightened. Money wasn’t cheap anymore.

So layoffs became common. Budgets shrank. Orgs flattened. And reorgs became a routine thing.

This happened right after I stepped into formal management. (Yes, I’m the guy who buys a stock and tanks the whole company 😅)

I found myself in the middle of changing expectations. I had to learn to

• Handle layoffs

• Manage PIPs

• Work with reduced capacity

• Deal with engineers’ frustrations

• Raise the performance bar

These were skills most EMs in the 2010s never had to develop but they were table stakes now.

A lot of managers had to lose their jobs. They may have been the best managers in the previous era but they weren’t considered good now.

What’s in 2026 and beyond?

Is this the new normal now? Have we found the ultimate model? Is this how managers will operate forever?

No. I’m sure it’s going to change again. But it may get worse before it gets better. AI is already challenging everything. From how we build to how we organize to how many people we need.

So how do we prepare ourselves? What should we do to thrive?

I’m gonna focus on these four things myself. But keep in the mind the core strategy - Engineering managers exist to make the team better and provide value to the company.

1. Technical understanding

I don’t necessarily want to be a programmer again. But I want to be deeply technical. I’ll measure myself in terms of my ability to:

• Understand system designs

• Challenge designs from others

• Engage in deeper discussions without being hand wavy

• Use AI coding tools

The speed of this understanding is going to be important as well. How do you understand large complex systems?

From past experience, I can tell that can be achieved by treating certain areas as black boxes. I don’t have to understand all at once. I abstract the things I don’t understand. Like if I don’t know Apache Spark or Kafka, that’s fine. Do I understand how it plugs into our system and what role it plays? Yes? Then great start. And then gradually open the black boxes.

2. Bringing clarity

With the industry moving faster than ever, there is more chaos. With so many things going on at once, engineers are overwhelmed.

• What AI tools to use?

• How is my job changing?

• How to adapt?

• How to align to new leadership and org?

There are new problems to solve. New bars to meet.

The best thing an EM can do is help the team get some clarity. I know even you as an EM are feeling overwhelmed with the changes and have no answer. But you should be able to define the direction the team should be heading. Break it down into short-term and long-term. You may get it wrong sometimes, but that’s ok. Iterate on it. But they need some clarity today, not after the fog clears on it’s own.

3. Staying organized

Again, to keep the chaos under control, keeping everything organized will help you make quicker decisions.

Do you know exactly what the team is working on, on a given day or week? Are the projects broken down correctly? Are the design docs created and easily findable? Do you have a sense of redundancy, backup, etc.?

See where you’re getting surprises and see how you can get organized around that. A lot of times, it’d mean adding a new process. Engineers might hate you for that. But if you put the right process, they will thank you later.

One such process is a Team Working Agreement.

4. Teaching others

Now a lot of managers try coaching and giving feedback. And that works for some engineers but not for the majority.

Because feedback and coaching leave the action completely up to the individual. Like, I’d just recommend a course or a book and follow up on it. But I realized that is a long loop. They may learn something but not exactly what’s needed from them in their current role and at the right time.

In 2026, I recommend more of a teaching approach.

Teaching is time consuming but worth it. I’ve been practicing this lately. I identified a couple of skills for a couple of people and set up a daily 30 minute 1:1 for 6 weeks. I taught them “how to write effectively” and “how to be a scrum lead”. I prepared some notes and topics. I pulled up some of their past examples. For the most part, it was like feedback session but it didn’t stop there. I also showed what good looks like and how to practice it.

And in that whole process, I felt so proud to see them grow and as a bonus, I got even better at those skills myself.

That’s it folks! Not gonna summarize because this is already a long post.

More Resources

• Great article collection written by that covers the impact of end of zero interest rates.

• The article from Will Larson that inspired my post: https://lethain.com/good-eng-mgmt-is-a-fad

What can I say, I love cleaning fountain pens! Why? Who can really say. But we all have certain little unexplainable intricacies that make up our personalities, and mine seems to be that when I’m no longer using an inked fountain pen regularly, I love returning it to that (almost) brand new state it was in prior to inking it.

If you look around my desk, you would be shocked that cleaning fountain pens would be one of my things. I will admit that the process isn’t a picnic at the park, but I’ve learned how to clean fountain pens fast and well over the past decade. Here are a few givens when I clean pens.

Tap water is fine.

I’ve only ever used my kitchen sink to clean, including water directly from the faucet. For context, I practice good fountain pen maintenance. I’m never in a situation where ink has gunked up the inner workings of a pen, stained it, or had any other issue caused by it sitting for months on end, unused.

If I did find myself in that situation, I would use my sink setup as much as possible, and then move to a bath with distilled water in an ultrasonic cleaner. I cannot tell you the last time I broke out the ultrasonic clear - it’s been that long.

If the pen is still not clean after that, it may be time to look at a fountain pen flush, or make your own.

Last note on my sink - it’s stainless steel. I wouldn’t use any other surface to splash ink around in. If that isn’t an option, an ultrasonic cleaner may be more of a priority. This is the one I bought in 2016 (Amazon affiliate link,) and I think it is still a good recommendation.

Nibs and feeds can sit and soak.

When possible, I like to remove the nib and feed from the housing. This isn’t always possible, nor is it always necessary. But for nibs where this is easy to do (Jowo #6 nib, for example,) I’ll always disassemble them. This allows me to get any stray ink my regular flushing didn’t clean all the way out.

Disassembling a fountain pen nib and feed, and dropping the parts in a bowl.

Once taken apart, I’ll rinse them out in my hand (be sure your drain isn’t going to gobble these small parts up!) If they are clean after that, I’ll set them on the towel to dry. If the feed is still holding ink, I’ll drop it in a bowl and let it soak for an hour or so. Rinse and repeat, literally.

Modernize your Booger Suckers.

As an avid believer in the nasal aspirator cleaning method, I’ve modernized my tools over the years. I mainly use the Schon DSGN Luer Syringe Pen Cleaning Tool System, which has custom fittings to seal off many different sized pens for easy cleaning.

I own three - Jowo, Pilot, and Sailor - and those cover me for the majority of my cleaning needs. Are they mandatory? No. Do they make my life easier? Yes. I still have the booger suckers as backup.

Hot Schon DSGN Luer action. Watch as I move the nib around into clean water so I can see how it’s working.

Inky hands are expected.

This was the last picture taken just to show the results of any inky remnants after cleaning seven pens. Once I got over my fear of the mess - which I admit was a struggle in my early fountain pens days - everything became easier.

When cleaning pens, you are going to get ink on your hands. It’s a given, so I own it. I want my pens as clean as possible when I’m storing them away, so sometimes that means getting under the hood while there is still ink present. Once I’m done, I wash my hands with hot water and dish soap and go on about my day.

I’m lucky that I work from home, where inky hands are the rule, not the exception. If I had a presentation to give at work on Monday morning, and I had just gotten in a fight with a pen inked with Diamine Oxblood the day before, then yes, that might be an issue. For those cases, check out this list of tips for your options. For the rest of you, enjoy some of the Horror Stories from podcasts past.

Final notes.

I didn’t set a timer, but I’d wager I spent less than 20 minutes cleaning these seven pens. As I stated up top, my pens are clean to begin with, used as much as possible when inked, and don’t sit more than a week or two without being used. If you keep up with your fountain pen hygiene, it’s an easy process.

I do set up a workspace on the counter, with an 18” x 24” cutting mat, topped with a microfiber cloth. The cloth serves to catch any stray ink, like when I unscrew the barrel to get to the converter and need to set the nib down. It’s also for keeping pen barrels and small parts from rolling away. The mat underneath makes it so I can grab the entire setup and relocate the unassembled masses to a counter out of the way to dry, probably overnight.

And I think that’s it! I wasn’t intending this to be a step-by-step process for beginners, but rather a “hey look, this is pretty simple!” process. If you have any specific questions please don’t hesitate to leave a comment below and I’ll answer them ASAP.

BONUS SEGMENT!

While all of your pen cleaning stuff is out, be sure to fill any annoying pens with an eyedropper or syringe. The Pilot CON-70 is the best worst converter Pilot makes, and I never fill it in the pen. Grab a bottle of ink and blunt-nose syringe, load it, fill it, and since all of my cleaning stuff is still out, clean the syringe out right away before storing the rest of the goods.

---

Enjoy reading The Pen Addict? Then consider becoming a member to receive additional weekly content, giveaways, and discounts in The Pen Addict shop. Plus, you support me and the site directly, for which I am very grateful.

Membership starts at just $5/month, with a discounted annual option available. To find out more about membership click here and join us!

Something is coming. You can feel it if you talk to enough engineering leaders.

A quiet tension. A sense that AI isn’t just a new tool — it’s a structural shift.
A force that will reshape how we build, how we organize, and who we need on our teams.

But the conversation is often… shallow.

People keep asking “Will AI replace engineers?” or “Will it make teams 10x faster?” — as if output alone decides the future.

I think the real story is different.

The Myth of Faster Teams

Many leaders I speak with believe AI will make large teams go faster.

If we have 100 engineers today, we’ll deliver twice as much tomorrow.

But I’m on the opposite side of this debate.

Because speed itself is no longer the bottleneck.
Validation, discovery, and maintenance are.

We can already generate code at near-light speed.
That part is solved.

But just as anything nearing the speed of light experiences relativistic effects — time dilation, mass increase, and rising energy requirements — teams approaching “AI-assisted velocity” feel mounting forces of their own: more validation, more maintenance, more coordination load.

Faster creation → exponentially faster accumulation of responsibility.

And that pressure doesn’t scale linearly with the size of the team.

The Hidden Geometry of Overhead

Every engineer added to a team introduces new communication pathways.

The formula is simple:
Connections = N × (N – 1) / 2

• 3 engineers → 3 connections

• 5 engineers → 10

• 10 engineers → 45

• 50 engineers → 1,225

• 100 engineers → 4,950

This is why large teams swim in meetings, alignment docs, JIRA gymnastics, and endless “syncs.”

We built processes to compensate for scale — not because they are good, but because they are necessary when 100 people must row in the same direction.

But if AI gives us the ability to do more with fewer people, then shrinking teams isn’t just possible — it becomes strategically beneficial.

Simpler orgs.
Fewer communication lines.
Higher clarity.
Better focus.

For the first time in decades…
we can optimize for small.

Why It Hasn’t Happened Yet

A fair question people ask:

“If AI makes teams smaller, why didn’t we see it in 2024–2025?”

Because we’re still terrible at using AI well.

Many teams tried.
Most produced chaos:

• More output, worse quality

• Faster changes, higher defect rates

• Systems built fast… maintained slowly

During a 1:1 with one of my team's principal engineers, I discussed this challenge: juniors have already started using AI to generate code. It works and meets functional requirements. But it’s not scalable, full of gaps (security, architecture, etc.). Ultimately, it’ll lead us towards writing better specs, but for now… the engineer I talked to spends hours doing the code review.

Research confirms this: AI boosts output but also magnifies mess when teams don’t control the process.

We failed not because AI is bad.
We failed because we haven’t yet mastered how to drive it.

But some individuals have figured it out.

They can:

• Write specs

• Define architectures

• Use AI to generate clean features

• Validate output

• Ship cross-stack changes

One engineer, guided by AI, now delivers what previously required a small team.

It’s not widespread yet.
But it’s real.

Which means 2026 won’t be about “AI generating more.”
It will be about companies discovering they no longer need as many people to build the same amount of product.

The Real Future: Smaller Teams, Larger Impact

Marty Cagan, one of the influential product leaders, says:

The current generative AI-based tools are helping to improve the productivity of engineers by something in the range of 20-30%. (…) But in practice, it means that where you might have had 8 engineers on a product team, now you might have 5 or 6.

As AI matures and workflows stabilize, here’s what’s coming:

• A backend engineer can generate solid UI.

• A frontend engineer can scaffold backend services.

• A full-stack engineer can prototype an entire product — alone.

• A single team can cover what once required a full department.

Not because humans became superhuman.
But because the surface area of what one person can command expands when AI does most of the mechanical lifting.

This shifts the bottleneck.

The challenge won’t be building features.
It will be:

• choosing the right features

• validating them fast

• maintaining quality

• shipping safely

• solving real customer problems

This is where engineering leaders must re-anchor.

So What Should Engineers and Leaders Do Now?

If teams shrink — and they will — how do you stay indispensable?

Here’s the simple truth:

The people who thrive will be the ones who stop thinking of themselves as “coders”… and start thinking as “problem-solvers for the business.”

Let’s break it down.

1. Become Product-Oriented, Not Ticket-Oriented

Ask:

• What problem are we solving?

• For whom?

• Why does it matter?

• What is the metric of success?

If you can’t answer these, AI can’t help you — because you’re optimizing for output, not outcomes.

Engineers who understand the product context rise.
Those who don’t will be replaced by cheaper automation.

For a simple exercise about solving the right problems, have a look at the Problem Solving Framework.

2. Own the Full Lifecycle

Not just building.

But:

• scoping

• validating

• instrumenting

• monitoring

• quality

• SLO thinking

• pruning and deprecating features

• ensuring what exists actually works

AI amplifies creation.
Humans must amplify selection and judgment.

3. Learn to Drive AI With Clarity

The winners will be those who know how to:

• write crystal-clear specs

• define architecture before generation

• set constraints

• iterate with AI agents

• validate outputs quickly

This is a skill.
It’s not magic.
And it will separate professionals from button-clickers.

If you want to be better in driving AI, have a look on my book: From Engineers to Operators – AI Strategy Workbook for Engineering Leaders.

Free preview | Full book

4. Strengthen Cross-Functional Collaboration

Future teams look like micro product pods:

• 1–3 engineers backed by AI-assisted development

• 1 PM

• 1 designer

AI handles execution.
Humans handle intention and direction.

If you can speak fluently with PMs and designers, you’re future-proof.

If you can’t… now is the time to learn. Product Engineering Manifesto can help you with that.

Final Thoughts: The Profession Is Changing — But Not Dying

2026 won’t kill engineering.
It will kill the old model of engineering:

• Large teams

• Heavy process

• Slow validation

• Output-centric thinking

• Siloed skills

• Leaders who only “run JIRA”

What will survive — and thrive — are leaders and engineers who:

• understand the business

• love solving real problems

• shape products, not just code

• use AI as leverage, not as a crutch

• build small, focused, outcome-driven teams

The future belongs to designers of systems, not just writers of code.

And if you lean into that shift now,
you won’t just survive the shrinking of teams —
you’ll be the one people want to keep when the shrinking begins.

In this BONUS episode, we explore the organizational barriers that prevent companies from becoming truly software-native. Despite having proof that agile, iterative approaches work at scale—from Spotify to Amazon to Etsy—most organizations still struggle to adopt these practices. We reveal the root cause behind this resistance and expose four critical barriers that form what we call “The Organizational Immune System.” This isn’t about resistance to change; it’s about embedded structures, incentives, and mental models that actively reject beneficial transformation.

The Root Cause: Project Management as an Incompatible Mindset

“Project management as a mental model is fundamentally incompatible with software development. And will continue to be, because ‘project management’ as an art needs to support industries that are not software-native.”

The fundamental problem isn’t about tools or practices—it’s about how we think about work itself. Project management operates on assumptions that simply don’t hold true for software development. It assumes you can know the scope upfront, plan everything in advance, and execute according to that plan. But software is fundamentally different. A significant portion of the work only becomes visible once you start building. You discover that the “simple” feature requires refactoring three other systems. You learn that users actually need something different than what they asked for. This isn’t poor planning—it’s the nature of software. Project management treats discovery as failure (”we missed requirements”), while software-native thinking treats discovery as progress (”we learned something critical”). As Vasco points out in his NoEstimates work, what project management calls “scope creep” should really be labeled “value discovery” in software—because we’re discovering more value to add.

Discovery vs. Execution: Why Software Needs Different Success Metrics

“Software hypotheses need to be tested in hours or days, not weeks, and certainly not months. You can’t wait until the end of a 12-month project to find out your core assumption was wrong.”

The timing mismatch between project management and software development creates fundamental problems. Project management optimizes for plan execution with feedback loops that are months or years long, with clear distinctions between teams doing requirements, design, building, and testing. But software needs to probe and validate assumptions in hours or days. Questions like “Will users actually use this feature?” or “Does this architecture handle the load?” can’t wait for the end of a 12-month project. When we finally discover our core assumption was wrong, we need to fully replan—not just “change the plan.” Software-native organizations optimize for learning speed, while project management optimizes for plan adherence. These are opposing and mutually exclusive definitions of success.

The Language Gap: Why Software Needs Its Own Vocabulary

“When you force software into project management language, you lose the ability to manage what actually matters. You end up tracking task completion while missing that you’re building the wrong thing.”

The vocabulary we use shapes how we think about problems and solutions. Project management talks about tasks, milestones, percent complete, resource allocation, and critical path. Software needs to talk about user value, technical debt, architectural runway, learning velocity, deployment frequency, and lead time. These aren’t just different words—they represent fundamentally different ways of thinking about work. When organizations force software teams to speak in project management terms, they lose the ability to discuss and manage what actually creates value in software development.

The Scholarship Crisis: An Industry-Wide Knowledge Gap

“Agile software development represents the first worldwide trend in scholarship around software delivery. But most organizational investment still goes into project management scholarship and training.”

There’s extensive scholarship in IT, but almost none about delivery processes until recently. The agile movement represents the first major wave of people studying what actually works for building software, rather than adapting thinking from manufacturing or construction. Yet most organizational investment continues to flow into project management certifications like PMI and Prince2, and traditional MBA programs—all teaching an approach with fundamental problems when applied to software. This creates an industry-wide challenge: when CFOs, executives, and business partners all think in project management terms, they literally cannot understand why software needs to work differently. The mental model mismatch isn’t just a team problem—it’s affecting everyone in the organization and the broader industry.

Budget Cycles: The Project Funding Trap

“You commit to a scope at the start, when you know the least about what you need to build. The budget runs out exactly when you’re starting to understand what users actually need.”

Project thinking drives project funding: organizations approve a fixed budget (say $2M over 9 months) to deliver specific features. This seems rational and gives finance predictability, but it’s completely misaligned with how software creates value. Teams commit to scope when they know the least about what needs building. The budget expires just when they’re starting to understand what users actually need. When the “project” ends, the team disbands, taking all their accumulated knowledge with them. Next year, the cycle starts over with a new project, new team, and zero retained context. Meanwhile, the software itself needs continuous evolution, but the funding structure treats it as a series of temporary initiatives with hard stops.

The Alternative: Incremental Funding and Real-Time Signals

“Instead of approving $2M for 9 months, approve smaller increments—maybe $200K for 6 weeks. Then decide whether to continue based on what you’ve learned.”

Software-native organizations fund teams working on products, not projects. This means incremental funding decisions based on learning rather than upfront commitments. Instead of detailed estimates that pretend to predict the future, they use lightweight signals from the NoEstimates approach to detect problems early: Are we delivering value regularly? Are we learning? Are users responding positively? These signals provide more useful information than any Gantt chart. Portfolio managers shift from being “task police” asking “are you on schedule?” to investment curators asking “are we seeing the value we expected? Should we invest more, pivot, or stop?” This mirrors how venture capital works—and software is inherently more like VC than construction. Amazon exemplifies this approach, giving teams continuous funding as long as they’re delivering value and learning, with no arbitrary end date to the investment.

The Business/IT Separation: A Structural Disaster

“’The business’ doesn’t understand software—and often doesn’t want to. They think in terms of features and deadlines, not capabilities and evolution.”

Project thinking reinforces organizational separation: “the business” defines requirements, “IT” implements them, and project managers coordinate the handoff. This seems logical with clear specialization and defined responsibilities. But it creates a disaster. The business writes requirements documents without understanding what’s technically possible or what users actually need. IT receives them, estimates, and builds—but the requirements are usually wrong. By the time IT delivers, the business need has changed, or the software works but doesn’t solve the real problem. Sometimes worst of all, it works exactly as specified but nobody wants it. This isn’t a communication problem—it’s a structural problem created by project thinking.

Product Thinking: Starting with Behavior Change

“Instead of ‘build a new reporting dashboard,’ the goal is ‘reduce time finance team spends preparing monthly reports from 40 hours to 4 hours.’”

Software-native organizations eliminate the business/IT separation by creating product teams focused on outcomes. Using approaches like Impact Mapping, they start with behavior change instead of features. The goal becomes a measurable change in business behavior or performance, not a list of requirements. Teams measure business outcomes, not task completion—tracking whether finance actually spends less time on reports. If the first version doesn’t achieve that outcome, they iterate. The “requirement” isn’t sacred; the outcome is. “Business” and “IT” collaborate on goals rather than handing off requirements. They’re on the same team, working toward the same measurable outcome with no walls to throw things over. Spotify’s squad model popularized this approach, with each squad including product managers, designers, and engineers all focused on the same part of the product, all owning the outcome together.

Risk Management Theater: The Appearance of Control

“Here’s the real risk in software: delivering software that nobody wants, and having to maintain it forever.”

Project thinking creates elaborate risk management processes—steering committees, gate reviews, sign-offs, extensive documentation, and governance frameworks. These create the appearance of managing risk and make everyone feel professional and in control. But paradoxically, the very practices meant to manage risk end up increasing the risk of catastrophic failure. This mirrors Chesterton’s Fence paradox. The real risk in software isn’t about following the plan—it’s delivering software nobody wants and having to maintain it forever. Every line of code becomes a maintenance burden. If it’s not delivering value, you’re paying the cost forever or paying additional cost to remove it later. Traditional risk management theater doesn’t protect against this at all. Gates and approvals just slow you down without validating whether users will actually use what you’re building or whether the software creates business value.

Agile as Risk Management: Fast Learning Loops

“Software-native organizations don’t see ‘governance’ and ‘agility’ as a tradeoff. Agility IS governance. Fast learning loops ARE how you manage risk.”

Software-native organizations recognize that agile and product thinking ARE risk management. The fastest way to reduce risk is delivering quickly—getting software in front of real users in production with real data solving real problems, not in demos or staging environments. Teams validate expected value by measuring whether software achieves intended outcomes. Did finance really reduce their reporting time? Did users actually engage with the feature? When something isn’t working, teams change it quickly. When it is working, they double down. Either way, they’re managing risk through rapid learning. Eric Ries’s Lean Startup methodology isn’t just for startups—it’s fundamentally a software-native management practice. Build-Measure-Learn isn’t a nice-to-have; it’s how you avoid the catastrophic risk of building the wrong thing.

The Risk Management Contrast: Theater vs. Reality

“Which approach actually manages risk? The second one validates assumptions quickly and cheaply. The first one maximizes your exposure to building the wrong thing.”

The contrast between approaches is stark. Risk management theater involves six months of requirements gathering and design, multiple approval gates that claim to prevent risk but actually accumulate it, comprehensive test plans, and a big-bang launch after 12 months. Teams then discover users don’t want it—and now they’re maintaining unwanted software forever. The agile risk management approach takes two weeks to build a minimal viable feature, ships to a subset of users, measures actual behavior, learns it’s not quite right, iterates in another two weeks, validates value before scaling, and only maintains software that’s proven valuable. The second approach validates assumptions quickly and cheaply. The first maximizes exposure to building the wrong thing.

The Immune System in Action: How Barriers Reinforce Each Other

“When you try to ‘implement agile’ without addressing these structural barriers, the organization’s immune system rejects it. Teams might adopt standups and sprints, but nothing fundamental changes.”

These barriers work together as an immune system defending the status quo. It starts with the project management mindset—the fundamental belief that software is like construction, that we can plan it all upfront, that “done” is a meaningful state. That mindset creates funding models that allocate budgets to temporary projects instead of continuous products, organizational structures that separate “business” from “IT” and treat software as a cost center, and risk management theater that optimizes for appearing in control rather than actually learning. Each barrier reinforces the others. The funding model makes it hard to keep stable product teams. The business/IT separation makes it hard to validate value quickly. The risk theater slows down learning loops. The whole system resists change—even beneficial change—because each part depends on the others. This is why so many “agile transformations” fail: they treat the symptoms (team practices) without addressing the disease (organizational structures built on project thinking).

Breaking Free: Seeing the System Clearly

“Once you see the system clearly, you can transform it. You now know the root cause, how it manifests, and what the alternatives look like.”

Understanding these barriers is empowering. It’s not that people are stupid or resistant to change—organizations have structural barriers built on a fundamental mental model mismatch. But once you see the system clearly, transformation becomes possible. You now understand the root cause (project management mindset), how it manifests in your organization (funding models, business/IT separation, risk theater), and what the alternatives look like through real examples from companies successfully operating as software-native organizations. The path forward requires addressing the disease, not just the symptoms—transforming the fundamental structures and mental models that shape how your organization approaches software.

Recommended Further Reading

• Vasco’s article on 5 examples of software disasters that show we are in the middle of another software crisis

• NoEstimates movement: Vasco Duarte’s work and book

• Impact Mapping: Gojko Adzic’s framework

• Lean Startup: Eric Ries, “The Lean Startup”

• Outcome-based funding model

• Spotify squad model: Henrik Kniberg’s materials

• Chesterton’s fence paradox

https://traffic.libsyn.com/secure/scrummastertoolbox/20251225_XMAS_2025_Thu.mp3

About Vasco Duarte

Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.

You can link with Vasco Duarte on LinkedIn.

Download audio: https://api.substack.com/feed/podcast/181873657/903eee0fb5fad8af5703b63a243e7c0e.mp3