Most engineering leaders care deeply about delivering high-quality software. We invest in tooling, encourage automation, and set expectations around testing. But even with the best intentions, our efforts can quietly backfire.

A failing test suite, endless maintenance work, flaky tests no one trusts, these are more than automation problems. They’re signals. Signals that your quality strategy isn’t working as well as you think.

In past posts, I’ve explored how engineering culture, overloaded language (like what “done” or “tested” means), and unclear automation ownership impact quality. Today, I want to focus on a different angle: what the symptoms are telling us.

These are the patterns I see across teams: brittle frameworks, bloated suites, misaligned tools. More than bad practices these are quality antipatterns, and they come with real costs: slower delivery, decreased trust, and team frustration.

This post is a field guide for recognizing those signs, not just so you can fix your automation, but so you can rethink your quality strategy from the top down.

Let’s dig in.

Maintenance Overhead

Antipattern:
Teams often fall into the trap of “automate everything” without a clear strategy. The result? A bloated, slow, and expensive-to-maintain test suite that takes hours to run and frustrates everyone involved.

Cost:
This overhead drains productivity, demoralizes engineers, and slows down delivery. It’s a classic example of how “more” isn’t always better—especially when “more” isn’t thought through.

Better approach:
Align ahead of time on what to automate and why. Focus on value, not volume.

Brittle Frameworks

Antipattern:
Your tests shouldn’t fall apart every time someone changes a CSS class. But brittle frameworks do exactly that. They’re built on fragile assumptions and tight coupling to UI details, making them unreliable and frustrating. When automation isn’t designed for flexibility, even minor code changes cause widespread test failures. This brittleness undermines confidence in the test suite and leads to “test fatigue,” where teams start ignoring failures.

This is the second most common quality complaint I hear—and it's usually tied to the same root issue: lack of shared ownership and long-term thinking.

Cost:
Brittle frameworks erode trust in automation, increase pressure on testing, and slow down the feedback loop, making it harder to iterate quickly and confidently.

Better approach:
Invest in resilient test design. If a test breaks more often than it catches bugs, it's time to rethink it.

Misaligned Tooling

Antipattern:
Testers and developers using different tools, languages, or repositories create a disconnect. Testers bear the brunt of maintaining automation, while developers remain detached from quality efforts. Testers end up alone on an island, owning tools no one else understands. Engineers can’t (or won’t) contribute. And the rest of the team remains in the dark about test coverage and gaps.

This is inefficient and it erodes collaboration, creating invisible walls in your delivery pipeline.

Cost:
This misalignment leads to poor test coverage visibility, overworked testers, and a fragmented team culture. Quality becomes “someone else’s problem,” rather than a shared responsibility.

Better approach:
Choose tools your whole team can contribute to. Break down the walls between test and code. Read more about how to do that here.

Too Many Tests, Too Little Value

Antipattern:
When teams don’t align on goals, tests pile up, whether they’re useful or not. They often respond to production bugs by adding more tests, believing that quantity equals quality. Bloated test suites become slow, fragile, and overwhelming. And when bugs still make it to production (because they will), the instinct is to write even more tests, instead of asking if the right tests are in place - see the infinite loop we are getting into here?

And the irony is that most of the time, fewer, smarter tests provide better coverage and give testers room to do higher-value work, like exploratory testing, usability checks, and advocating for the customer.

Cost:
Valuable time is wasted on low-impact tests, while high-value testing (like exploratory, usability, or customer advocacy) gets neglected. The cycle of maintenance and brittleness continues.

Better approach:
Focus on coverage that matters, discuss test coverage with the whole team (including PMs), increase the visibility of what is covered, and gather diverse opinions. Don’t trade test quantity for actual quality.

Lack of Ownership

Antipattern:
As with everything else, when no one clearly owns software quality, everyone assumes someone else is responsible for it. Test failures go unnoticed, flaky tests are tolerated, and bugs sit unresolved (not because people don’t care, but because it’s unclear who’s responsible). This is especially common in teams where quality is seen as “QA’s or Testers’ only job” rather than a shared team outcome.

When teams lack a sense of ownership, small quality issues are ignored until they snowball into larger problems, like missed regressions, fragile releases, or broken pipelines that stay red for days.

Cost:
Test failures accumulate. Trust in the automation suite erodes. Engineers hesitate to make changes, fearing they will break something, and quality becomes reactive rather than proactive.

Better approach:
Make quality a team responsibility. Assign clear owners for addressing failing tests and flaky pipelines. Celebrate teams who fix root causes, not just symptoms. Build a culture where raising a quality issue is seen as a leadership move, not a complaint.

Ignoring Technical Debt

Antipattern:
Teams that chase delivery speed at all costs often leave a trail of messy code, outdated tests, and manual processes. “We’ll fix it later” becomes a mantra, but later rarely comes. As debt accumulates, velocity slows, bugs increase, and the system becomes harder to test, change, and deploy.

In test automation, this often shows up as abandoned test files, skipped test cases, or outdated frameworks that no one wants to touch.

Cost:
The codebase becomes fragile. New features take longer to deliver. Testing becomes more difficult and unreliable, and the team spends more time debugging infrastructure than building product.

Better approach:
Treat test infrastructure as product infrastructure. Include automation in hack weeks. Track test-related tech debt in your backlog and prioritize it with the same rigor as product work.

No Feedback Loops

Antipattern:
Teams ship bugs to production, fix them quickly, and move on, without asking why the bug wasn’t caught earlier. When teams skip retrospectives, don’t conduct incident reviews, or fail to act on root causes, the same problems resurface. Quality becomes a game of whack-a-mole instead of a system that learns and improves.

Without feedback loops, testing and automation strategies stagnate. There’s no data to inform better test coverage, no learning from failures, and no alignment on how to prevent future issues.

Cost:
Teams waste time fixing repeat issues instead of improving the system. The same types of bugs slip through again and again. Test coverage doesn't evolve with the product, and quality plateaus.

Better approach:
Build feedback loops into your process. Do postmortems, even for smaller bugs. Use production incidents as a source of truth to refine test coverage. Review bugs in retros to ask: “Should we have caught this? Where? How can we improve?”

Watch for the Drift

Most of these antipatterns don’t happen overnight. They creep in slowly, one skipped retro, one ignored flaky test, one hacky fix at a time. But over weeks and months, they compound. Spotting the signs early (and being willing to course correct) is the real mark of a mature team.

Subscribe now

Have you seen these antipatterns on your team? Or others I didn’t mention? Drop your thoughts in the comments or share this with a teammate who cares about quality. Let’s normalize talking about what doesn’t work, so we can get better at what does!

In software development, team culture and software quality are not separate goals. They are deeply interconnected. When one cracks, the other almost always follows.

Too often, leaders try to fix broken code by throwing more tools or processes at it, without addressing the real root cause: how people work together.

Let’s unpack that.

Subscribe now

What Is Team Culture?

Before we go deeper, it’s important to define what I mean by team culture. It is the invisible framework of shared values, habits, and expectations (spoken and unspoken) that shape how a team collaborates. It’s not just about fun Slack emojis or team lunches. It’s about:

• How people handle mistakes

• How feedback is given and received

• How deadlines are set, and respected

• How decisions get made and shared

Culture can be explicit, like team charters or engineering principles. But often, it’s implicit—baked into daily habits, rituals, and reactions.

Culture Problems Become Code Problems

As Jerry Weinberg famously put it in The Secrets of Consulting:

“No matter how it looks at first, it’s always a people problem.”

It’s easy to point to bugs in the code or flaky tests and say, “This is a technical issue.” But when you zoom out, you start to see the cracks in the human systems behind the software.

That last-minute bug that slipped into production? Maybe the team was rushing to meet an unrealistic deadline set without input from engineering.

That brittle legacy system no one wants to touch? Maybe knowledge transfer was poor because engineers didn’t feel safe asking “dumb” questions or documenting their work properly.

That “testers didn’t catch this” incident? Maybe the definition of “done” was fuzzy, or developers and testers weren’t aligned on what needed to be tested, and when.

More often than not, what looks like a purely technical failure turns out to be the result of:

• Misaligned expectations between stakeholders

• Gaps in communication across disciplines

• Lack of shared ownership around quality

• Or a culture of fear, where people hesitate to speak up, slow down, or challenge assumptions

If these continue to happen, they’re systemic issues. And unless we’re willing to address them head-on (just like we’d debug an API or refactor a messy codebase) they’ll keep resurfacing.

Because software is built by people, and when people aren’t aligned, the product reflects that disconnection.

Weak Culture Writes Fragile Code

Weinberg also warned, decades earlier in The Psychology of Computer Programming:

“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”

What he meant was: without a strong foundation of collaboration, accountability, and continuous learning, our systems will always be fragile, no matter how advanced the tools or experienced the engineers.

Because great software isn't just engineered. It's cultivated.

Quality Is a Team Sport

We can talk all day about test coverage, automation frameworks, or the latest deployment pipelines, and believe me, some days I do. But if you’ve been following my newsletter for a while, you know I’m a firm believer that quality is a team sport. It’s not just about tools or test cases, it’s about the environment in which we build and ship software.

Because at the end of the day, none of those practices matter if the team behind them isn’t aligned. I’ve seen teams with world-class tooling still struggle to deliver quality because they lacked trust, shared ownership, or psychological safety. And I’ve seen scrappy teams with minimal resources ship robust, reliable products, because they communicated well, embraced feedback, and held each other accountable.

