The next level of your career rarely begins when someone hands you a bigger title or officially assigns you a bigger area. More often, it begins when your judgment becomes reliable enough that other people naturally start trusting you with bigger decisions.

If you are waiting for your manager to give you something important to own before you can demonstrate ownership, you may be looking at career growth backwards.

In software engineering, especially in large technology companies, “ownership” often means being responsible for a product, system, or technical area and having the judgment to decide what should happen to it over time. The common question from less experienced engineers is understandable: How can responsibility be demonstrated when nobody has given them anything to be responsible for?

The answer is that responsibility does not usually begin with an assignment.

It begins with behavior.

Creators lock in their holiday content calendars 90 days out, before most ecommerce brands finalize their commission strategy and way before Black Friday and October deal events.

Get ahead of the seasonal rush with The 90-Day Holiday Sprint, a practical guide for brands that want creators driving holiday demand while competitors are still recruiting:

Your 90-day countdown starts now.

Get the Free Guide

Think about the decision from a technical lead’s perspective. When a TL gives an engineer responsibility for an area, they are not simply handing over a collection of tasks. They are trusting that person to make decisions that could affect users, reliability, performance, architecture, and the rest of the team.

That means the real question is not simply, “Can this engineer finish the work?”

It is closer to: “Can this person make good decisions without needing constant supervision?”

A technical lead needs confidence that the engineer will identify problems, consider consequences, recognize trade-offs, and make decisions with enough judgment to protect the system.

That trust has to come from somewhere.

You build it by repeatedly showing that you can think through problems well within the scope you already have.

Tip: Do not wait for a larger title to start demonstrating ownership. Look for decisions within your current responsibilities where better judgment, preparation, and follow-through can make a visible difference.

The progression is rarely dramatic.

An engineer may initially work under close technical direction. The TL might point toward an implementation and catch important issues during review. Instead of simply fixing those issues and moving on, the engineer can study why the TL noticed them.

That distinction is important.

Copying someone's recommendation solves the immediate problem. Understanding the reasoning behind the recommendation improves your ability to solve the next problem independently.

Over time, those lessons become part of how you evaluate your own ideas.

You begin pressure-testing an API change before proposing it. You think about performance implications before someone points them out. You consider whether apparently different pieces of a system might actually share a deeper abstraction.

Eventually, fewer of your proposals require correction.

That is when the relationship begins to change.

The TL does not have to inspect every decision because experience has demonstrated that the engineer is increasingly capable of reaching sound conclusions independently.

The article's experience with Perfetto provides a useful example of how this progression can happen.

While building trace-analysis tooling, the engineer initially worked largely under the direction of the technical lead. As implementation decisions became more independent, the TL continued identifying significant issues that had been missed.

One example involved several data structures that appeared unrelated. The engineer had created separate classes for three or four of them.

The technical lead saw something different: they were all tables and could be represented through a common abstraction.

At the time, that connection was not obvious to the engineer. But instead of treating the feedback as simply a correction to the code, the more valuable lesson was understanding the reasoning behind it.

That pattern compounded.

The engineer began applying the same way of thinking when evaluating API changes and performance improvements. More proposals began receiving a simple approval: go ahead.

That short response represented something much bigger.

It meant trust was growing.

Tip: When a more experienced engineer catches something you missed, do not focus only on fixing the mistake. Study the reasoning that allowed them to see it earlier.

Eventually, ownership starts looking different from simply being assigned tasks.

Instead of asking what should be implemented next, the engineer starts talking directly with users, understanding their problems, translating those problems into technical changes, and deciding what should be improved.

The engineer is no longer just executing someone else's agenda.

They are helping create the agenda.

That is a significant transition.

It also changes the relationship with the technical lead. Instead of the TL always suggesting the direction and the engineer evaluating how to implement it, the engineer can begin challenging proposed approaches when their own understanding of the system has become stronger.

At that point, the engineer may explain why a suggested solution will not work.

