DEV Community: Vlad Z

The quadrant that swallows engineering teams whole

Vlad Z — Sat, 26 Sep 2026 17:20:07 +0000

Hard low-impact work is the most dangerous quadrant on the list

Not because the work is harmful. Because it feels like real progress while delivering almost none

I know this one personally

Early in my career I spent two weeks building a custom Lambda-based system to automatically rightsize instances based on utilization metrics. It was genuinely interesting work. The code was clean. The logic was solid. The system worked

It saved $180 a month

Two weeks of engineering time. $180 a month. The payback period was longer than most startups' runways

The reason it happens is that hard technical work is satisfying in a way that easy cleanup work isn't. Deleting old snapshots feels like housekeeping. Building an automated optimization system feels like engineering. Same outcome on the bill. Very different experience of doing the work

The other way teams end up here is through scope creep during legitimate optimization projects

They start with a real high-impact initiative. Somewhere in the middle, the scope expands. A feature gets added because it would be nice to have. An edge case gets handled that accounts for 0.3 percent of the workload. The timeline doubles. The incremental savings from the expanded scope are minimal

How to avoid it

Before starting any hard optimization work, ask one question

If this takes twice as long as planned, is the saving still worth it?

If the answer is no, it belongs in a different category

And if you're already in the middle of hard low-impact work

Finish what's near completion. Cut what isn't. Don't let sunk cost keep you in the wrong quadrant

The goal is a smaller bill, not a more elegant optimization system

Sometimes those are the same thing

Often they aren't

Small and easy fixes are worth more than they look

Vlad Z — Sat, 26 Sep 2026 17:11:30 +0000

Easy low-impact changes get dismissed too quickly

They're not going to move your bill significantly on their own. Any one of them is maybe $20, $50, $100 a month. Not worth a meeting. Not worth a sprint. Not worth the conversation

But here's what happens when you ignore them indefinitely

They accumulate

Unused Elastic IPs at $4 a month each. Idle NAT gateways. Old AMIs nobody will ever launch again but are stored in every region you ever tested in. Forgotten CloudWatch dashboards with expensive metric queries running on a schedule. Tiny Lambda functions that run constantly for a use case that no longer exists

Each one is nothing. Together they're $400, $600, $800 a month of pure noise with zero value delivered

And there's a second reason not to ignore them

The habit

Teams that regularly clean up small inefficiencies develop an instinct for it. They notice when something is running that shouldn't be. They ask the question before the next thing gets added. They treat the account like a space that needs to stay organized, not a place where things accumulate until someone complains about the bill

Teams that never do small cleanup work tend to have accounts that gradually fill with cruft. Not because anyone made bad decisions. Because nobody made any decisions. Things got created, served their purpose, and never got removed

The easy low-impact quadrant is worth doing

Not as a priority. Not before the more important work

But as maintenance. As hygiene. As the habit that prevents the account from becoming the maze that took me 15 minutes to untangle every time I opened a new console

Set aside a few hours every quarter

Go through the account

Ask the simple question for everything you find: is this still needed?

The answer will surprise you more often than you expect

What a hard, high-impact cloud change looks like from the inside

Vlad Z — Sat, 26 Sep 2026 17:09:11 +0000

Let me show you what a hard high-impact change actually looks like in practice

A team I worked with had a microservices architecture. Seven services. All of them deployed in one region. All of them talking to each other

The data transfer bill was $3,200 a month

At first glance that number didn't make sense for their traffic volume. The services weren't moving that much data. But the bill said otherwise

We traced it

Turns out three of the services were deployed in different availability zones. Not different regions - different AZs within the same region. AWS charges for data crossing AZ boundaries. Every API call between those services crossed that boundary. Multiple times per request. At scale that adds up fast

The fix was architectural. Move the services into the same AZ, or introduce a service mesh that routes intra-service traffic locally. Neither option was trivial. Both required changes across three teams, testing across multiple environments, and a careful cutover with monitoring

It took six weeks

The data transfer bill dropped from $3,200 to $400 a month

$2,800 saved every single month from that point forward. Compounding as traffic grows

That's $33,600 in the first year

The hard part wasn't the technical work. The technical work was straightforward once we understood the problem. The hard part was coordinating three teams who all had other priorities, explaining the problem in a way that made the investment of time make sense, and holding the effort together for six weeks when there were always more urgent things demanding attention

This is what hard high-impact looks like in practice

Not impossible. Not glamorous. Just sustained, coordinated, well-scoped work that most teams don't finish

The ones that do finish it are the ones that treated it like a real project from the beginning

The changes that save the most are the ones nobody finishes

Vlad Z — Sat, 26 Sep 2026 17:05:16 +0000