Quality is never created in a vacuum. It’s shaped by a broad set of circumstances: how decisions are made, how risk is discussed, how mistakes are handled, and whether everyone actually feels responsible for the outcome. When those cultural ingredients are missing, even the smartest, most experienced engineers will struggle to prop up the system alone.

Strong teams build strong software. But when culture breaks down, no amount of individual brilliance can hold things together for long.

If you’ve ever worked on a team where culture lifted the quality of the work—or one where poor dynamics tanked a release—you know how true this is.

👉 How have you seen culture impact software quality? Share your story in the comments or forward this to a teammate who cares about both.

Language is one of the most powerful tools in software development, and one of the most dangerous when misused. Every day, software teams toss around words like 'test,' 'quality,' ' automation,' or 'done,' assuming everyone is on the same page. But what if we’re not? What if those words mean very different things to a developer, a tester, a PM, and a VP?

This is more than a vocabulary problem, it’s a collaboration problem. And when it goes unchecked, it leads to misaligned expectations, wasted effort, and bugs that could’ve been caught sooner.

Now, let me preface this: I’m not someone who loves getting into endless debates about semantics. I’m not here to prescribe universal definitions or fuel the ongoing arguments within the testing and quality engineering world about what each term should mean.

Yes, shared vocabulary matters. But what matters more (much more) is the clarity it enables in our day-to-day work. And clarity doesn’t have to come from industry consensus. In fact, I’ve found the fastest path to effective collaboration is not by chasing external validation, but by getting crisp on language within the team.

So yes, I’ll admit: I often take the easier, optimize for collaboration route. If the team agrees on what a word means, and it helps them move faster with fewer misunderstandings, I’m good with that. I care far more about alignment than correctness.

You might disagree. That’s okay.

But here’s the argument I’ll make: if we want to build better software together, we need to get better at noticing when we’re not actually speaking the same language. Let’s break that down.

Subscribe now

What Is an Overloaded Term?

An overloaded term is a word or phrase that carries multiple meanings—meanings that shift depending on your role, context, or company culture.

In programming, we know what overloaded functions are: same name, different signatures. In team communication, overloaded terms are sneakier. They sound familiar, but underneath the surface, they’re anything but aligned. Here’s what makes them dangerous:

• They feel precise, but are actually vague.

• They create the illusion of agreement.

• They prevent the clarifying conversations we actually need to have.

One Word, Many Meanings

Few words in software are as overloaded (and as misunderstood) as test. We use it constantly, often assuming we’re all referring to the same thing. But in reality, “test” can point to completely different activities depending on who you ask:

• To a developer: “I wrote unit tests and pushed to CI.”

• To a tester: “I ran exploratory testing on staging.”

• To a product manager: “The feature passed acceptance testing, right?”

• To a data analyst or growth team: “Let’s A/B test this in production.”

Each of these is technically a form of testing, but they serve different purposes, happen at different stages, and answer different questions.

So when someone says, “Did we test it?” the only right response is: “What kind of test are we talking about?” Without that clarification, your team may believe they’ve covered all the bases, when in fact, critical gaps might remain.

This is how bugs slip through. This is how confidence gets eroded. This is how “we tested it” becomes meaningless.

Defining what we mean by test (within the context of the team) is one of the most effective and underused ways to improve quality and reduce miscommunication.

Other Common Offenders

Here are a few more terms that often cause confusion:

• “Done” - Is the code merged? Deployed? Tested? Reviewed by design? Does it meet the Definition of Done? You’d be surprised how many teams don’t agree on this, and how often it derails delivery.

• “Automation” - Does it mean test automation? Infrastructure-as-code? Deployment scripts? GitHub Actions? You need context, or chaos follows.

• “Quality” - Is it about functional bugs? User happiness? System performance? Developer experience? You need to define it before you can improve it.

Why This Matters

Here’s the trap: we assume we’re aligned because we’re all using the same words. But as we’ve discussed, shared vocabulary doesn’t guarantee shared meaning. When teams operate on assumed definitions, all kinds of subtle failures start stacking up:

• Work gets marked as “done,” but turns out to be far from production-ready.

• Features “pass testing,” but no one tested the right thing.

• Bugs slip through, not because people weren’t working hard, but because they weren’t working in sync.

This isn’t a failure of effort. It’s a failure of alignment. And alignment starts with language.

In cross-functional teams, where developers, testers, product managers, designers, and stakeholders all need to coordinate, clarity in language is a superpower, it becomes operational glue.

When teams define what they mean, explicitly and early:

• Collaboration gets faster.

• Trust gets stronger.

• Handoffs become smoother.

• Quality improves, both in the code and in the team dynamic.

So yes, words matter. And if you want to build better software, start by building better shared language within your team.

How to Spot and Fix Overloaded Terms

Step 1: Notice the friction.
Are handoffs breaking down? Are retros full of finger-pointing? Those are signs that something wasn’t clearly defined.

Step 2: Call it out.
Try this in a meeting, when one of the most common overloaded terms talked about above pops up. For example: “Just to clarify, when we say test, do we mean unit tests or exploratory?” Small moment, huge clarity.

Step 3: Normalize precision.
Create team norms for language. Define your Definition of Done. Document what regression testing means in your context. Even a shared glossary in your Confluence or GitHub repo helps.

Build Shared Language, Build Better Software

Great software is more than code, it’s conversation. The more precisely we speak, the fewer assumptions we make. And fewer assumptions mean better systems, better collaboration, and fewer incidents. As an engineering leader or senior IC, it’s part of your job to build that clarity into the culture. Because when teams align on meaning, they align on expectations.

Bonus Idea: Make It a Team Exercise

At your next team meeting, try a word audit:

“Let’s list 5 words we use every week and define what they mean for us.”

You’ll be surprised how many different answers you get—and how many opportunities for alignment you find.

Have you run into overloaded terms in your teams? Which ones caused the most friction? Drop your examples in the comments—or better yet, share this post with your team and see if you agree on what “done” really means.

Last week, I posted an unpopular opinion on LinkedIn: if you want your automation strategy to succeed, your whole team needs to be involved. It turns out it was more controversial than I expected.

In this post, I want to break that idea down and get into the details of what involving the whole team actually means and why it’s essential if you want automation to deliver real value.

Define Clear Automation Objectives (Before You Write a Single Test)

No project succeeds without a clear goal, and automation is no different. Without shared objectives, your automation suite will drift fast. Here are three common objectives:

Enable faster development:
Good automation allows incremental, fast, and safer deployments, but only if these two conditions are met:

1. The suite runs fast enough to trigger on every commit.

2. It covers the high-risk, high-impact areas that the whole team agrees on.

Free up testers’ time:
Automation should liberate testers from repetitive work, freeing them to focus on real, investigative testing, which is the kind of work only humans can do well.

Raise red flags early:
Contrary to popular belief, automation doesn’t find bugs, it raises alerts. Only a human can determine whether a failed test is a real issue, a flaky test, or an environment glitch.

In reality, most teams will aim for a combination of these goals.

👉 Action: Document your objectives and make sure the team buys in before you start building.

What Whole-Team Involvement Actually Looks Like

When I say “whole team,” I mean everyone: engineers, QA, PMs, POs. Yes, even those who claim they "don’t know anything about automation." If automation becomes a side-project owned by one person, you’ll face two major issues:

Lack of coverage visibility:
If coverage decisions happen in isolation, the team won’t know what’s protected and what’s not until it’s too late. Worse, they may disagree with the choices made, causing friction and wasted effort.

Misunderstanding of tester workload:
Ever hear: “Why is testing taking so long?” If automation is invisible to the team, they’ll misinterpret the tester’s time investment. Making it squad work clarifies priorities and creates shared ownership.

💡 Important: Involvement doesn’t mean everyone codes the automation. It means everyone shapes the strategy. The tester still leads implementation.

Practical Ways to Involve the Whole Team

So, how do you go from a tester quietly building automation in isolation to a team that actively collaborates on automation strategy and coverage?

This shift isn’t just about holding one-off meetings or asking for quick sign-offs. It’s about embedding automation into the way your team thinks, plans, and delivers software. It means creating visibility, opening up conversations, and treating automation not as an integral part of how your team ensures quality. Here’s how to shift from solo automation to true team involvement:

Set up a team session to discuss coverage

Before diving into writing automation, carve out dedicated time with your team to align on what should be tested and why. This session is your opportunity to bring clarity, invite collaboration, and build shared ownership of your automation strategy.

Come prepared to lead the conversation with intention and structure. Your preparation will help make the best use of everyone's time and build credibility around the automation effort. Bring these with you:

• A map of the key surfaces your squad owns:
  This should include all major functional areas, services, and workflows the team is responsible for. Think in terms of customer-facing features (e.g., login, checkout), backend services (e.g., auth, payments), and shared components (e.g., design systems, APIs). Having this visualized, even in a simple spreadsheet or diagram, helps ground the conversation.

• Suggested critical paths that need protection:
  Come with a preliminary list of the most important user flows or service calls that, if broken, would result in high-severity incidents. Be ready to explain why you’ve selected them and ask for feedback. This isn’t about having the “right” answer — it’s about creating a starting point for productive discussion.

💬 Pro tip: Frame the session as a collaborative risk-identification workshop. You're not there to get sign-off — you’re there to co-create a shared understanding of what matters most, and how your team will protect it through automation.