That is not a rejection of leadership. Done correctly, it is evidence that the engineer has developed enough understanding to exercise independent judgment.

Eventually, the TL may stop thinking of that person as simply “the engineer who works on the tools.”

They become the person others associate with that area.

That is ownership before the formal label arrives.

Try Factor, America's #1 ready-to-eat meal delivery service.

Made from ingredients you recognize. Whole food. Nothing unnecessary. Let’s eat real.

Get 50% off your first Factor box + Free Breakfast for a year *1 free breakfast item per box for 1 year while subscription active.

Try Factor Now

There is an important boundary here.

Taking responsibility does not mean grabbing projects from teammates, making decisions outside your authority, or deliberately stepping on someone else's area simply to make yourself look senior.

That can create the opposite impression.

Real ownership grows inside the scope you already have.

If you are responsible for a component, make sure you understand its users. If you are changing an API, think through how it affects the surrounding system. If you are fixing a performance problem, investigate the underlying cause instead of stopping at the immediate symptom.

You do not need to declare yourself the owner.

You need to behave like someone who can eventually be trusted with ownership.

Tip: Expand your responsibility through better judgment, not through territorial behavior. Make the people already responsible for the area feel safer giving you more room to operate.

Formal responsibility is often a trailing indicator.

By the time your title, project assignment, or official scope changes, other people may already have been relying on your judgment for months.

You might notice it in small ways.

Your TL stops reviewing every minor decision. Teammates start asking for your opinion before making changes. Users come directly to you with problems. Your proposals need fewer corrections. You begin identifying issues before they become incidents.

Those are signals that responsibility is already increasing.

The formal recognition may simply arrive later.

This is why waiting for someone to say, “You now own this,” can be limiting. The opportunity to demonstrate readiness exists in the work already sitting in front of you.

There is one important qualification: this approach cannot overcome every organizational problem.

A healthy manager should recognize good judgment and gradually expand an engineer's scope. But some environments are driven more by politics, favoritism, or poor management than by demonstrated capability.

In those situations, responsibility may not reliably follow performance.

That does not invalidate the principle. It simply means career progression depends partly on the environment in which that behavior is being demonstrated.

In a healthy team, however, the pattern is powerful:

First, demonstrate judgment. Then earn trust. Then receive more responsibility.

Not the other way around.

If you want more responsibility, the most useful question may not be, “What bigger project can someone give me?”

Try asking a different question:

“What decision within my current scope can I handle better without being told what to do?”

That could mean understanding the users of a system more deeply, identifying a recurring technical problem, improving a design before implementation begins, challenging an assumption with evidence, or anticipating a risk your team has not considered.

Do that consistently and something changes.

You become easier to trust.

And once people trust your judgment, responsibility tends to follow.

The career lesson is straightforward: responsibility is taken in small increments before it is given in full. The strongest signal that you are ready for more is not asking for more. It is demonstrating, through your existing work, that giving you more would be a safe decision.

What’s your next spark? A new platform engineering skill? A bold pitch? A team ready to rise? Share your ideas or challenges at Tiny Big Spark. Let’s build your pyramid—together.

That’s it!

Keep innovating and stay inspired!

If you think your colleagues and friends would find this content valuable, we’d love it if you shared our newsletter with them!

As the world becomes increasingly digital, this question will be on the minds of millions of people seeking new income streams in 2026.

The answer is—Absolutely!

Thank you for taking the time to read today’s email! Your support allows me to send out this newsletter for free every day. 

 What do you think for today’s episode? Please provide your feedback in the poll below.

Share the newsletter with your friends and colleagues if you find it valuable.

Disclaimer: The "Tiny Big Spark" newsletter is for informational and educational purposes only, not a substitute for professional advice, including financial, legal, medical, or technical. We strive for accuracy but make no guarantees about the completeness or reliability of the information provided. Any reliance on this information is at your own risk. The views expressed are those of the authors and do not reflect any organization's official position. This newsletter may link to external sites we don't control; we do not endorse their content. We are not liable for any losses or damages from using this information.