The hard high-impact changes are the ones most teams talk about and few actually finish

Not because they're impossible. Because they require something the easy wins don't: sustained attention over time

Easy wins are a sprint. Hard wins are a marathon. And most optimization efforts lose steam before they get there

Here's what makes something hard in this context

It's not always technically complex. Sometimes it's organizationally complex. Changing how services communicate affects multiple teams. Rightsizing a production database requires coordination with the application team, a maintenance window, careful monitoring afterward. Restructuring data transfer patterns means changing code that touches multiple services and has unclear downstream effects

Hard means: you can't do this alone in an afternoon

And that friction is where most efforts stop

The ones that don't stop share a pattern

They treat hard changes like engineering projects, not optimization tasks. They have a named owner. A timeline with a defined end date. A rollback plan documented before the change starts. A success metric agreed on in advance so everyone knows what done looks like

They also separate the change from the reason

A developer asked to rightsize a database for cost reasons will have a hundred objections. A developer asked to rightsize a database because the team's goal is to reduce infrastructure spend 30 percent by Q3, and this database is a key part of reaching that goal, has fewer objections. The work is identical. The context changes the conversation

The savings from hard high-impact changes compound differently than easy wins

Easy wins happen once and hold. Hard changes often improve every month as the infrastructure scales. A better data transfer architecture that saves $2,000 a month now saves $4,000 a month when traffic doubles

The effort is a one-time investment

The return keeps coming

That's why they're worth the friction

The easy wins are already sitting in your cloud account

Vlad Z — Sat, 26 Sep 2026 17:01:09 +0000

The easy big wins are hiding in plain sight in almost every cloud account

They don't require architectural decisions. They don't require weeks of planning. They don't require sign-off from three teams. They're just sitting there, costing money, waiting for someone to look

Here's what they usually are

Idle and forgotten resources

Compute instances running at 5 percent CPU. Load balancers forwarding zero requests. NAT gateways attached to subnets nothing uses anymore. These are resources that were useful once and stopped being useful and nobody removed them because removing things feels risky and leaving them feels safe

They're not safe. They're expensive

Old snapshots and unused storage

Snapshots taken months ago for a migration that finished. Database backups retained far longer than any recovery scenario would require. EBS volumes orphaned when the instances they were attached to were terminated. Buckets full of logs that rolled off any compliance requirement twelve months ago

Nobody deleted them because nobody thought about them

Dev and staging environments running 24/7

This one gets me every time. A full production-mirror staging environment running continuously when the engineering team works business hours in one time zone. Nights and weekends: fully provisioned, fully billed, zero usage

A scheduler that turns them off outside working hours costs almost nothing to set up and saves real money every month

Oversized database instances

Provisioned for a load that never came, or for a load that came and went and was never right-sized afterward. Running at 10 percent capacity. Billed for 100 percent

The pattern across all of these is the same

Someone made a decision, it made sense at the time, circumstances changed, and nobody came back to revisit it

The fix in every case is also the same

Look. Actually look. Go through the account with the specific question: is this still earning its cost?

Most of it is. Some of it isn't

The part that isn't is your fastest path to a smaller bill

Every optimization list is infinite. One question sorts it

Vlad Z — Sat, 26 Sep 2026 16:58:03 +0000

Every optimization problem has the same question underneath it
Is this worth doing now?

Not eventually. Not someday. Now. With the time and people you actually have

Because the list of things you could optimize is always infinite. There is no cloud account anywhere that has nothing left to improve. The question is never whether there's more to do. The question is whether the next thing is worth doing before everything else

Two variables decide that

How much does it save? And how hard is it to fix?

That's it. Everything else is a distraction

High savings, low effort: this is where you start. Every single time. These are the changes that justify the entire effort. They're fast to ship, meaningful in impact, and low in risk. They create momentum and they generate the credibility that funds the harder work coming later

High savings, high effort: this is where the serious wins live. Architectural changes. Rebuilding how services communicate. Replacing legacy implementations that were never the right solution. These take real time. They need proper planning and testing. But the savings compound for years. Worth doing after the easy wins are cleared

Low savings, low effort: the cleanup work. Good habits. Worth doing when you have breathing room. Never worth prioritizing over the quadrant above it

Low savings, high effort: this is the trap that swallows teams whole. Technically interesting. Architecturally elegant. Practically not worth it. I've watched engineers spend three weeks on an optimization that saves $200 a month. The work was excellent.
The prioritization was not

The framework doesn't require a spreadsheet or a sophisticated model

For every item on your list, ask two questions

How much does this save and how hard is it to fix

Put the easy big-savers first

Everything else falls into place from there