During the session:

Discuss Test Coverage at Every Layer
One of the most impactful parts of involving the team is having an open discussion about test coverage across all levels of testing. This includes unit tests, integration and API tests, as well as end-to-end (E2E) automation. Too often, teams jump straight into automating at the UI layer without first asking:

• What’s already covered?

• Where are the real risks?

• What level of the stack is the most efficient place to catch issues?

Bringing the team into these conversations helps prevent duplicate coverage, identify blind spots early, and optimize where automation is most effective. For example, engineers might identify areas that can be tested more efficiently at the unit level, while testers highlight gaps in critical user flows that only E2E tests can catch.

This is what “shifting left” looks like in practice, not just talking about quality earlier, but embedding testability and risk assessment into the development process itself. By aligning on coverage strategy before writing a single test, teams reduce rework, improve feedback loops, and build more confidence in their delivery pipeline.

Identify the Critical User Paths
These are the workflows that, if broken, would immediately trigger a Sev 0 or Sev 1 incident. They represent your product’s non-negotiables — the functions that must work at all times. Think: login, payments, order placement, or core data flows.

This exercise isn’t just about listing features. It’s about partnering with product and business stakeholders to align on what’s mission-critical. It’s also a chance to uncover hidden dependencies, clarify edge cases, and determine the right level of test coverage for each path.

Prioritize What Matters Most
Once your team has identified the key user paths and test layers, the next step is prioritization. Here’s where many teams go wrong: they try to test every variation of a scenario “just in case.” But more tests ≠ better coverage.

Testing too many permutations leads to:

• Longer suite execution times

• Increased maintenance burden

• Flaky test noise that obscures real issues

Instead, focus on coverage that delivers maximum signal with minimum noise. Prioritize high-impact paths, common use cases, and areas most likely to change. Talk through what’s worth automating now versus what can wait or be monitored through other means (e.g., observability, manual exploratory testing).

After coverage is agreed:

• Make reviewing failing tests part of the daily standup.

• Share the load. Engineers should help investigate failures when their commits break the build.

• Keep iterating. Review coverage quarterly or when your product changes significantly.

Overcoming Common Pushbacks

Introducing this model isn’t always smooth. Here’s what you might hear — and how to respond:

“We don’t have time to discuss this in sprint.”
Solution: Break the conversation into 15-30 minute chunks during sprint planning or backlog grooming. Save time by prepping thoroughly.

“Isn’t this just the tester’s job?”
Solution: Remind them, this is test coverage strategy, not just implementation. Shared strategy = better outcomes.

“Our PM/PO doesn’t know automation.”
Solution: Perfect. They’re not here to code, they’re here to help prioritize what matters most to customers and the business.

Subscribe now

Automation is only as effective as the conversations that shape it. If your automation strategy is built in isolation, it will fall short, no matter how well-written the tests are. But when the entire team contributes to defining risk, coverage, and priorities, automation becomes a strategic asset rather than a side project. So the next time you're kicking off or revisiting your automation efforts, don’t go it alone.

🗣️ How does your team handle automation coverage? Are testers leading the strategy, or is it still siloed? Drop your thoughts in the comments — I’d love to hear how others are making this work in practice. 👇

Too often in software development, we treat the delivery date like the finish line. We rush to hit deadlines, celebrate shipping a new feature, and breathe a sigh of relief once it’s live. But here’s the truth: delivery is just the beginning.

The moment we ship something is the moment it enters the real world. And in the real world, everything is subject to decay.

Entropy: The Inevitable Decline into Disorder

There’s a principle in thermodynamics called entropy, the idea that all systems tend toward disorder over time. Coffee cools. Sandcastles crumble. Weeds overtake gardens. Our bodies are constantly declining unless we actively care for them.

It’s not the most uplifting message, I know. But here’s the hopeful twist: once we accept that entropy is inevitable, we can plan for it. We eat well, exercise, and go for check-ups, not to stop aging, but to manage it. The same mindset applies to software.

Software Is a Living, Decaying System

Software is not static. We increase complexity whenever we ship a new feature, fix a bug, or add a quick workaround. Bit by bit, entropy creeps in.

And the higher the degree of entropy a system has, the harder it becomes to manage. High-entropy systems are chaotic. They’re harder to debug, harder to change, and more expensive to maintain. That’s why it’s critical to build with maintenance in mind from day one.

Low-Entropy Systems Are Easier to Sustain

It’s far easier to keep a system clean and maintainable if you start early. Teams prioritizing sustainability during development make smarter trade-offs, detect issues faster, and reduce firefighting later on. Here’s how you can keep entropy in check:

Scaffolding for Long-Term Sustainability

Start by creating a culture that embraces maintainability as part of the definition of done. Here are concrete actions your team can take before going live:

• Define a maintenance owner. Make sure each new feature has a clear post-release owner or team responsible for upkeep.

• Create a plan for known issues. Document open bugs you’re shipping with and include them in upcoming sprint planning.

• Set up robust monitoring. Implement observability tools and ensure alerting is configured for the right people.

• Establish a post-release checklist. Include steps for validation, monitoring, communication, and follow-ups.

• Define incident response protocols. Make sure the team knows how to react if something goes wrong.

These actions shift the focus from shipping fast to shipping sustainably.

Shipping Shouldn't Mean Slipping Into Chaos

We all love the dopamine hit of shipping. But if we don’t pair that with intentionality about what comes after, our systems and teams pay the price.

Sustainable software practices are not about slowing down or adding red tape. They’re about shifting the mindset from “just ship it” to “what happens after we ship.” Delivery is an important milestone, but it’s not the finish line. It’s the point where real users start interacting with your product, where bugs emerge, feedback rolls in, and the cost of quick fixes starts to surface. Teams that embrace sustainability understand that the work doesn’t stop at release; it evolves. Building with maintenance, monitoring, and long-term health in mind ensures that you can move fast and keep moving, without burning out your team or breaking your system. And it takes less time than most think.

Let’s Redefine What “Done” Really Means

Done isn't just "it's live." Done means the team understands how to maintain what’s been built. It means monitoring is in place. It means there's a plan for bugs, tech debt, and user feedback.

Entropy is inevitable, but high-entropy is not.

🚨 Signs Your System Is Sliding Into High Entropy

Not sure if your team is dealing with a high-entropy system? Here are a few red flags to watch for:

• Onboarding takes forever. If new engineers need weeks just to get a local environment running or understand the codebase, that’s a sign the system is too complex or poorly documented.

• Fixing one thing breaks three others. Fragile systems lack clear boundaries and test coverage. When small changes cause widespread breakages, it’s entropy at work.

• Recurring bugs keep popping up. When the same issues resurface sprint after sprint, it usually means the root cause wasn’t addressed, or the system is so tangled it’s hard to fix.

• Deploys are scary. If releases feel risky or require “all hands on deck,” you’re likely dealing with high entropy. Healthy systems make deployment boring.

• Tech debt discussions go nowhere. When debt piles up and no one owns the cleanup, disorder becomes normalized, and entropy accelerates.

If more than one of these resonates, it’s time to take a step back and prioritize long-term maintainability. Start small: a retro discussion, a checklist addition, a post-release playbook. Every action that restores order slows the decay.

💬 What Do You Think?

How does your team handle post-release ownership? Do you plan for maintenance as part of development or treat it as an afterthought? I’d love to hear how you approach sustainability in your software systems.

👉 Share your thoughts in the comments or tag someone who needs to read this.

Another day, another round of hype about how AI will revolutionize software development. Tools promising faster code generation, shorter development cycles, and “one-click” features dominate the headlines.

But here’s the thing: shipping faster doesn’t mean shipping better.

Ask any seasoned engineer, and they’ll tell you success in software isn’t about pumping out more lines of code. It’s about creating systems that are maintainable, secure, observable, and built to last.

So why are we still pretending that speed is the only thing that matters?

The Real Tension: Speed vs. Quality

We've always lived in the tension between “get it done fast” and “do it right.” AI didn’t invent this challenge — it just turned up the volume.

Yes, AI can help us move faster. But faster is only good if you're headed in the right direction.

And right now, I see too many leaders optimizing for velocity without asking at what cost?

Fast Code is Like Fast Food

You can get a burger in 2 minutes at a drive-thru. It’ll be fast, cheap, and probably satisfying — for now.

But eat it every day, and you’re going to feel the consequences.

The same goes for software.

When we trade quality for speed, we create systems that are brittle, hard to test, impossible to scale, and frustrating to debug. They might ship fast, but they break faster. And no amount of AI is going to refactor your spaghetti architecture into a clean, scalable design later.

The Quiet Work of Long-Term Thinking

For engineering leaders who are focused on quality, the road ahead will be bumpy. You’ll be in meetings where others are promising “AI-built features in half the time.” You’ll be asked why you’re not using the latest tool that “writes all your tests for you.”

But we have to keep playing the long game.

Real software quality isn’t flashy. It looks like:

• Reviewing the edge cases that LLMs missed.

• Designing clean interfaces before writing code.

• Investing in observability and testing early.

• Saying “no” to shortcuts that save time now but cost you later.

AI Can Help — But It Can’t Save You

Let’s be clear: AI has a place. It’s useful. It can be a productivity amplifier. It can suggest code, automate tasks, and reduce toil.

