How do I start thinking like an engineer instead of just completing assigned tasks?

Task mode versus engineer mode

When managers say "think like an engineer" or "take more ownership", they are usually describing a difference like this:

Nothing in the right column requires more technical knowledge. It requires a different set of questions.

Before you code: understand the why

For every task, try to answer these before starting:

1. Who is this for? A customer, an internal team, another service?
2. What problem does it solve? Not what feature it adds, but what pain it removes.
3. How will we know it worked? Fewer support tickets, faster page load, a metric going up?
4. What is out of scope? So you do not overbuild.

If the ticket does not say, ask briefly:

Before I start on the export feature, is the main goal to help finance with month-end reports, or for customers to download their own data? It changes the format and the permissions.

That one question often prevents a week of the wrong work, and it is exactly what people mean by engineering judgement.

While you build: look for what is missing

Tickets describe the happy path. Engineers think about everything else:

• What happens with empty, huge or malformed input?
• What if the external service is slow or down?
• Who should and should not be allowed to do this?
• Will this be slow when there are a million rows instead of a hundred?
• Does it affect any other feature, report or integration?
• How would we notice if it broke in production?

You do not need to solve all of these yourself. Raising them is already valuable. "I noticed the import has no limit on file size. Should I add one, or is that handled elsewhere?"

Offer options, not just an implementation

When a task has more than one reasonable approach, share the choice rather than silently picking one:

I see two ways to do this. We can compute totals on every request, which is simple but slower for large accounts, or store them and update on each change, which is faster but adds complexity. For our current data, I would start with the first and add caching if needed. Does that match what you expect?

This shows you understand trade-offs, invites input early, and makes the final decision a shared one.

After you ship: check the outcome

Most people stop when the pull request merges. Engineers follow through:

• Check logs or metrics after release to confirm it is working.
• Ask the person who requested it whether it solved their problem.
• Note anything you would do differently, and anything left to clean up.

This habit, more than any technical skill, is what makes managers comfortable giving you bigger work.

Notice the unassigned problems

Every team has problems nobody owns: a flaky test, a slow build, missing documentation, a confusing error message users keep reporting. Engineers notice these and raise them with a suggestion:

Our build takes twelve minutes and most of it is installing dependencies. I think caching them in CI could cut it in half. Would it be all right if I spent a few hours trying it next week?

You are not overstepping by suggesting. You are showing that you care about the system, not just your ticket.

A two-week experiment

Try this on your next few tasks:

1. Write three lines before coding: the problem, who it is for, how success is measured.
2. List at least three edge cases or risks and mention them in your pull request.
3. Include one sentence on the alternative you considered and why you chose this approach.
4. Check the result a day after release and share what you saw.
5. Raise one unassigned problem with a suggested fix.

After two weeks, ask your manager whether they have noticed a difference. You will probably get a very specific answer, which is feedback you can use.

If you are still stuck

Read The Habits That Make an Engineer Worth Routing Work Through and Twelve Moves That Take You From Mid Level to Senior. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.