I Stopped Writing Code and Started Making Decisions—Here's What Changed

Two years into my first job, I could ship features in my sleep. A Jira ticket would land in my lap with a wireframe attached, acceptance criteria spelled out in bullet points, and I'd have it merged by EOD. Add a filter here, fix a query there, bump a version number. It felt productive. It felt like I was crushing it.

Then one day, my tech lead pulled me into a meeting about our search performance. Our e-commerce platform was slowing down. The filters we'd been casually adding for months—price, category, brand, rating—were now killing our database. I remember thinking: but these were just tickets. I shipped what they asked me to ship.

That's when I realized I'd been confusing implementation with ownership. And it's a distinction that barely anyone talks about, but it's the entire difference between being a mid-level developer and being someone who actually shapes the product.

The Difference Between Executing and Deciding

Implementing is taking a pre-drawn box and filling it in. Someone else—a product manager, a senior engineer, a tech lead—has already decided the shape of the problem. Your job is the execution. It's valuable work. But it's not ownership.

Ownership is looking at that same box and asking: Is this the right box at all?

In my search example, the "right box" wasn't adding more filters to a table query. It was recognizing that a SQL table—optimized for transactional consistency—had become the wrong tool for what we were asking it to do. We needed a search index. A completely different piece of infrastructure designed from the ground up to handle rapid filtering across millions of products.

The person executing would wait for that redesign to show up on the roadmap. The person owning it would put it there themselves, because they're the one in the code every day seeing the cracks appear.

Three Questions That Separate the Two Roles

I started thinking about every service I touch through three lenses, and honestly, it's changed how I approach every ticket now:

Who is this actually for? Not the user persona in the Figma file, but the real usage pattern emerging in production. Are we optimizing for the casual browser or the power user with fifteen filters open?

What is it built on, and can it scale? Not at our current data size, but at the size we'll be in six months or a year. I've learned the hard way that databases, caching layers, and indexing strategies have limits. Knowing those limits before you hit them is the difference between a smooth scaling story and a 3 AM incident.

What breaks first when growth happens? And when it does—not if—is the fix more of the same thing, or something entirely different?

My Take: This Is About Judgment, Not Speed

The article mentions AI at the end, almost casually. And I think that's the most important part. AI can write the WHERE clause. It can generate the search index config. What it absolutely cannot do is sit in your chair for two weeks, watching query times creep up from 200ms to 4 seconds, and decide that the entire architectural approach needs to change.

That's judgment. That's the thing that doesn't get outsourced.

I used to measure my worth by velocity—how many tickets I closed, how fast I could ship. Now I measure it by the decisions I make that don't appear on any board. Did I catch a scaling issue before it became a crisis? Did I push back on a feature request because the underlying data model couldn't handle it? Did I architect something defensively, knowing the requirements would evolve?

Those decisions barely show up on your calendar, and your manager might not even notice them. But they're what keeps the lights on when your product actually succeeds.

The Uncomfortable Truth

Here's what took me a while to accept: nobody's coming to hand you the redesign ticket. There's no roadmap item for "please rethink the foundation we built two years ago." The empty space where that work should go isn't a gap in someone else's planning. It's your job to fill it.

And yeah, that's scary. It means you're not just executing someone else's vision anymore. You're responsible for whether the system survives its own success.

But that's also where the actual career growth happens.

Source: This post was inspired by "Own the roadmap, not the backlog" by Dev.to. Read the original article