But AI won’t save a codebase that was never built with quality in mind.

It won’t untangle an overengineered monolith. It won’t fix broken team processes. It won’t prevent the human mistakes that come from unrealistic deadlines and unclear requirements.

And it definitely won’t refactor your legacy UI into a sustainable architecture.

AI Can 10x Engineers — But Only If They Know What They’re Doing

There’s a common myth floating around: that AI will level the playing field for junior and senior engineers.

In practice? AI doesn’t replace expertise — it multiplies it.

For experienced engineers, AI can feel like having a sharp assistant. It speeds up boilerplate, catches small bugs, suggests patterns — and leaves you more time for deep work. But it only works because you already understand the architecture, the tradeoffs, the risks.

You still have to:

• Know how to read the code it generates

• Spot when something looks “off” — even if it compiles

• Understand the broader system so that AI suggestions actually integrate

Without that foundation, AI becomes noise.

For entry-level engineers, the picture is trickier. AI might help you move faster on the surface, but without understanding why something works, you’re building knowledge on shaky ground. Worse, when AI-generated code doesn’t integrate well or subtly breaks conventions, newer engineers won’t have the experience to debug it.

The result? More confusion, more brittle systems, and a false sense of progress.

What Does “Mastering Your Craft” Look Like Today?

In the AI era, engineers still need to invest in learning the fundamentals — arguably more than ever. That means:

• Reading code, not just generating it

• Understanding systems, not just syntax

• Practicing architectural thinking, testing discipline, and design patterns

• Debugging real issues instead of relying on AI to suggest fixes

Yes, AI is here to stay. But if you don’t know your craft, it won’t elevate you — it will expose you.

Build for the Long Game

As the noise gets louder and the promises get bolder, the temptation will be to go faster — to match the pace, to impress stakeholders, to ride the AI wave.

But if you’re a technical leader, your responsibility is bigger than that. You’re not just shipping code. You’re building systems, culture, and trust.

The best software teams in the AI era will be the ones who don’t lose sight of quality, who understand that long-term success is about thoughtful architecture, not just rapid iteration.

How is the “speed at all costs” mindset creeping into your org? How are you balancing AI adoption with long-term quality? Let me know in the comments and

share this with a fellow engineering leader who's navigating the same tension.

Testing Is Dead. Oh Wait, It’s Alive Again.

In 2016, Google’s GTAC conference1 closed with a theatrical statement—Alberto Savoia, dressed as the Grim Reaper, took the stage to declare the death of software testing. It marked the end of a decade-long run for one of the most respected conferences in the test automation space.

That same year, James Whittaker—who introduced Alberto Savoia at GTAC 2016—echoed the sentiment by formally pronouncing testing dead. The industry took note—and took action. Testing roles across Google, Microsoft, and other major tech companies were eliminated or folded into broader engineering functions. The message was clear: testing, as a distinct discipline, was no longer seen as essential.

And yet, testing never truly disappeared. Last year, Whittaker himself declared its resurrection2, recognizing that despite advances in automation, DevOps, and now AI, the need for thoughtful, context-aware testing had not gone away—it had only been misunderstood.

Today, as we see another wave of hype promising to replace testers with AI, it’s worth revisiting the real story: testing didn’t die. It evolved. And it's more relevant than ever.

Testing Never Died—It Evolved

The “testing is dead” narrative is not new. It flared up when Selenium went open source, flared up again when automation tools flooded the market, and is now back with AI.

But here’s the truth: testing didn’t die. It had to evolve—just like the rest of engineering did.

And yes, some folks are now proclaiming that engineering is dead too—thanks to AI and the rise of "vibe coding" culture. But most of us know better. We understand that engineering isn’t dead—it’s adapting. So is testing.

What Actually Died? Bad Testing.

Let’s be honest—some parts of software testing deserve to die. And in many organizations, they already have. I’m talking about the outdated practices that reduce testing to little more than requirement verification, test case checklists, and meaningless green bars on dashboards. These shallow, mechanical approaches give the illusion of quality without actually delivering it.

When testing becomes synonymous with “box checking,” it loses its value—and rightfully gets cut. Verifying known behaviors through scripted steps is something automation can (and should) handle. What should die is the kind of testing that adds no insight, no risk evaluation, and no exploration beyond what the product owner wrote in a user story.

This kind of “testing theater”—where success is measured by how many test cases pass, not whether we’ve uncovered meaningful problems—has long been a drag on engineering culture. It doesn’t scale, it doesn’t adapt, and it certainly doesn’t help us build better software.

Testing Is Not Box Checking

Automation is for checking the knowns—things we expect the system to do.

Real testing? That’s about the unknowns. It’s investigative. It’s creative. It’s risk analysis. It’s modeling user behavior. It’s edge cases and system thinking. No script or AI can fully replace that.

Misunderstood by Many—Including Testers

Why does the “testing is dead” idea keep coming back?

• Many testers don’t see it as a craft.

• Many companies confuse automation with testing.

• Some automation engineers are not inclined to learn to test—they wait for someone else to tell them what to automate.

• Some testers still only verify requirements, not value or risk.

This isn't just a leadership problem. It's an industry-wide problem, and yes—it includes us testers.

Testing Never Stopped—It Just Went Underground

Even when companies cut testing roles, testing still happened:

• Engineers continued unit testing (or at least, I hope they did).

• Customers unknowingly became the testers (often painfully).

• Teams tested without testers—often poorly, often late.

What those 2016 declarations really meant was that testing as a separate role was no longer needed. But even that was a short-sighted take.

The Real Future of Testing Is Craft + Context

Testing is not just about bugs. It’s not just about tools. It’s about:

• Understanding product risks

• Communicating uncertainty

• Modeling user behavior

• Finding what others missed

And to do that well, testers need to level up.

How to Stay Relevant in Testing

If you want to thrive—despite the AI hype—here’s how to do it:

🎯 Understand Stakeholder Priorities

Some stakeholders prioritize speed, others care more about stability. Your job is to understand what matters most in context—and tailor your testing approach to support it.

🗞️ Become a Risk Communicator

Report your findings like a journalist. Neutral tone, high clarity, relevant insights.

🧠 Study Testing as a Discipline

Learn heuristics. Practice modeling. Understand systems thinking. Dive into testing theory—not just tools.

🛠️ Embrace Tools—but Wisely

Use automation, AI, observability, and monitoring—but as helpers, not replacements for your brain.

🌱 Build a Learner’s Mindset

Stay curious. Stay connected. Join the actual testing community—not just flashy LinkedIn threads.

Subscribe now

Testing is alive—and thriving—in teams that understand its true value. It’s evolving fast, and if we want to stay in the game, we need to evolve too. Let’s stop waiting for validation from the same people who once called us obsolete. Let’s build a better testing future—together.

Drop a comment. Start the conversation. Let’s keep testing alive—by doing it better.

Related posts:

Why "Shift Test Left" Isn't as New as You Think

"Shift left testing" seems to be returning as a buzzword, creating an impression that it's a new concept. In reality, the idea isn't new at all. Its roots date back nearly as far as the agile movement itself. The earliest documented mention1 I've found is from November 2001, just a few months after the Agile Manifesto was published in February 2001. Despite this history, many teams still perceive "shifting left" as a novel innovation, missing the opportunity to fully embrace the benefits of integrating testing earlier into their processes.

Subscribe now

The Origins: Painful Lessons from the Waterfall Era

"Shift left" emerged in response to the severe limitations of the waterfall model. In those days, design, development, and testing were distinctly separate phases, creating frequent delays, bottlenecks, and frustration.

Testing was predominantly manual, automation tools were primitive, and Selenium—the cornerstone of modern automation—didn't even appear until 2004. Teams started realizing the inefficiency and high cost of delaying testing until the very end of development.

Beyond Early Testing: Shifting the Conversation

At its core, "shift left" emphasizes conducting testing earlier in the development lifecycle. Although unit and integration tests naturally took place earlier, shifting left pushed for broader and more systemic testing earlier in the development process in search of earlier feedback.

Today, even agile teams frequently fall into the trap of waiting until a full feature is complete before beginning testing, thus missing critical opportunities for early feedback.

Embedding Testing Conversations Early

Rather than focusing solely on performing tests earlier, the most impactful approach is shifting the testing conversation. Embed your quality professionals directly within your development squads, and equip and empower them to lead test and quality discussions from the outset of any project.

Short, focused sessions between developers and testers reviewing unit test coverage can significantly boost your team's software quality outcomes. These meetings should be quick—under 15 minutes per feature or ticket—and occur as soon as the developer considers the work ready for initial testing, which also means they would happen often during a sprint. These brief interactions foster essential dialogues:

• Prevent duplication of effort in integration and end-to-end testing by clearly identifying what's already covered at the unit level. This will avoid redundancy and save valuable testing resources at the end-to-end level, where maintenance costs are higher.

• Strengthen trust and teamwork between developers and testers by promoting regular communication, mutual understanding of each other's roles, and collective ownership of software quality.

• Allow testers to introduce, suggest, and guide the adoption of valuable testing strategies within the development process. Testers often bring distinct perspectives and knowledge, having insights into diverse testing techniques, good practices, and potential risks that developers might not initially consider. By involving testers early, the team can leverage their expertise to proactively increase unit test coverage and potentially uncover issues earlier.

Addressing Resistance: A Path to Successful Collaboration

