4 ways to ship smarter, not just faster

Estimated reading time: 6 minutes

How a QA-turned-engineering manager has embedded quality and security into the CI/CD.

Software delivery often feels like walking a tightrope. On one side, there’s pressure from the business to move faster. Faster than competitors, faster than last quarter, faster than the team probably feels comfortable with. 

On the other side, there’s engineering, raising caution flags about long-term stability, user experience, and the very real cost of tech debt. It’s a familiar tension. And if you’ve worked in software long enough, you’ve probably felt it, too. 

I’ve lived this from both sides. I began my career as a quality assurance (QA) engineer, focusing on identifying bugs, ensuring test coverage, enhancing user experience, and maintaining system stability. Today, I lead an engineering team where speed is a constant topic of conversation. And if there‘s one thing I’ve learned, it’s this: speed and quality don’t have to be trade-offs. When teams stop seeing them as opposing forces and start thinking in terms of balance and risk, they can deliver faster without cutting corners.

The common struggle

Let’s be real: shipping quickly feels great. Teams are energized, stakeholders are happy, and customers see progress. But that high can fade fast if quality is overlooked.

Skip critical validation steps, and the cost shows up later: bugs piling up, regressions slipping through, and users losing trust. On the flip side, if perfectionism is the key, you slow down unnecessarily, missing opportunities and frustrating stakeholders. 

This isn’t a simple “fast vs. safe” binary. It’s a constant decision-making game, where teams build systems and habits that enable them to make intelligent, intentional trade-offs.

The real challenge is aligning your team around shared goals, expectations, and risk tolerance.

So, how do we do it? Let’s walk through four practical approaches.

1. Critical vs. non-critical

Not all features or bugs carry the same level of importance. Some changes could take down your entire system, while others might nudge a pixel out of place. That’s why one of the most powerful things a team can do is assess the risk early and often. 

Start by identifying what’s critical during refinement sessions. Think about infrastructure changes, anything touching security or user data, payment flows, or foundational APIs. These areas need deeper validation, more thorough code coverage, automated regression suites, and sometimes slower rollout.

But that same level of scrutiny doesn’t need to apply everywhere. For minor user interface (UI) tweaks or internal reporting tools, the risk is lower. These can move faster, with lighter testing and faster feedback loops.

My team uses a checklist during the refinement sessions, where they consider several aspects (e.g., risks and unknowns, technical considerations, deployment, and release). All in all, it gives us a clearer view of how serious the issue is. 

This kind of risk-based thinking helps teams prioritize their efforts, reduce over-engineering, and focus on what truly matters. Engineers know where to focus their energy, QAs can prioritize deeper testing for the riskiest paths, and stakeholders get early signals on timelines grounded in risk, not guesswork. In the end, it also builds trust, because everyone knows the speed isn’t reckless, it’s thoughtful.

2. Lightweight quality gates

Before we dive into specific strategies, it’s worth defining what we mean by quality gates. These are the checks that a piece of work must pass before it’s allowed to move forward. They can be there when merging a pull request, deploying to staging, or releasing to customers.

Quality gates don’t need to be blockers. Some of the best gates are barely noticeable because they’re built into the process.

Here are a few lightweight approaches that I’ve seen my teams adopting that keep velocity high and reduce risk:

• Small, fast-running tests in CI/CD that catch the most common regressions, such as API contract mismatches, navigation failures, or authentication problems. Instead of waiting for a full suite of integration tests, add key smoke tests or linters that run on every commit.
• Feature flags to isolate unfinished work or allow well-handled rollouts. This gives teams control over risk exposure.
• Progressive delivery or canary releases to validate real-world impact in a safe, limited way. This allows for validation in production with a small user group.
• Monitoring and alerts that catch issues early without requiring exhaustive manual testing upfront. Fast recovery is just as important as prevention. If something slips through, observability can serve as a safety net.

These tools don’t slow you down. They enable the delivery. Automation and processes give you the confidence to move faster, knowing you’ve got safety nets in place.

3. Define “good enough”

Perfectionism is a velocity killer and one of the most challenging habits for engineering teams to overcome. Flawless code is an admirable goal post, but chasing perfection can be paralyzing.

The issue here often stems from the fact that engineers are working toward an undefined version of “done.” Instead, the team should come up with a definition of what “good enough” looks like to them and move toward that. It will allow for alignment across engineering, product, and QA. It also helps you decide where to invest time and energy, based on how risky or impactful the change is.

This isn’t about lowering your standards or being sloppy. It means aligning on acceptable risk. It’s important to ask: “What’s the impact if something goes wrong? Can we fix it quickly? Is this level of polish worth the delay? Is this a must-have or a nice-to-have?”

By making “good enough” a shared decision (not an implicit guess), you avoid over-engineering. However, this shouldn’t be a “one-size-fits-all” approach. You need to evaluate it on a case-by-case basis, during refinement sessions or the development process itself, to ensure you are delivering the right level of quality for the situation. And when you get that right, teams gain speed without sacrificing trust.

4. Create a culture of quality – it matters (a lot)

Processes and tools are essential. But culture is what makes them stick.

When developers see QAs as the final defense, they treat testing like someone else’s problem. When QAs are looped in too late, they scramble to catch what should have been prevented earlier. And when leaders only reward speed, quality becomes optional.

One of the most significant shifts I’ve seen in high-performing teams is the mindset that quality is everyone’s responsibility. QA isn’t the safety net; it’s a partner. Developers aren’t just writing code; they are thinking about how it behaves, how it breaks, and how users experience it.

Here are a few ways to nurture that culture:

• Encourage developers and QAs to collaborate before implementation begins. Reviewing test scenarios together often catches gaps that would surface much later.
• Integrate validation into the design and coding phases while fostering psychological safety. Teams should feel free to ask “What could go wrong?” without fear. The key is to treat questions as opportunities for exploration and curiosity, rather than blame or criticism.
• When someone ships a quick fix behind a feature flag and monitors it closely, recognize that in a team meeting, 1:1, or in a public messaging channel. Highlight not just the speed but the intentional approach behind it.
• Bugs will happen. What matters is how teams learn from them. Post-incident reviews should focus on process improvements, not finger-pointing.

When teams collaborate on quality from the start and leadership trusts and supports this, risk becomes something you manage, not fear. 

Final thoughts 

In my early QA days, I thought the best way to protect users was to catch everything before release. However, as I evolved in this role and watched my team grow, I realized that this mindset doesn’t scale. It created bottlenecks (every release was dependent on me), limited learning (the team was dependent on my knowledge), and, consequently, slowed everyone down. 

Once I became a champion of making quality everyone’s responsibility and transitioned into engineering leadership, I realized that quality isn’t a gate; it’s a path we walk together. It’s something that should be adjusted depending on the stakes and risks. We just need to build systems and processes (both technical and cultural) that help the teams make those calls with clarity.