When introducing these collaborative testing sessions, teams often encounter initial pushback. Developers might feel vulnerable to criticism or doubt the tester's ability to provide meaningful feedback at this stage. Some fear it will distract from their development tasks.

These reactions, while understandable, can be effectively addressed by:

• Clearly communicating the shared goals of early testing collaboration.

• Providing coaching that emphasizes joint responsibility for software quality.

• Persisting through initial discomfort to build new, productive habits.

Every team I've guided through this approach has initially experienced some resistance. However, each one has recognized significant benefits, including fewer issues reaching production, enhanced collaboration among team members, and a streamlined, more efficient automation strategy.

Have you faced resistance when trying to shift testing left in your team's development process? How did you overcome these hurdles?

Related Posts

Have you ever wondered why poor software practices tend to persist, even when everyone recognizes their detrimental effects? Gresham's law, an economic principle, provides insight into this phenomenon within software development.

What is Gresham's Law?

Gresham’s law states: "Bad money drives out good money." In simpler terms, when lower standards become acceptable, higher standards are gradually abandoned in favor of cheaper, quicker, or more convenient alternatives.

Subscribe now

A Psychological Explanation: The Cost of "Free"

Dan Ariely, in his book Predictably Irrational, offers a psychological perspective on this law through his experiment on how "free" affects human decisions:

• Scenario 1: Participants were offered Lindt chocolate for 15 cents or Hershey's chocolate for 1 cent. Most chose Lindt, clearly recognizing its superior value.

• Scenario 2: Lindt remained at 15 cents, but Hershey's became free. Despite Lindt still being clearly superior, most participants overwhelmingly chose Hershey's.

Ariely’s experiment highlights our irrational attraction to "free," often causing us to prefer lower-quality options simply because there's no immediate cost.

How Does This Relate to Software Quality?

Let's translate Gresham's law into scenarios familiar to software developers and engineering leaders:

1. Code Quality and Technical Debt

Quick fixes and shortcuts become appealing when teams are under pressure to meet tight deadlines. Initially viewed as temporary, these solutions often bypass important quality measures like thorough documentation, automated testing, and well-planned architecture. Over time, these rushed solutions become standard practice, displacing better, quality-driven methods. As shortcuts accumulate, the codebase becomes increasingly fragile and difficult to maintain, ultimately creating significant technical debt.

2. Agile Methodologies and Development Practices

When poor agile practices become acceptable—such as routinely skipping retrospectives, neglecting sprint planning, or tolerating chronic antipatterns—they inevitably replace disciplined Agile or Scrum methodologies. Over time, productivity suffers, morale declines, and overall quality diminishes.

3. Workplace Culture and Performance Incentives

If an organization fails to differentiate between high and low performers, rewarding them equally, motivation for excellence diminishes. High-quality standards gradually disappear as employees see less incentive to excel.

Breaking the Cycle: Prioritizing Quality

To counteract the negative effects of Gresham's law in software development, organizations must consciously promote and reward high-quality practices:

• Recognize and incentivize quality-driven developers and practices.

• Establish clear standards and consistently uphold them.

• Educate stakeholders about the hidden costs of shortcuts and poor-quality solutions.
  

Have you noticed Gresham’s law within your software teams or projects? How have you combated the race to the bottom in quality practices? Share your experiences and insights in the comments below. Let's learn from each other's challenges and successes.

Related Posts:

With all the talk about AI writing and testing software, very little is being discussed about what truly goes into delivering quality software to production. In my previous post, I explored what software quality is and how it differs from software testing. Now, I’ll expand on that by examining the key elements required to build and deliver high-quality software.

Subscribe now

The Four Pillars of Quality Software

Delivering quality software is about establishing a solid foundation across multiple dimensions. There are four critical pillars that support software quality, and weaknesses in any of these can lead to software that fails expectations, is difficult to maintain, or introduces unnecessary risks.

1. Tools: The Overrated but Necessary Pillar

The software industry is flooded with shiny new tools that promise better quality, smoother workflows, and improved developer experience. While tools are essential—IDEs, version control, CI/CD pipelines, testing frameworks—they alone do not create quality software.

A major anti-pattern is Shiny Tool Syndrome—the tendency to chase the latest tools, believing they will magically fix deeper issues, such as process or communication. Teams often fall into this trap, constantly adding new tools instead of addressing underlying inefficiencies. The result? Tool sprawl, increased complexity, and diminished effectiveness.

Instead of constantly switching tools, teams that focus on mastering the right set of tools—ensuring they are well-understood, effectively integrated, and truly add value—are the ones building a strong pillar of software quality.

2. Processes: The Underrated Backbone of Quality

Processes are often undervalued (or ignored because process change is hard), but are crucial to ensuring quality at scale. Agile, DevOps, and other methodologies can help, but many organizations implement them poorly, leading to dysfunction rather than efficiency. Strong processes ensure:

• Maintainability – Code and systems remain readable, extendable, and easy to modify.

• Scalability – The software can grow without major refactoring.

• Observability – Issues can be detected and diagnosed quickly through logging, monitoring, and alerting.

• Risk Management – Quality gates, peer reviews, and release strategies help mitigate failures before they impact users.

Good processes don’t slow teams down—they create predictability, reduce firefighting, and improve overall efficiency.

3. People: The Most Valuable Asset in Software Quality

Software quality is fundamentally about people—the engineers, testers, product managers, and leadership who build and shape it. A high-quality product emerges from a high-quality team environment, which includes:

• Continuous Learning – Investing in team training and skill development.

• Collaboration – Encouraging open communication between developers, testers, and business stakeholders.

• Psychological Safety – Ensuring team members feel comfortable discussing risks, challenges, and potential failures without fear of blame.

Supported, empowered, and aligned teams produce better software—plain and simple.

4. Culture: The Invisible Force That Shapes Quality

The company culture sets the tone for software quality. A culture that values quality will:

• Prioritize learning over blame—mistakes are opportunities to improve, not punishable offenses.

• Encourage knowledge sharing—teams don’t work in silos but collaborate effectively.

• Celebrate quality wins—not just fast releases but well-executed releases.

If leadership sees software quality as an expendable cost, it will be the first thing sacrificed under pressure. On the other hand, companies that integrate quality into their values and decision-making create better products without slowing down innovation.

The Pragmatic Equalizer: Finding the Right Balance

Software quality isn’t about achieving perfection—it’s about delivering the right level of quality based on business needs, risks, and constraints. "Good enough" quality is sometimes all a company needs to ship quickly and compete. The key is to make conscious trade-offs, ensuring that risks are understood, mitigated, and aligned with business goals.

Building quality software requires more than tools and tests—it demands a strong foundation of processes, people, and culture. Each pillar plays a vital role, and when balanced effectively, they enable teams to deliver high-quality software consistently and sustainably.

What do you think is the most overlooked factor in software quality? Let’s discuss in the comments! 🚀

Related Posts:

Delivering quality software—software that delights customers and meets stakeholders’ expectations—is a journey, not just a checkpoint. Too often, people conflate quality with testing. This may be because software testing has historically been referred to as Quality Assurance (QA), reinforcing the misconception that testing alone ensures quality.

Even within testing, the term is frequently misunderstood, reduced to merely finding bugs or breaking software rather than enabling the delivery of reliable, valuable, and user-centric solutions. In this piece, I want to break down the distinctions between software quality and software testing, why they matter, and how teams can move beyond these misconceptions to build truly high-quality software.

What Is Software Quality?

Quality is an intrinsic and relative value—what one person considers "high quality" may not meet another’s expectations. This is especially true in software development. When we talk about software quality, we need to consider who defines quality and how we assess and measure it.

Quality Is Defined by Stakeholders

Quality software is software that meets the expectations of those who matter—stakeholders, customers, users, and business owners. These are the people who use the software, invest in it, and ultimately define what "quality" means in their context. Engineering teams work for these stakeholders, and our ability to deliver quality software depends on understanding their definition of quality.

What Does It Take to Deliver Quality?

Ensuring quality software requires more than just testing. It involves a combination of:

• Communication: Do we truly understand what stakeholders and customers want? Are we going beyond verifying requirements and instead ensuring we're solving the right problems?

• Collaboration: Do teams work together effectively? Do they share a clear understanding of what "quality" means to stakeholders? Are they able to communicate and clarify uncertainties?

• Processes & Practices: Quality is built into software through disciplined coding practices, code reviews, software testing, automation, CI/CD pipelines, and feedback loops—all of which shape the end product.

What Is Software Testing?

Software testing is one piece of the quality software puzzle, but it is often misunderstood. Testing is frequently reduced to finding bugs or verifying that requirements were met, but in reality, testing is much broader and more strategic. Software testing is a critical investigative process that evaluates software behavior, identifies flaws, and highlights potential risks. It provides valuable insights that help teams assess software readiness and make informed decisions about its quality and reliability.

Testing Happens at Every Stage of Development

Testing should be embedded throughout the entire software lifecycle, before, during, and after coding:

• Before coding: Understanding risks, defining acceptance criteria, exploratory testing of prototypes.

• During coding: Unit testing, pair programming, static analysis, shift-left testing approaches.

• After coding: Automated regression testing, manual exploratory testing, performance and security testing.

• Before and after deployment: Canary releases, observability, production monitoring, feature flagging strategies.

This holistic approach to testing (inspired by Lisa Crispin & Janet Gregory's Holistic Testing principles) ensures that quality is continuously assessed and improved, rather than tested in at the last minute.

Why This Distinction Matters

Understanding the difference between software quality and software testing is crucial because achieving quality software requires many different strategies—of which testing is only one.

Over the past few years, the term Quality Engineering (QE) has gained traction, signaling an industry shift. Organizations are beginning to recognize that delivering quality software goes beyond tools and is about creating a culture of quality that permeates all engineering teams.

Ultimately, delivering high-quality software is about mindset, collaboration, and continuous improvement—and testing!

Subscribe now

How does your team approach quality? Have you seen the shift from "QA" to "Quality Engineering" in your organization? Drop a comment and share your thoughts!

Related content:

Here’s an unpopular opinion: not all engineering teams need testers. This is a polarizing statement because there are two distinct camps:

1. The testers—who strongly believe that every engineering team should have a dedicated tester.

2. The skeptics—engineers and leaders who argue that testers are unnecessary (some even claim testers hinder development).

As a consultant and startup advisor, I’ve had countless conversations on both sides of this debate. And the truth is both perspectives have valid points.

Before you assume I’m sitting on the fence, let me be clear: I am a tester at heart. I understand why testers advocate for their role on every engineering team. I believe most teams would benefit from an experienced tester who brings a mix of critical thinking and technical expertise.

But here’s where the argument for testers on every team breaks down.

Subscribe now

When a Tester Might Not Be Necessary

There are a few key scenarios where embedding a tester in an engineering team isn’t a must:

1. Not all testers bring the same value – A highly skilled, technical tester can be a game-changer. However, if a tester lacks technical depth or strong critical thinking, their contributions may not be enough to justify the role. This is one of the primary concerns raised by the “no testers needed” camp.

2. Small, scrappy startups operate differently – In the early days, everyone is responsible for testing. The priority isn’t catching every single bug—it’s shipping fast and iterating. In these early days, systems are usually simpler with fewer interfaces, making testing more manageable. Some don’t even have customers yet, or they’re in beta, where a higher tolerance for bugs is acceptable.

The Case for Dedicated Testers

On the other side of the debate, some engineers and leaders argue that having a dedicated testing function is not only unnecessary but counterproductive—suggesting that testers could make engineers complacent.

This perspective assumes that if testers exist, engineers will "slack off" and leave quality concerns to them. Some even point to Google and Facebook as examples of companies that operate without dedicated testers in some of their teams.

But this argument is flawed for a couple of reasons:

1 - Developers don’t “slack off” just because testers exist

Testers and engineers are partners in building quality software, not separate entities working in silos. When testers are embedded in teams, they don’t exist to catch developers' mistakes—they collaborate to prevent defects and enhance code quality together proactively.

Rather than viewing quality as something that can be “offloaded” to a single role, the most effective teams share responsibility by integrating testing practices early in development. For example:

• Pair programming and code reviews – Testers can collaborate with engineers to spot potential edge cases and improve testability before merging code.

• Shift-left testing strategies – Teams can implement unit tests, API contract tests, and static analysis as part of the CI/CD pipeline to catch issues sooner.

• Exploratory testing alongside developers – Testers and engineers work together to uncover usability and integration issues before they reach production.

• Monitoring and observability – By designing better logging, alerts, and user analytics, testers, and engineers can detect anomalies early and respond faster.

Bugs don’t happen because developers are careless—they occur because modern software systems are inherently complex. By fostering a culture of collaboration, shared ownership, and early defect detection, engineering teams can build more resilient, high-quality software together.

2- Companies like Google and Facebook are unique cases

While it’s true that some teams at these companies don’t have dedicated testers, it’s important to consider a few of the reasons why:

• Their software is free, and they can afford to rely on user feedback for bug discovery.

• They have millions of users, so they can roll out features to a fraction of their audience first, catching issues via monitoring before full deployment.

• Unlike banks, healthcare platforms, or financial services, their products don’t handle critical user data where failure has serious consequences.

For companies in regulated industries, where a bug could cost money, impact health, or damage reputation, testing cannot be an afterthought.

When You Might Need a Dedicated Tester

Here’s a simple way to think about it:

✅ You may not need a tester if:

• Your software is free, and minor bugs won’t impact credibility.

• You have strong monitoring and observability to detect issues in production.

• You’re in the early stages of development, and speed matters more than perfection.

🚨 You likely want to have a tester if:

• Bugs in production could impact customer trust, finances, or safety.

• Your software is used in high-stakes industries (e.g., healthcare, banking).

• You want to prevent costly failures rather than reactively fix them proactively.

Understanding this distinction is key to making informed decisions about testing roles in your engineering teams. The answer isn’t black and white—it’s all about context.

Now, I’d love to hear your thoughts! Do you think every engineering team should have a tester? Drop a comment, and let’s discuss.

Related posts:

I’ll admit that I’m getting a little tired of the endless posts and videos predicting AI’s domination. But one discussion I actually enjoyed was the NYT Opinion piece where Hank Azaria—famous for voicing characters on The Simpsons—tested an AI voice model trained to mimic him. The AI did well, but not well enough.

Why? Because it lacked the human characteristics that make voice acting compelling—character motivation, emotional depth, subtlety in physicality, and facial expressions. This is a perfect analogy for what’s happening in software engineering.

AI is Fast, But Is It Smart?

AI can generate code at lightning speed, but does that make it as effective as an experienced engineer or architect? Not quite.

Many people equate AI’s ability to process vast amounts of data with actual intelligence, but there’s an important distinction. AI doesn’t reason independently—it follows predefined objectives and optimizes for efficiency based on algorithms. It lacks the creative problem-solving, long-term thinking, and architectural foresight that make software engineering more than just code output.

Where AI Falls Short in Software Engineering

1. Lack of Context Awareness: AI tools like GitHub Copilot can generate functional code snippets, but they don’t understand the broader system architecture. They can’t weigh trade-offs like maintainability, scalability, or security in the way a seasoned engineer does.

2. No Deep Problem-Solving: Debugging is often about intuition and experience—patterns that engineers recognize after years of working with complex systems. AI might point out syntax errors, but can it predict a race condition caused by an unusual user interaction? Highly unlikely.

3. More Than Just Test Coverage: AI can churn out thousands of test cases for, but does more coverage equal better software quality? Not at all. Many of the most critical issues—usability flaws, accessibility problems, performance bottlenecks—require human judgment. AI can’t replicate the nuanced thinking needed to spot real-world user experience gaps.

AI: A Powerful Tool, Not a Replacement

If AI were an engineer, it would be a junior developer—fast, eager, and good at following patterns but lacking the strategic thinking required for genuinely innovative solutions.

This brings me to a simple analogy:

Artificial Intelligence is like artificial flavors—it can mimic the real thing, but only at a surface level.

It’s a tool to assist, not a substitute for human expertise. The best outcomes will come from AI augmenting human creativity and decision-making, not replacing it.

I’d love to hear your thoughts! Drop a comment below and let’s discuss. And if this post made you think, share it with a colleague or friend who has strong opinions on AI!

Software testers’ role is often misunderstood in agile teams. Unlike developers, product managers, or designers, whose responsibilities are widely recognized, testers frequently struggle with a lack of clarity and visibility in their contributions. This misunderstanding leads to the assumption that testing is merely a supporting function rather than a specialized discipline requiring expertise.

Because testing is often viewed as disposable—a task anyone can perform rather than a critical skill—many leaders fail to see its depth, treating it as an interchangeable commodity rather than a profession in its own right. This post focuses on one of the most damaging consequences of this misconception: the elimination of test leadership and the merging of testers into engineering teams. 

The Problems With Testers Reporting to Engineering Managers

This structure creates several challenges for both testers and the teams they support:

Stunted Career Growth for Testers

Engineering managers are typically not equipped to mentor testers or provide structured career growth in testing. A software engineer’s career path involves learning different coding languages, architecture, scalability, and DevOps principles—good skills for some testers, but none of which are directly related to the progression of a strong testing career. Testers need leadership that understands their discipline and can help them grow in exploratory testing, critical thinking, test design, risk analysis, and quality advocacy.

Testing Becomes an Individual Burden Instead of a Team Responsibility

When testers report to engineering managers, testing challenges such as tooling, environments, and process improvements often fall on individual testers to resolve alone. Unlike software engineers, who benefit from strong engineering leadership to advocate for their needs, testers end up with no structured leadership to push for systemic improvements. This results in:

• Poorly maintained or underfunded test environments

• Disjointed quality approach and automation strategies across squads

• Lack of investment in test tooling

• Testers fighting for quality improvements without leadership backing

Inconsistent Testing Practices Across Teams

Every squad in an agile team develops its own approach to testing, leading to fragmentation:

• Some teams heavily invest in automation, while others barely touch it.

• Some squads integrate testers early in the development cycle, while others treat them as afterthoughts.

• Without quality leadership overseeing the entire organization, there is no unified approach to testing, automation, and integration.

Lack of a Cross-Team Quality Strategy

Engineering teams require consistent leadership in test environments, tooling, and automation approaches. When each squad works independently, systemic testing issues—like unstable test environments or inconsistent release validation—go unaddressed. A dedicated quality leadership team ensures that:

• Cross-squad testing challenges are tackled at an organizational level.

• Test automation strategies remain scalable and sustainable.

• Test environments and CI/CD pipelines are managed holistically instead of per squad.

If You’re a Tester Reporting to an Engineering Manager, Here’s What You Can Do

While I strongly advocate for keeping testers within a dedicated quality leadership structure, I recognize that many testers already find themselves reporting to engineering managers. If that’s your reality, here are some tips on how you can make the most of the situation:

Use the Opportunity to Learn from Engineers

Even though engineering managers may not specialize in testing, there’s a lot to gain from being closely aligned with engineers. Learn about and try to influence:

• How your developers approach code quality

• The team's CI/CD pipeline and DevOps practices

• Automation frameworks that could enhance your testing strategy

Be Vocal About Your Needs

Engineering managers may not understand what testers require to be successful. Advocate for:

• Dedicated time for test automation and exploratory testing

• Resources for better tooling and test environments

• Inclusion in architectural discussions where testing strategies should be considered early

Find Allies in Your Squad

Seek out developers, product managers, or designers who care about quality. Build relationships with those who recognize that quality is a shared responsibility. These allies can help advocate for testing practices when leadership doesn't.

Create a Tester Guild or Working Group

If your company lacks a formal quality leadership structure, take the initiative to create one.

• Form a tester guild with peers across different squads.

• Meet regularly to discuss challenges, share strategies, and align testing practices.

• Use this platform to raise visibility on quality issues that affect the entire organization.

Find a Leadership Ally for Quality Initiatives

While your direct manager may not be a quality expert, look for leaders—another engineering manager, director of engineering, VP, or CTO—who value quality and can champion test-related initiatives.

Seek Mentorship Outside of Work

If your workplace doesn’t provide strong testing leadership, find mentorship externally. There are many experienced quality leaders (myself included!) who are happy to mentor testers looking to grow in their careers. Consider:

• Joining software testing communities

• Attending conferences or meetups on software quality

• Finding a mentor through LinkedIn or professional networks

Are you a tester reporting directly to an engineering manager? What have your experience been?

This post is part of a series aimed at engineering leaders. It focuses on elevating the role of testers and testing by understanding their true purpose. Testing isn’t just about finding bugs—it’s about providing critical insights that drive informed decisions.

As an engineering leader, you rely on data to assess risks, prioritize investments, and guide product direction. You wouldn’t navigate a complex project without a roadmap, just as you wouldn’t build a bridge without thoroughly testing its structural integrity. Yet, testing is often reduced to a gatekeeping function—a final checkpoint rather than an ongoing feedback mechanism.

If your team treats testing as an afterthought or a box to check, you’re missing a crucial opportunity. Testing, when done right, is a strategic enabler that helps improve decision-making, enhance software quality, and ensure engineering efforts align with business objectives.

Testing Is About Information, Not Just Defects

We can debate testing methodologies, the value of testers learning to code, what to automate, and how testing fits within Agile or DevOps. However, one thing we can’t debate is the core purpose of testing: providing information.

Testing exists to gather and share information—not just about defects but about system behavior, risks, usability, and performance. The way we test and report findings should help leaders make informed trade-offs: Is this release stable enough to ship? Do we need more time? Where are our biggest risks?

The format and depth of information may vary depending on the audience—detailed logs for engineers, risk summaries for executives—but the goal remains the same: testing is a continuous feedback mechanism, not just a final checkpoint.

Engineering Leaders Need Testers Who Can Tell the Right Story

Raw data without context is meaningless. As an engineering leader, you need more than test results—you need stories that inform decision-making. A good tester doesn’t just say, “There are five critical bugs.” They explain:

✅ Context: What were we testing, and why? And sometimes more importantly, what didn’t we test.
✅ Findings: What did we discover, and how does it impact the user experience?
✅ Risk Assessment: What happens if we proceed with these issues?
✅ Recommendations: What trade-offs should we consider? Note that testers can provide recommendations, but it is not their role to gatekeep the release. I wrote more about this in a previous post: Why Good Testers Ship Bad Software.

Think of testing like a business intelligence function—it’s not about drowning in metrics but about surfacing the right insights at the right time to guide product and engineering strategy.

The Risk of Assumptions in Testing and Leadership

One of the most dangerous phrases an engineer—or a leader—can say is: “I just assumed…” Assumptions are silent risk multipliers. They can lead to poor product decisions, hidden technical debt, and frustrated customers. The problem isn’t just that assumptions exist—it’s that they often go unnoticed until they cause real damage.

Consider these common (and costly) testing and leadership assumptions:

Assumptions About Test Coverage

Assumption: “Our automation test suite is robust enough to catch all critical issues.”
Reality: Automated test suites often prioritize what’s easy to test rather than what’s most critical to the business. If coverage isn't continuously assessed against evolving risks, gaps can emerge—leading to undetected regressions, security vulnerabilities, or performance bottlenecks.

✅ Solution: Define test coverage based on business impact, not just code coverage percentages. Engage product teams, developers, and testers in risk analysis exercises to ensure critical scenarios are covered.

Assumptions About User Behavior

Assumption: “Users will interact with our product exactly as we designed it.”
Reality: Real users take unpredictable paths, misuse features, and rely on workarounds in ways teams never expected. A feature that works perfectly under controlled testing may fail in real-world usage.

✅ Solution: Use real user data, analytics, and skilled exploratory testing to validate assumptions about workflows. Test under real-world conditions, including accessibility challenges, slow networks, and different device types.

How Leaders Can Shift from Assumptions to Evidence-Based Decision-Making

Great engineering leaders foster a culture of clarity, validation, and continuous learning by encouraging teams to:

🔹 State and document assumptions before making decisions—whether about testing, architecture, or user behavior.
🔹 Challenge assumptions through data, experiments, and diverse perspectives rather than relying on gut feelings or past experiences.
🔹 Align test coverage and engineering priorities with actual business risks, ensuring that testing efforts focus on what matters most.
🔹 Invest in observability and monitoring, enabling real-time insights that validate system behavior in production.

By shifting the focus from assumptions to evidence, you empower your teams to build more reliable, scalable, and user-centric software—and ultimately, to make better engineering decisions that drive business success.

The best engineering teams treat testing as an integrated feedback loop, helping drive product direction and business success—not just catching bugs.

As a leader, how do you ensure that testing provides real value to your organization? Do your teams see testing as a core function of engineering or as an isolated step in the pipeline? What changes have you made to improve the way your organization gathers and shares quality insights?

Other posts in this series:

• Why Good Testers Ship Bad Software

• Why Engineering Leaders Must Rethink Testing to Build Reliable Software

• Same Tools, Different Uses: Adapting Leadership to New Contexts

Engineering leaders (not just managers) hold immense power to shape how software is built, tested, and delivered. Some of the most impactful conversations I’ve had with engineering leaders have revolved around shifting the narrative on testing and software quality. These discussions often reveal surprising misconceptions and expose gaps in understanding that can make or break a team’s ability to deliver reliable software.

Below, I share some of the most common conversations I have with other engineering leaders, from CTOs to ICs, that tackle important truths about testing and software quality—truths that can help your organization move in the right direction, one step at a time.

The Myths Holding Testing Back

One of the most harmful misconceptions in software engineering is the division of testing into “manual” and “automated,” as if they are in opposition. Testing isn’t about choosing one over the other—it’s about using the right tools for the right job. Think of it this way: A chef isn’t called an “automated chef” because they use a food processor; they’re just a chef leveraging the right tools to get the job done. Similarly, testers use automation as a tool—it doesn’t replace their critical thinking, creativity, or investigative skills.

Why Automation Isn’t the Silver Bullet

The obsession with automating everything has led to an industry-wide anti-pattern: teams with extensive test suites but declining software quality. While automation is excellent for repetitive tasks, not all tests should be automated. Over-automating creates hidden costs, from the time it takes to run large test suites to the effort needed for maintenance. Automation is valuable, but it must be balanced with pragmatic decision-making. Just as no chef cooks every dish with an Instant Pot, no team should automate every test case.

Metrics That Matter (And Those That Don’t)

Misused metrics are another common pitfall in testing. Metrics like code coverage or the number of automated tests often lead teams astray, focusing on quantity over quality. For instance, 100% code coverage doesn’t mean your software is robust or bug-free. Instead, leaders should focus on metrics that truly reflect quality and productivity. Those are hard to find but are worth looking for. I like using DORA’s Change Failure Rate and Bugs Found in Production as tools to guide decisions, not absolute quality indicators. Ultimately, only your customers can define whether your software is of high quality.

Testers as Innovators: Advocating for Users and Preventing Bugs

Testers and testing should not be afterthoughts in the development process. Testers are investigators, experimenters, and user advocates. Their work goes far beyond running test cases—it’s about uncovering risks, improving usability, and ensuring the software delivers value. To help testers succeed, leaders must:

• Provide robust tools for testing (for all testing, not just automation).

• Encourage a culture of respect for their expertise.

• Involve them early in the development process to prevent bugs, not just find them.

Quality Starts with Leadership and Culture

Here’s a hard truth: despite what some may think, testing doesn’t create quality—it identifies where quality might be lacking. Quality is everyone’s responsibility, and it starts with leadership. Leaders must actively foster a culture where quality is prioritized at every stage, from requirements to production. How do you create this culture? By aligning teams around a quality-first mindset:

• Ensure all roles—developers, testers, product managers—share ownership of quality.

• Make quality a central theme in sprint planning, retrospectives, and team discussions.

• Celebrate successes like preventing bugs, not just fixing them.

Now it’s your turn: What strategies have worked for you to foster a quality-first culture? Have you struggled with testing myths or misconceptions in your organization? I’d love to hear your thoughts.

For years, Selenium has been the go-to tool for automated browser testing, and for good reasons: it’s open source and free, has a large and active community, supports multiple browsers, platforms, and programming languages, and—perhaps most importantly—it’s familiar.

However, Selenium is not without its drawbacks. It tends to have slower execution compared to headless browser automation tools, lacks built-in reporting and test management features, and comes with a steep learning curve—especially for team members outside of the QA team, like engineers. And this last point matters—a lot. Here’s why.

Beyond the Testing Team: Cypress and Playwright in Modern Workflows

I had an interesting discussion at work today about The State of Front End Development, a report by The House of Software. We talked about automation tools—Cypress, Playwright, and Selenium—and their roles in modern testing workflows.

When a colleague mentioned Cypress ranked second and Playwright fifth in the report, I was intrigued. Selenium? Nowhere in the top 10.

Initially, I was surprised these tools ranked so highly. Despite competition, Selenium is still widely used in testing. But after examining the data, it made sense. The survey, which included 6,000 developers—not testers—focused on tools used by front-end developers for testing tasks like unit and integration testing. Jest, a JavaScript and TypeScript framework, unsurprisingly topped the list.

Cypress and Playwright’s prominence was even more intriguing under the context of the report, as I’d always viewed them as tools primarily aimed at testers and QA professionals – not engineers. However, their high rankings also confirmed what I’ve observed firsthand: their developer-friendly design makes them better suited to modern teams and workflows than traditional tools like Selenium.

Why Engineers Prefer Working with Cypress and Playwright¹

Testing can feel like an uphill battle for developers, especially with tools that require steep learning curves or outdated workflows. Here’s why Cypress and Playwright are changing the game:

• Developer-Friendly Design: Streamlined setup and configuration minimize adoption hurdles, making these tools far more accessible than Selenium.

• Seamless Integration: Built to integrate effortlessly with CI/CD pipelines, ensuring testing aligns smoothly with modern delivery workflows.

• Intuitive and Approachable: Clearer documentation simplify the learning curve, enabling quicker adoption and effective use.

A Real-World Case Study: Testing as a Team Sport

In past roles, I’ve seen firsthand how tools like Playwright can transform team dynamics. For example, during one project, we faced a classic challenge: too many engineers, not enough testers. To address this, we shifted test maintenance to the entire team. Another step towards making quality everyone’s responsibility.

Here’s what worked:

• Empowering Engineers: When an E2E test failed after a merge, engineers took the lead in investigating the issue. Was it a genuine bug or just a test update requirement? They analysed and resolved it, with testers providing support as needed rather than immediately stepping in to fix it. Testers focused on creating new tests during sprints, but test maintenance became a shared responsibility across the team.

• Lowering the Learning Curve: Playwright simplified onboarding for engineers by reducing friction. Its seamless integration with modern CI/CD pipelines and built-in features—such as tracing, screenshots, and debugging tools—eliminated the need for external libraries or frameworks like TestNG or Allure. This reduced complexity ensured engineers could get started quickly without feeling overwhelmed.

• Collaborative Test Maintenance: While testers handled test creation during the sprint, maintaining those tests became a team-wide effort, fostering a culture of shared responsibility and collaboration.

Would we have had the same success with Selenium? Possibly—if it could have been implemented the same way. I’ve attempted to approach testing this way with teams using Selenium before, and it hasn’t been successful, even once. The steep learning curve alone often created resistance, undermining efforts to distribute responsibility across the team. This challenge has largely relegated Selenium to being a tool used primarily by testers.

In contrast, tools like Playwright have enabled collaboration and made it feasible to sustain a team-wide approach to testing. Their simplicity and developer-friendly design have bridged the gap, helping make testing a shared responsibility rather than a siloed activity.

Sometimes, it’s not about choosing the “best” tool—it’s about choosing the tool your team will actually use to get the job done effectively.

Testing tools spark passionate debates—what’s your perspective? Comment below to share your experiences with Selenium, Cypress, or Playwright and how they’ve impacted your team’s testing efforts.

1. Note: This post is not intended to be a comprehensive guide or a detailed comparison of Selenium, Playwright, and Cypress, nor does it delve into their respective pros and cons. Instead, my goal is to highlight why Playwright and Cypress are gaining momentum in adoption. Based on my experience, these tools resonate more with teams aiming to bring engineers deeper into the testing sphere, fostering greater collaboration and shared ownership of quality.

   ︎

As leaders, our toolkits are packed with experiences, strategies, and practices that have worked wonders in the past. But when we step into new environments, those familiar tools often require a different approach to stay effective. Leadership, much like software engineering, thrives on adaptability.

One of the Hardest Leadership Lessons I’ve Learned

Two months into a new job, I found myself navigating an unexpected leadership shake-up. The manager who hired me—and had been one of the reasons I joined—left abruptly. Within weeks, I was reporting to a new manager. On paper, his credentials were impressive: seasoned engineering leader, top-tier companies, an enviable LinkedIn profile. Reality? Not so good.

Despite his experience, he struggled to adapt to the organization’s culture and the needs of the teams he managed. He wielded his previous company’s playbook like a hammer, viewing every challenge as a nail. His failure to adjust not only alienated the team but also stalled progress. After six months of chaos, he was let go. For me, as a middle manager at the time, it was one of the most challenging periods in my career—juggling a rigid leader’s fallout, guiding my team through turbulence, and ensuring quality software delivery.

This experience taught me that leadership isn’t just about the tools we carry—it’s about knowing when and how to use them, and when to set them aside altogether.

4 Strategies for Leadership Adaptability

We have been navigating challenging times with layoffs, restructures, and shifting priorities, meaning that as leaders, we must regularly recalibrate. While our skills and experience are invaluable, they must be wielded with an understanding of the new context we find ourselves in.

When I step into a new team, these strategies help me adapt and apply my leadership toolkit effectively (trying not to be ‘that’ rigid manager I had to deal with):

1. Resist Action Bias

The urge to prove your worth as a new leader is strong, but resist diving into delivering change too quickly. Take time to observe and absorb the business ecosystem—its culture, processes, and systems. Accept that you are a beginner in this environment, even if you’re the leader. Attend meetings with a learner’s mindset, not just a decision-maker’s.

2. Build Trust Through Small Wins

Establishing credibility within the team takes time. Identify low-hanging fruit—small but meaningful improvements that demonstrate your value. Early wins help build trust and pave the way for bigger changes.

3. Cultivate a Network of Collaborators

Leadership isn’t a solo endeavor. Forge connections across teams and departments. Collaborators amplify your influence and help you navigate organizational complexities.

4. Spot the Key Players

Every organization has unofficial influencers and “organizational translators”—people who understand the culture and can bridge gaps. Identify and work with them to understand unspoken dynamics and gain deeper insights into the team.

Context Is Key

The tools and strategies that once made you successful are still valuable—but they aren’t universally applicable. Leadership requires context-aware adaptation. By listening, learning, and tailoring our approach, we set ourselves—and our teams—up for success. We can do more than just manage change. We can model how to thrive in it.

Testing isn’t just about finding bugs.
Testing isn’t just about verifying requirements.

It’s about revealing the truth—the good, the bad, and the ugly.

The role of a great tester is to uncover and share information with decision-makers so they can make informed decisions. Sometimes, that means releasing software that’s not 100% polished.

Yes, you read that right:

• Good testers release software with known bugs.

• Good testers ship imperfect products.

Sound counterintuitive? Here’s why: quality isn’t the only priority. When a business makes decisions, it weighs factors like:

• Speed to market: Being first often trumps being perfect.

• Customer needs: Sometimes, “good enough” delivers value faster.

• Seasonality: Some deadlines don’t wait for flawless code.

This doesn’t mean testers or testing failed. It means testers empowered the business with the right information to choose its trade-offs.

It’s not about “perfect” software.
It’s about the right software, delivered at the right time, with the right trade-offs.

So the next time you see a bug in production, remember:
It might not be a failure of testing.
It might be a deliberate decision for the business.

Being a good tester isn’t about chasing perfection.
It’s about delivering clarity, even when the answers are messy.

To my software engineering and testing community: I’d love to know what’s the hardest trade-off you’ve had to make when balancing quality with business goals?

I took some time this week to dive into the 2024 DORA Report, and one statement really jumped out at me:

“Software doesn’t build itself. Even when assisted by AI, people build software, and their experiences at work are a foundational component of successful organizations.”

This holds true in software testing as well: software does NOT test itself. People test software.

Yes, people build tools for automated regression checking. Yes, AI can assist in investigations, code reviews, and research. But here’s the truth:

AI cannot replace human experience or the core function of testing: human-driven insight.

AI assists, but it doesn’t innovate. It doesn’t connect the dots the way a skilled tester can when troubleshooting complex issues. It can’t anticipate edge cases, empathize with user behavior, or apply critical thinking. Even with sophisticated AI testing tools on the market, they still require human expertise for effective configuration, interpretation, and escalation. Just like AI won’t build software on its own, it won’t test it either.

AI is a partner, not a replacement.

In testing.
In software development.
In innovation.

And the organizations and teams that thrive will be the ones that recognize the irreplaceable value of human insight, supported (not overshadowed) by the power of AI.